From Sanskriti Khandelwal | Product & Market Analysis
Multi-Agent Systems Are Overrated. Here Is the Narrow Case Where They Win
On this page
Anthropic's own engineering team measured multi-agent systems using about 15 times the tokens of a chat interaction. The same write-up reported that token usage alone explained 80% of the performance variance on its research benchmark. That is most of the argument in two numbers. Multi-agent architecture is largely a delivery mechanism for compute, and there are cheaper ways to buy compute.
Key takeaways
- Multi-agent systems use roughly 15 times the tokens of a chat. Anthropic measured about 4 times for a single agent and about 15 times for a multi-agent system, and found token usage by itself explained 80% of the variance in its research evaluation.
- Match the compute and most of the advantage disappears. A controlled study published in April 2026 across three model families found single agents matched or beat multi-agent architectures on multi-hop reasoning once reasoning-token budgets were held constant.
- Coordination failure is a measured category, not bad luck. An analysis of more than 1,600 annotated traces across 7 frameworks recorded failure rates of 41% to 86.7%, with the largest single mode being agents repeating steps without progress.
- The genuine case is narrow and testable. Multi-agent wins where subtasks are parallel, read-only, and jointly larger than one context window. That describes broad research, not most enterprise workflows.
What counts as a multi-agent system
A multi-agent system splits one task across two or more model instances that each hold their own context and communicate with each other or with a coordinator. A single agent calling 30 tools is not one. The distinction is where decisions live, not how many tool calls happen.
That definition matters because the label has stretched to cover almost anything. Vendors call a router a multi-agent system. Teams call a prompt chain one. The three architectures below cost differently and fail differently, and only the last carries the full coordination tax this post is about.
Read the table before the rest of the post. If you are running the first row, most of the evidence here does not apply to you, and you are already sitting in the cheap position.
| Architecture | What it is | Token cost | What breaks first |
|---|---|---|---|
| Single agent with tools | One model instance, one context, many tools | Baseline | Tool selection degrades as the tool count climbs |
| Lead agent with subagents | One planner delegates bounded jobs and assembles the result | Multiplied by the number of subagents | Handoff quality, and the planner's summary of what came back |
| Peer multi-agent system | Several agents hold decisions and negotiate between themselves | Multiplied, plus retries and re-negotiation | Conflicting assumptions that no agent can see |
The middle row is what most production systems actually run, and it is the row most vendor material describes as a swarm. Rows two and three behave very differently under failure, so treating them as one category is where a lot of confused procurement starts.
The 15x multiplier, and who published it
The most useful number in this debate came from a company with every commercial incentive to sell you the expensive version.
Anthropic published its Claude Research architecture in June 2025. A lead agent plans, spawns 3 to 5 subagents in parallel, and a separate pass handles citations. Inside that write-up sits a plain sentence: agents use about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more.
Take that seriously. It is a vendor disclosing the cost of its own architecture, which is the most credible direction a cost figure can travel. It also means the economics only close on work whose answer is worth dollars per query.
Token spend explains most of the gain
The more damaging number is in the same post. Anthropic analysed its BrowseComp evaluation and found three factors explained 95% of performance variance, and token usage by itself explained 80%.
I read that as the finding, not a footnote. If four fifths of the improvement tracks how much compute you spent, the architecture is mostly a way of spending more. You can spend more without it, by extending a single agent's reasoning budget or letting it run longer.
That is the question to put to any vendor selling orchestration. Was the comparison run at equal token spend? If the answer is no, you are being shown a compute result dressed as an architecture result. The wider pattern of rising agent bills is covered in why cheaper tokens keep producing larger invoices.
Hold the budget constant and the advantage mostly goes
Somebody finally ran that comparison properly.
The matched-budget experiment
Dat Tran and Douwe Kiela published a controlled study in April 2026 comparing single-agent and multi-agent systems under matched reasoning-token budgets. They tested three model families: Qwen3, DeepSeek-R1-Distill-Llama and Gemini 2.5.
The result is blunt. Single agents consistently matched or outperformed multi-agent architectures on multi-hop reasoning when reasoning tokens were held constant. The paper is a preprint and has not been peer reviewed, which belongs in the same sentence as the finding.
Two details make it more useful than a headline. The authors predict when multi-agent should win: when a single agent's context utilisation degrades, or when more compute is spent. They also found measurement artifacts in API-based budget control, notably in Gemini 2.5, that inflate apparent multi-agent gains. Some of the published advantage is an instrumentation problem.
A negative ablation on GAIA
A second preprint, published in May 2026, reports the same direction from the opposite angle. The ChromaFlow report evaluated a tool-augmented agent framework on GAIA 2023 Level-1 validation tasks.
A frozen baseline scored 29 of 53, or 54.72%. A later configuration with expanded orchestration scored 27 of 53, or 50.94%, while producing more tracebacks, more timeout events, more tool-failure mentions and higher logged cost. Two randomised 20-task checks returned 12 of 20 and 11 of 20, which the author uses to show that small diagnostic gains are unstable across samples.
Treat this as one data point, not proof. It is 53 tasks, one framework, one author and no peer review. What makes it worth quoting is that it is a published negative result, and this literature is short of those.
Coordination failure is a named category now
Until early 2025 the case against multi-agent systems was anecdote. Then a group at Berkeley and its collaborators built a taxonomy out of evidence.
The MAST work, by Mert Cemri, Melissa Pan and eleven co-authors including Matei Zaharia, Joseph Gonzalez and Ion Stoica, annotated more than 1,600 traces across 7 open-source multi-agent frameworks. It recorded failure rates between 41% and 86.7% and sorted the causes into 14 modes across 3 categories: system design, inter-agent misalignment, and task verification.
Six expert annotators reached a Cohen's kappa of 0.88 during taxonomy development. That is unusually strong agreement for qualitative coding, and it is why this paper carries more weight than the many blog posts restating it.
Where the failures cluster
The distribution is the interesting part. These are not knowledge failures. They are process failures, and every one of them is created by the act of splitting the work.
The paper also tested fixes, and the results deserve reading twice. On the ChatDev framework, adding a workflow step where a lead role gives final approval lifted success by 9.4%. Adding verification of the high-level task objective lifted it by 15.6% on a program development benchmark.
Both fixes add a checking step. Neither adds an agent. That is the pattern across most of this literature: the recoverable gains come from constraining the system, not from expanding it. The broader reasons agent projects stall are set out in the breakdown of the six real pilot failure modes.
The failure surface grows faster than the capability
There is a structural reason coordination hurts, and it is arithmetic rather than opinion.
The arithmetic nobody runs
Assume each handoff between agents is 95% reliable. Chain 5 of them and joint reliability is 77%. Chain 10 and it is 60%. Those figures are illustrative arithmetic, not measured data, and the real per-step number in your system is almost certainly unknown to you.
That is the honest problem. Very few teams can state their per-handoff reliability, so the compounding happens invisibly. Capability adds up in a straight line. Failure probability compounds.
Cognition's Walden Yan made the qualitative version of this argument in June 2025, in a post titled Don't Build Multi-Agents. His two principles are worth memorising: share full agent traces rather than individual messages, and treat every action as carrying an implicit decision, because conflicting decisions produce bad results. His example is a game build split across subagents, where one built a background in the wrong visual style and another built a character that did not match. Nobody made an error. They made incompatible assumptions, which is a different failure and much harder to test for.
Most teams cannot see any of this happening. LangChain surveyed 1,340 practitioners between 18 November and 2 December 2025 and found 57% had agents in production, rising to 67% at organisations above 10,000 employees. Quality was the most cited barrier, named by about a third of respondents, ahead of both cost and latency.
The gap that matters sits underneath. 89% of organisations had adopted some form of observability, but only 52.4% ran offline evaluations. Tracing tells you what happened. Evaluation tells you whether it was right, and roughly half of these teams cannot answer the second question.
Adding agents to a system you cannot evaluate is not an architecture decision. It is a bet placed in the dark. If you have no evaluation suite, build that before you build a swarm, and the guide to standing up an eval suite is the cheaper first move. The related problem of quiet degradation after launch is covered in the piece on agent drift in production.
The narrow band where multi-agent genuinely wins
None of the above says multi-agent never works. It says the winning conditions are specific, and most enterprise workflows do not meet them.
Breadth-first, read-only research
Anthropic's own result is the strongest published case for the architecture. A multi-agent system with Claude Opus 4 leading and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on its internal research evaluation.
Look at the task type rather than the number. The example given is identifying board members across every S&P 500 information technology company. That decomposes into many independent lookups. None modifies shared state, none needs to see another's output, and together they exceed a single context window.
Anthropic is equally clear about the other side. Most coding tasks contain fewer genuinely parallelisable subtasks than research does, and domains where agents must share the same context or carry many dependencies are the wrong fit. The company's earlier guidance on building agents tells you to find the simplest solution possible and only increase complexity when needed.
Width scaling with smaller models
The second real case is more interesting, and it is the strongest argument against my own position. A February 2026 paper introduced WideSeek-R1, a lead-agent and subagent framework trained with multi-agent reinforcement learning on 20,000 broad information-seeking tasks.
A 4-billion-parameter version reached an item F1 of 40.0% on the WideSearch benchmark, comparable to single-agent DeepSeek-R1-671B, and gains rose consistently as the number of parallel subagents increased. A small model organised well matched a model roughly 170 times its size.
That is a genuine architectural result, not a compute result. It also arrives with two conditions most enterprises cannot meet: the agents were trained jointly with reinforcement learning, and the task class was broad information seeking. Buying a framework does not reproduce it.
Four tests before you split one agent into five
Here is the test I would apply, in order, before approving any orchestration work.
| Test | The question | If the answer is no |
|---|---|---|
| 1. Independence | Can the subtasks run without ever seeing each other's output? | Do not split. Shared context is exactly what handoffs destroy. |
| 2. Read-only | Is the work reading and gathering rather than writing to a shared artefact? | Do not split. Two agents writing the same object is a conflict generator. |
| 3. Context pressure | Does the combined input genuinely exceed one context window? | Do not split. You would be paying a coordination tax to solve a problem you do not have. |
| 4. Measurability | Can you score the end-to-end output automatically today? | Do not split. Build the evaluation first or you will never detect the regression. |
This table is our framing, drawn from the sources cited in this post. It is not lifted from a single published framework and has not been validated against outcome data, because no public dataset links architecture choice to measured enterprise results.
Four yes answers is a real case for splitting. Anything less and the cheaper move is to raise the ceiling on one agent: better tool descriptions, tiered tool discovery, a longer reasoning budget, and a human checkpoint at the one step that carries the risk. Where that checkpoint belongs is argued in the case for human in the loop as an architecture rather than a cop-out.
One more rule, and it is the one most often broken. Split on state boundaries, not on job titles. A researcher agent, a writer agent and an editor agent is an org chart, not an architecture. It feels intuitive and it maps onto nothing in the system's actual data flow.
Where this argument is weakest
Four things could make this post wrong, and one of them is already happening.
This is benchmark evidence, not enterprise evidence
Every controlled comparison cited here runs on public benchmarks: GAIA, WideSearch, BrowseComp, multi-hop question answering. None runs on a claims process, a procurement workflow or a support queue. Enterprise tasks have messier tools, dirtier data and stricter permissions, and decomposition may help more in that setting rather than less.
| Source | What it measured | Main limitation |
|---|---|---|
| Anthropic Engineering, June 2025 | Token multipliers and a 90.2% research gain | Vendor's internal evaluation, not reproducible externally |
| Cemri et al., NeurIPS 2025 | Failure taxonomy over 1,600+ traces, 7 frameworks | Open-source research frameworks, not enterprise products |
| Tran and Kiela, April 2026 | Single vs multi-agent at matched token budgets | Preprint, multi-hop reasoning tasks only |
| ChromaFlow, May 2026 | Negative ablation on orchestration depth | 53 tasks, one framework, one author, preprint |
| WideSeek-R1, February 2026 | Width scaling gains from trained subagents | Requires joint reinforcement learning training |
| LangChain, late 2025 | Production rates and barriers, 1,340 practitioners | Self-selected sample skewed toward its own users |
The frontier is moving back toward delegation
At LangChain's Interrupt conference in 2026, a team manager from monday.com described running a monolithic engine holding more than 200 tools across CRM, service and marketing, and said the architecture exploded in their face through context pollution and rising cost. The rebuild moved to tiered tool discovery and delegation to subagents, with a reported 94% recovery success rate.
That case cuts both ways and I am not going to pretend otherwise. It is evidence that a flat single agent with hundreds of tools also fails, and that structured delegation is the fix. It is also a conference talk with no published before-figure and no independent verification, so treat the 94% as directional. The reconciliation is that delegation with one owner of intent is not the same object as a peer swarm. The frameworks studied by MAST are mostly the second kind. The systems working in production are mostly the first.
Two further things could flip this. Model coordination may simply improve, and Anthropic noted in 2025 that language models are not yet good at delegating to each other in real time, where the word yet is doing real work. Token prices could also fall far enough that a 15 times multiplier stops mattering, though that has not happened for agent workloads, because falling unit prices keep being absorbed by longer runs.
Frequently asked questions
Are multi-agent systems better than a single agent?
Not by default. Anthropic's multi-agent research system beat a single agent by 90.2% on a breadth-first research evaluation, but it used roughly 15 times the tokens of a chat. A controlled study published in April 2026 found that once reasoning-token budgets are matched, single agents match or beat multi-agent architectures on multi-hop reasoning. The honest summary is that multi-agent buys compute, and compute buys the score.
When should you use a multi-agent system?
Use one when the subtasks are genuinely parallel, mostly read-only, and jointly larger than a single context window. Breadth-first research fits, because 20 independent lookups do not conflict with each other. Work that shares state, has ordered dependencies, or writes to the same artefact does not fit. Anthropic's own guidance says most coding tasks contain fewer parallelisable subtasks than research does.
How much more do multi-agent systems cost?
Anthropic measured single agents at about 4 times the tokens of a chat interaction and multi-agent systems at about 15 times. That covers the token line only. Add duplicated context across agents, retries after failed handoffs, longer traces to store, and the evaluation work needed to trust the output. Budget an order of magnitude above a single-agent baseline, then re-measure after two weeks of real traffic.
Why do multi-agent AI systems fail?
Mostly on coordination rather than model quality. The MAST study annotated more than 1,600 traces across 7 frameworks and recorded failure rates between 41% and 86.7%. The largest single mode was step repetition without progress at 15.7%, followed by a mismatch between an agent's stated reasoning and its action at 13.2%, and failure to recognise a termination condition at 12.4%. Those are orchestration defects.
Is agent orchestration worth it for enterprises?
Sometimes, and later than most roadmaps assume. LangChain's survey of 1,340 practitioners in late 2025 found 57% had agents in production and named quality as the top barrier, ahead of cost and latency. Only 52.4% ran offline evaluations. Orchestration adds failure modes that only evaluation can catch, so a team without evaluations is buying complexity it has no way to measure.
What is the difference between subagents and a multi-agent system?
Subagents are delegated by one lead agent that keeps the plan and assembles the result. A peer multi-agent system distributes the decision itself across agents that negotiate. The first keeps a single owner of intent, which is why it degrades more gracefully. The second is where conflicting assumptions arise, because agents act on decisions they never saw each other make.
Where to start this week
Two exercises, both cheap, both uncomfortable.
First, take your most complex agent workflow and rerun the same 20 tasks with one agent holding the whole job and the same total token budget. Record accuracy, cost and wall-clock time for both. If the single agent comes within a few points, you have found the cheapest improvement available to you this quarter, and it is a deletion.
Second, write down your per-handoff reliability. Not the end-to-end success rate, the per-handoff number. Most teams discover they have never measured it, and the discovery is worth more than the number would have been.
If you take one thing
Ask every orchestration vendor one question: was the comparison run at equal token spend? Four fifths of the published gain tracks compute, so a demo that does not control for it is showing you a bigger bill, not a better architecture.
References
- Anthropic Engineering, How we built our multi-agent research system, 13 June 2025. Used for the 4x and 15x token multipliers, the 80% variance figure, the 90.2% research result and the statements on where multi-agent does not fit.
- Mert Cemri, Melissa Z. Pan, Shuyi Yang and co-authors, Why Do Multi-Agent LLM Systems Fail?, arXiv 2503.13657, March 2025, revised October 2025, NeurIPS 2025. Used for the 41% to 86.7% failure rates, the failure mode shares and the ChatDev intervention results.
- Dat Tran and Douwe Kiela, Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, arXiv 2604.02460, April 2026. Preprint, not peer reviewed. Used for the matched-budget finding and the budget-control artifacts.
- Tarun Mittal, ChromaFlow: A Negative Ablation Study of Orchestration Overhead in Tool-Augmented Agent Evaluation, arXiv 2605.14102, May 2026. Preprint, single author, 53 tasks. Used for the GAIA Level-1 figures.
- Zelai Xu and co-authors, WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning, arXiv 2602.04634, February 2026. Preprint. Used for the 40.0% item F1 result.
- Walden Yan, Cognition, Don't Build Multi-Agents, 12 June 2025. Used for the two principles and the incompatible-assumptions example.
- LangChain, State of Agent Engineering, 1,340 responses collected 18 November to 2 December 2025. Used for the production, barrier, observability and evaluation figures.
The weakest thing about this source base: three of the seven references are arXiv preprints that have not been peer reviewed, and the two strongest cost figures come from a vendor measuring its own product. No source here compares a multi-agent system running an actual enterprise process against a single-agent alternative at equal spend. That comparison does not exist in public.
Related reading