Multi-Agent Orchestration: How Six Specialist Agents Work Behind One Router
Six specialist agents and a router instead of one giant prompt. The architecture of the system we built for Beyond Creator, how its 55 tools are split, and why the reply modes are the real product decision.
In short: multi-agent orchestration splits a job across specialist agents that each see only their own tools, instead of one giant prompt. In the system we built for Beyond Creator, six specialist agents and a router share 55 tools. Because responsibility is split, each part can be tested and changed on its own.
A multi-agent system is an architecture in which several AI agents share one task. A router agent is the agent that reads an incoming request and hands it to the right specialist without producing an answer itself.
In most places, "AI agent" describes a chat box running on a single prompt. In production it hits a familiar wall: as the prompt grows the model loses track of which job it is doing, as the tool count grows it calls the wrong tool, and a single error brings the whole flow down.
Beyond Review, which GG Tech Teknoloji built for Beyond Creator, uses six specialist agents and a router instead. It runs on Google ADK, took 11 months to build, and is live at beyondreview.ai.
How do the six specialist agents share the work?
The router (super_agent) never writes an answer and has no tools at all. Its only job is to hand each request to the right specialist. Each specialist sees only the tools for its own job.
| Agent | Job | Tools |
|---|---|---|
| gmb_agent | Google Business Profile management: fetching the profile, generating and choosing descriptions, updating phone and address, an approval flow for changes | 15 |
| billing_agent | Subscriptions and payments: listing plans, quoting and applying plan changes, paying invoices, payment alerts, support tickets | 14 |
| review_agent | Review replies: approving, rejecting and rewriting drafts, sentiment analysis, rule normalisation, flagging | 7 |
| competitor_agent | Competitor tracking (up to 3): adding, listing, searching, competitor reports | 7 |
| reporting_agent | Insights and reports: monthly and on-demand reports, latest insights | 6 |
| onboarding_agent | Onboarding: step status, submitting fields, going back, completing or cancelling | 6 |
| super_agent | Router: hands off, never answers | 0 |
That is 55 tools in total. The numbers were counted from the tool lists in the agents' source code (September 2026). Separately, a web_help_agent with 3 tools handles help on the website, independent of the dashboard.
The uneven split is deliberate. Business profile management and billing are multi-step flows that need approval. Replying to a review revolves around a single decision.
Which problems does specialisation solve?
- Tool selection stays reliable: give all 55 tools to one agent and the model mixes up tools with similar names. Each agent sees only its own 6 to 15 tools, so the choice space stays small.
- The context window is not wasted: the review-reply job does not have to carry the billing tools' definitions in its context.
- Failures can be isolated: you can trace which specialist went wrong at which step, instead of losing it in one long trace.
- Changes stay local: when you change one specialist's tools, you do not have to retest the others.
Why are the reply modes the real product decision?
The system has three reply modes: automatic, hybrid and manual. Each business chooses the mode separately for each star rating, so five-star reviews can be answered automatically while low ratings wait for approval.
This is not a technical detail; it is the most important product decision. Replying to reviews carries reputational risk, and a fully automatic system publishes a bad reply just as automatically. Hybrid mode drafts the reply and routes it to the owner for approval; manual mode only sends a notification. Every generated reply goes through a second model call that checks suitability and promises before publishing, and a reply that fails that check three times is never published.
The general rule: design an approval step for every agent action that is public and cannot be undone. Loosen it as the agent earns trust, never the other way round. The review_agent's tool list reflects this directly: approve_reply, reject_reply and rewrite_reply are all actions where a person decides.
What stack does this architecture run on?
The agents run on Google ADK and Gemini, the application on Node.js and Next.js, and the data on MongoDB. The scope is Google Business Profile reviews only; platforms such as Yelp or TripAdvisor are not covered.
Frequently asked questions
- How many tools before you should split an agent?
- There is no fixed number. The signal is the model starting to confuse tools with similar names. In our system each specialist sees between 6 and 15 tools.
- Why does the router agent have no tools?
- Its only job is to understand intent and hand off to the right specialist. Give it tools and it starts doing the work itself, and the separation that specialisation buys is lost.
- Is a multi-agent system more expensive than a single agent?
- Not always. Specialists carry only their own tool definitions in context, while a single large agent has to carry every tool definition on every request. Cost depends on how many agents a request activates.
Case study
Beyond Review: AI review managementService
Multi-agent orchestrationRelated article
RAG or fine-tuning? A decision matrix for enterprise Turkish documentsMulti-agent does not mean "more models"; it means splitting responsibility. Split responsibility can be tested, traced and changed piece by piece.
Author: Gürhan Elçiçek, founder of GG Tech Teknoloji.