Multi-agent system· AI architecture
Multi-Agent System — The Three Things That Name Covers, the Coordination Patterns, and What the Second Agent Costs (2026)
Quick answer: In the sense engineers mean, a multi-agent system is several AI agents coordinating on one task: a lead agent decomposes the goal, specialized workers handle the pieces with their own tools and their own context windows, and the results get merged. It buys parallelism and specialization. It costs a lot more tokens, and it adds failure modes that a single agent does not have. In the sense your chatbot vendor probably means, "multi-agent" is a tier limit counting how many separate bots you may create, or how many teammates may answer chats. Those are useful things to buy. They are not AI teamwork, and conflating them is how businesses end up paying for coordination they never receive.
One word, three different products
Start here, because everything downstream depends on which sense is in play. The word "agent" was already doing two jobs in customer-service software long before language models arrived, and the research sense landed on top without displacing either.
| Sense | What it actually means | Where you meet it |
|---|---|---|
| Coordinating AI agents | Several LLM-driven agents with distinct roles, tools, and context, pursuing one goal and exchanging results | Research systems, developer frameworks, agentic platforms |
| Multiple standalone bots | A tier limit on how many separate, unconnected assistants your account may hold | Chatbot platform pricing pages |
| Multiple human agents | Seats in a shared inbox, with assignment and routing between staff | Live chat and helpdesk products |
Two examples from our own review sessions make the gap visible. Chatbase prices "agents" as separately deployable assistants, verified on the vendor's pricing page on 26 May 2026 at one on Free, five on Hobby, eight on Standard, and twelve on Pro. By default those five bots point at five knowledge bases and never consult each other, which is a catalog rather than a team. Meanwhile the Teamwork tab we saw in SendPulse's inbox is the third sense entirely: human staff claiming and rerouting conversations to each other. The tab surfaces in the free-tier UI, though the assignment workflow behind it belongs to the paid tier, and we did not exercise it. Both are legitimate features. Neither is a multi-agent system in the sense the rest of this entry describes.
The research sense is also the oldest of the three. Distributed artificial intelligence has studied multi-agent systems since well before language models, in the tradition Michael Wooldridge documents in An Introduction to MultiAgent Systems, where agents were autonomous programs negotiating, bidding, and coordinating without a central controller. What the language-model era changed is that each agent is now steered by written instructions instead of hand-coded protocols. Anyone who can describe a job can now build one of these, which is why the architecture spread so fast and why its edges got so blurry.
What the architecture actually is
Strip the marketing and a multi-agent system has four parts. There is an orchestrator that receives the goal and decides how to split it. There are workers, each given a narrow brief, its own tool access, and its own context. There is a routing mechanism that decides who runs next and when the work is done. And there is a merge step that turns several partial answers into one, which sounds clerical and is where most of the quality is actually decided.
Anthropic's published account of its own Research feature is the clearest worked example in the open, because it names the parts and the costs. A LeadResearcher plans the approach and spawns three to five subagents that search in parallel, each with a separate context window. The lead decides whether the returned material is sufficient, spawns more if not, and a distinct CitationAgent then walks the draft and the sources to attach attributions. The write-up is also unusually frank about early failures: agents that spawned fifty subagents for a trivial query, agents that hunted endlessly for sources that did not exist, and agents that flooded each other with status updates. Those are the characteristic multi-agent failures, and none of them can happen to a system with one agent in it.
flowchart TD
U[User goal] --> O[Orchestrator agent<br/>plans and splits]
O --> W1[Worker 1<br/>own tools + context]
O --> W2[Worker 2<br/>own tools + context]
O --> W3[Worker 3<br/>own tools + context]
W1 --> M[Merge and verify]
W2 --> M
W3 --> M
M --> O
O --> R[Single answer or action]
style O fill:#ffe8cc
style M fill:#f5f5f5
Figure 1. The orchestrator-worker shape. The loop back from merge to orchestrator is the part that makes it a system and not a fan-out: the lead can decide the returned work is thin and send it back around, which is also how a runaway system burns a month of budget in an afternoon.
The coordination patterns worth knowing
Frameworks have converged on a small vocabulary. The labels differ slightly across LangGraph, the OpenAI Agents SDK, and Microsoft Agent Framework 1.0, which shipped on 3 April 2026 as the merged successor to AutoGen and Semantic Kernel. Underneath the labels there are four shapes.
| Pattern | How control moves | Good for | Main risk |
|---|---|---|---|
| Supervisor | A central agent routes every step and holds the global state | Clear task decomposition, auditable paths | The supervisor becomes the bottleneck and the single point of failure |
| Handoff / swarm | Agents pass control directly to each other by specialization | Conversational routing, natural topic switches | Debugging peer handoffs is close to impossible without tracing |
| Sequential pipeline | Fixed order, each agent's output feeds the next | Repeatable multi-stage work like draft, check, format | No adaptation; a bad early step poisons everything after it |
| Hierarchical | Supervisors of supervisors, in layers | Worker pools past roughly half a dozen | Layers of abstraction that add latency and token spend |
The supervisor pattern is the default for good reason: control flow stays inspectable, and one component owns the decision about what happens next. Handoff is the pattern most relevant to conversational products, since "this is a billing question, not a shipping question" is exactly the routing a support bot does anyway, and it is what the handoff rules entry describes at the human boundary. Hierarchies only start to earn their latency past roughly half a dozen workers, which is more agents than an SMB support stack will ever hold.
What the second agent costs
This is the number most product pages omit. Anthropic reported that its multi-agent research configuration consumed roughly fifteen times the tokens of an ordinary chat exchange, against roughly four times for a single agent doing the same kind of work, and, in a separate browsing evaluation, that token usage alone explained around 80 percent of the performance variance. A different internal research evaluation put a lead Claude Opus 4 agent directing Claude Sonnet 4 workers ahead of single-agent Opus 4 by 90.2 percent. Both figures are Anthropic's own, measured on Anthropic's own product, and neither transfers automatically to your support bot.
The shape they describe is consistent. A multi-agent system pays for itself when the task genuinely splits into independent strands that can be explored at the same time, because parallelism is what you are buying. It pays for nothing when the subtasks depend on each other, which is why Anthropic notes the approach works less well for tightly interdependent work such as coding, where step three needs step two's actual result rather than a summary of it.
There is a wrinkle that matters more to an SMB buyer than the multiplier itself: on most chatbot platforms you do not pay for tokens. You pay per message credit, per conversation, or per resolved outcome. Chatbase sells message credits by tier, and Intercom prices Fin at $0.99 per resolution on top of seat pricing, per our May 2026 reviews. Under those models a fifteenfold token bill is the vendor's margin problem before it is yours, and it reaches your invoice indirectly, as tier limits and price rises. Where the multiplier lands on you directly is a build on your own API key, which is the BYOLLM case. So the question to carry into a demo is not "how many tokens?" but "which meter am I on, and what does a multi-step run consume on that meter?" The ROI math does not change because the architecture got more interesting.
When one agent is enough
Most chatbot workloads do not need a second agent. A well-instructed single agent with retrieval over your knowledge base and a handful of tools handles order lookups, policy questions, bookings, and escalation without any coordination layer at all. Four questions separate the cases where a second agent earns its cost:
- Do the subtasks actually run in parallel? If the work is "search five sources at once and merge," splitting helps. If it is "do A, then use A's output to do B," a single agent with a plan is cheaper and less fragile.
- Do the roles need different tools or different permissions? A researcher that only reads and a writer that only drafts is a real separation. A researcher and a writer that share every tool is one agent with two prompts.
- Would a single agent's context overflow? Separate context windows are the strongest technical argument for splitting. If everything fits comfortably in one window, you are paying for a solution to a problem you do not have.
- Can you trace what each agent did? Coordination failures are invisible without per-agent logs. Without tracing, a wrong answer from a five-agent system is not debuggable, only replaceable.
If fewer than two of those land, the right answer is one agent, tighter instructions, and better guardrails. A vague system prompt copied across three agents is still a vague system prompt, now in triplicate and harder to edit.
How the protocols fit
Two open standards get mentioned in the same breath and answer different questions. The Model Context Protocol connects an agent to tools and data: one agent, many capabilities. The Agent2Agent protocol connects agents to each other across vendor and framework boundaries, so an agent built on one stack can discover another, describe what it can do, and exchange tasks. Google published A2A in April 2025 and donated it to the Linux Foundation on 23 June 2025; at the project's one-year mark on 9 April 2026 the foundation reported more than 150 supporting organizations, integration across the major cloud platforms, and production deployments in supply chain, financial services, insurance, and IT operations.
For an SMB buyer this matters at one remove. You will not implement A2A. But a platform that speaks it is a platform whose agents can work with agents you did not buy from it, which is a different lock-in profile than a closed orchestration layer. Ask about it the way you would ask about data export.
How chatbot platforms handle it
Across the fifteen platforms in our review index, none ships a lead-and-worker architecture of the kind this entry describes. What two of them do ship is a single coordination primitive, and the distinction is worth having precisely.
Chatbase offers Smart Agent Routing on its higher tiers: intent-based handoff from one agent to another. We tested it on a Standard-tier account during our May 2026 review and the routing performed cleanly. That is the handoff pattern from the table above, implemented once, without a supervisor or a merge step. Botpress ships a tool-catalog category it labels Agents, holding a single entry, "Extract Content from URL," which we captured on an authenticated account on 29 May 2026. The label suggests agent-to-agent calling; the entry itself is one narrow tool, and we have not watched one Botpress agent invoke another. Elsewhere in the same product the Autonomous Engine picks tools, knowledge bases, and sub-flows at runtime, configured once per agent instead of per node, and that is one agent with many capabilities.
So a platform can hold coordination primitives without being a multi-agent system, the way a kitchen can hold a stove without being a restaurant. When a pricing page says "agents," assume the second or third sense from the table above until the vendor shows you otherwise. Then ask for mechanics instead of adjectives: which agent decides, what gets passed, who reconciles the result. The companion guide, AI agent orchestration, turns those answers into a purchase decision, with entry prices and the cheaper thing to build when the agents merely coexist.
Related terms
- AI agent — the single unit that a multi-agent system is built out of.
- Agentic AI — the autonomy spectrum that determines how much any one agent can decide.
- AI agent vs chatbot — the boundary between replying and acting, one layer below this one.
- Model Context Protocol — the agent-to-tool standard, distinct from the agent-to-agent one.
- Large language model — the reasoning engine each agent in the system runs on.
- Human handoff — the exit that every architecture still needs, however many agents it has.
FAQ
What is a multi-agent system in simple terms?
Several AI assistants sharing one job instead of one assistant carrying it alone. One of them usually acts as the lead: it breaks the goal into pieces, hands each piece to a specialist with its own tools, and assembles the answers. The specialists do not share a memory, which is the point and also the problem.
Is a multi-agent system better than a single agent?
Only for work that splits. Anthropic's published evaluations of its own research product showed a large advantage for multi-agent on breadth-first research tasks, at a heavy token premium, and the same write-up notes the approach suits tightly interdependent work poorly. For a support bot answering questions from a knowledge base, one well-instructed agent is usually faster, cheaper, and easier to debug.
When my chatbot platform says "5 agents," is that a multi-agent system?
Usually not. On most platforms that counts standalone bots you can create, each with its own knowledge base and its own settings. Chatbase, for example, priced agents this way at one to twelve per tier when we verified its pricing page on 26 May 2026, while separately offering Smart Agent Routing on higher tiers so those agents can hand off to one another. Both facts live in the same product, so ask the mechanism question rather than the label question: what gets passed between them, and who decides?
What is the difference between MCP and A2A?
MCP is how an agent reaches tools and data sources. A2A is how agents reach each other across different vendors and frameworks. They complement each other, and a system can use both: MCP for what each agent can touch, A2A for how agents delegate between organizations.
What usually goes wrong in a multi-agent system?
The documented failure modes are coordination failures, not reasoning failures. Agents spawn far more subagents than a task warrants, chase sources that do not exist, duplicate each other's work, or lose information at the merge step where several partial answers become one. Every one of them costs money while it happens, which is why spend caps and per-agent tracing are prerequisites, not refinements.
Do I need a multi-agent system for a small business chatbot?
Rarely, in our reading of the 2026 platform landscape. The architecture solves problems of parallel breadth and context overflow, and typical SMB conversations create neither. If your bot is slow, wrong, or expensive, the fix is almost always better instructions, better retrieval, and a cleaner human handoff, in that order, well before a second agent enters the picture.
Sources
- Anthropic engineering. How we built our multi-agent research system. anthropic.com/engineering/multi-agent-research-system (verified 3 August 2026).
- Linux Foundation. A2A Protocol surpasses 150 organizations, lands in major cloud platforms, and sees enterprise production use in first year (9 April 2026). linuxfoundation.org (verified 3 August 2026).
- Linux Foundation. Linux Foundation launches the Agent2Agent Protocol project (23 June 2025). linuxfoundation.org (verified 3 August 2026).
- Microsoft. Microsoft Agent Framework version 1.0 (3 April 2026). devblogs.microsoft.com/agent-framework (verified 3 August 2026).
- LangChain. LangGraph supervisor and swarm references. reference.langchain.com/python/langgraph-supervisor (verified 3 August 2026).
- Wooldridge, Michael. An Introduction to MultiAgent Systems, 2nd edition. Wiley, 2009. Cited here as the standard reference for the pre-LLM research sense of the term; the characterization in this entry is our paraphrase of that tradition rather than a quotation.
- Chatbotscape platform reviews, first-party sessions. Botpress (tool catalog captured on an authenticated account, 29 May 2026), Chatbase (pricing page verified 26 May 2026; Smart Agent Routing tested on a Standard-tier account), Intercom (Fin per-outcome pricing, May 2026), SendPulse (free-tier inbox UI).
- Chatbotscape evaluation methodology. /methodology (continuously updated).