A single AI agent can plan, use tools, and work in a loop toward a goal. But some tasks are too big, too broad, or too parallel for one agent to handle well — researching a topic from a dozen angles at once, or coordinating a swarm of subtasks that don't depend on each other. That's the job of a multi-agent AI system: instead of one model doing everything sequentially, a lead agent breaks the task apart and hands pieces to multiple subagents that work at the same time, then merges what comes back.
This isn't a lab curiosity. Anthropic put its own multi-agent research system into production and published exactly how it performs — including where it beats a single agent, and what it costs to run one. This guide covers how multi-agent systems are built, why they win on the right tasks, and why they're the wrong choice for most others.
What is a multi-agent AI system?
A multi-agent AI system is more than one AI agent working on the same problem, coordinating rather than working in isolation. The most common and best-documented design is the orchestrator-worker pattern:
- A lead agent (the orchestrator) reads the task, decides how to break it into parts, and decides how many subagents the job actually needs.
- Subagents each get a narrow, well-defined slice of the work — a specific search, a specific check, a specific piece of the draft — and run in parallel, not one after another.
- The lead agent collects their results and synthesizes a single final answer, rather than just concatenating what came back.
This is a different shape from the single-agent loop covered in our AI agents guide: instead of one agent doing plan → act → observe → repeat by itself, work is split across multiple agents running at once, then reassembled.
Why use multiple agents instead of one?
Anthropic's engineering team documented this directly when they built the multi-agent research system behind Claude's research feature. On internal research evaluations, their multi-agent system beat a single Claude Opus 4 agent by 90.2% — and for genuinely parallelizable research tasks, it cut the time to a finished answer by roughly 90% compared to a single agent working through the same steps sequentially.
The reason comes down to how each architecture spends its effort:
- Breadth. A single agent researching "identify every board member at S&P 500 IT companies" has to work through the list one company at a time. A multi-agent system can assign chunks of the list to several subagents exploring in parallel — Anthropic's own example of exactly this kind of task showed the single-agent approach failing where the multi-agent version succeeded, simply because the work was decomposed.
- Separation of concerns. Each subagent has a tightly scoped job and a clean context window for it, rather than one agent juggling the entire task's context at once.
- Speed on parallel work. If the subtasks genuinely don't depend on each other, running them concurrently is strictly faster than running them in sequence.
None of this is free, and that tradeoff is the part most explainers skip.
The real cost: tokens
Multi-agent systems are expensive relative to a normal chat reply, and the gap is bigger than most people expect. Anthropic's own numbers:
- A single AI agent typically burns about 4× the tokens of one standard chat turn, because of tool calls and looping.
- A multi-agent system uses roughly 15× the tokens of a single chat conversation — every subagent runs its own context, its own tool calls, its own reasoning.
That cost isn't incidental — Anthropic found that token usage alone explains about 80% of the variance in performance on their research-agent evaluations. More parallel exploration produces better answers, but it does so by spending more tokens, not by being cleverer per token. That's the actual tradeoff: multi-agent systems buy breadth and speed with a real multiplier on compute cost, so they only make sense when the task's value clears that bar.
What goes wrong (and how it gets fixed)
Anthropic was candid about the early failure modes when they first put this system into production:
- Over-spawning. Early versions would spin up 50 subagents for a task that needed 3, burning tokens on tasks that didn't need decomposition at all.
- Subagents chasing nothing. Agents would run endless searches for sources that didn't exist, with no built-in sense of when to stop.
- Agents interfering with each other. Without clear boundaries, subagents could duplicate work or step on each other's context.
The fix wasn't more autonomy — it was tighter instructions: explicit task descriptions for each subagent, explicit rules for how many subagents a given task warrants, and clear effort budgets written directly into the prompts. As Anthropic put it, multi-agent systems have emergent behavior that arises without being specifically programmed — which means they need a framework for how agents should collaborate, not just a goal and a hope.
Multi-agent systems vs. a single agent
| Single agent | Multi-agent system | |
|---|---|---|
| Structure | One agent, one loop | Lead agent + parallel subagents |
| Best for | Sequential, well-defined tasks | Broad, parallelizable, exploratory tasks |
| Speed on parallel work | Slower — one step at a time | Faster — subagents run concurrently |
| Token cost | ~4× a single chat reply | ~15× a single chat reply |
| Failure mode | Gets stuck or wanders off-task | Over-spawns, duplicates work, or subagents interfere |
| Needs | A clear goal and tools | A clear goal, tools, and delegation rules |
When to actually reach for a multi-agent system
Multi-agent architectures earn their token cost on tasks that are genuinely wide, not just long:
- Open-ended research across many independent sources or subtopics at once.
- Broad discovery tasks where you don't know in advance how many angles need checking (Anthropic's board-member example is the canonical case).
- Large batch work that decomposes cleanly — reviewing many similar documents, or checking many independent claims.
They're the wrong tool for:
- Narrow, sequential tasks — a single agent with a good tool loop (like the pattern in our Fable 5 orchestrator guide) is faster and far cheaper.
- Tasks where subtasks depend on each other — if step 2 needs step 1's output, running agents in parallel doesn't help and just adds coordination overhead.
- Low-stakes queries — 15× the tokens for a question a single chat reply already answers well is waste, not quality.
The rule of thumb: reach for one lead agent by default, and only fan out to multiple subagents when the task is provably wide enough that parallel exploration beats sequential depth.
How this connects to retrieval and orchestration
Multi-agent systems often lean on the same building block covered in our RAG guide: each subagent frequently does its own retrieval pass, pulling in fresh, sourced information rather than relying on the model's training data alone. And the "lead agent decides how to delegate" role is the same orchestrator concept explored hands-on in our guide to using Claude Fable 5 as an orchestrator — that article shows the pattern from the practitioner's side; this one covers why the pattern works and what it costs. For the full cluster on autonomous AI, see our AI agents topic hub.
Frequently Asked Questions
What is a multi-agent AI system in simple terms?
It's a setup where one "lead" AI agent breaks a task into pieces and hands them to several other AI agents that work on their pieces at the same time, then the lead agent combines their results into one final answer.
Are multi-agent systems better than a single AI agent?
Only for the right kind of task. On broad, parallelizable research work, Anthropic measured a 90.2% performance improvement over a single agent. On narrow, sequential tasks, a single agent is faster and much cheaper — multi-agent systems cost roughly 15x the tokens of a single chat reply.
Why do multi-agent systems cost more to run?
Every subagent runs its own reasoning, tool calls, and context window in parallel. That parallelism is what makes the system fast and thorough, but it multiplies token usage rather than reducing it.
What's the difference between an orchestrator and a subagent?
The orchestrator (lead agent) plans the strategy, decides how to split the task, and synthesizes the final answer. Subagents each execute one narrow, well-defined slice of the work and report back — they don't see or manage the whole task.
Can multi-agent systems fail?
Yes — documented failure modes include spawning far more subagents than a task needs, subagents searching for sources that don't exist, and agents duplicating or interfering with each other's work. These are fixed with explicit delegation rules and effort budgets, not by giving agents more autonomy.
The bottom line
Multi-agent AI systems solve a real problem — a single agent working sequentially can't efficiently cover a task that's genuinely wide — by trading a large increase in token cost for breadth and speed. Anthropic's own data backs the case for the right task: a 90.2% performance jump and 90% less time on parallelizable research work. But the same data is also the warning label: roughly 15× the token cost of a normal chat reply, and a design that needs explicit delegation rules to avoid over-spawning or agents tripping over each other. Use one lead agent by default. Only bring in a multi-agent system when the task is provably too broad for one agent to cover well — and budget for what that breadth costs.
