Stop Adding Agents

Multi-agent architectures are the default in every demo and framework tutorial. The 2026 evidence says they help on a narrow class of tasks, hurt on most of the rest, and cost up to fifteen times more either way. Here is how to tell which side of the line you are on.

Open any agent framework’s getting-started guide and you will meet a team. A planner, a researcher, a coder, a reviewer, maybe a “critic” for good measure, each with a name and a persona, passing messages in a loop. The implicit promise is that more specialists means better work, the way it does in a human organisation.

For two years that promise went mostly untested. It was easy to publish a benchmark where five agents beat one, hard to publish the cases where they did not, and almost nobody counted the tokens. That changed in the last twelve months. Three pieces of work, from Google Research and MIT, from UC Berkeley, and from Anthropic’s own engineering team, now give us something close to a quantitative answer to the question every architect has been guessing at: when does adding agents actually help?

The answer is uncomfortable for the default. In a controlled study of 260 configurations, multi-agent setups ranged from 80.8% better than a single agent to 70% worse, depending on the task. Once a single agent was already clearing about 45% accuracy, adding agents tended to make things worse. A separate analysis of failing multi-agent runs found that the majority of failures had nothing to do with model capability; they were design and coordination problems. And the one widely cited production success story, Anthropic’s Research system, works precisely because its task is embarrassingly parallel, and it pays roughly fifteen times the tokens of a normal chat for the privilege.

This article pulls those findings into a decision framework you can apply before you split a task across agents. It is not an argument against multi-agent systems. It is an argument for earning them.

What 260 experiments say

The most rigorous evidence comes from “Towards a Science of Scaling Agent Systems”, a paper by Yubin Kim and eighteen co-authors from Google Research, Google DeepMind and MIT, first posted in December 2025 and revised in April 2026. Its contribution is not a new architecture but a controlled comparison of the ones we already use.

The setup is worth understanding because it is what most benchmark papers skip. The authors took six agentic benchmarks spanning financial reasoning, web browsing, planning and workplace tasks, and ran each one through five canonical architectures: a single agent, and four multi-agent topologies they call Independent (agents work alone, outputs aggregated), Centralized (an orchestrator delegates), Decentralized (peers negotiate) and Hybrid. They repeated this across three model families, for 260 configurations in total, with the detail that matters most: standardised tools and standardised token budgets. Every architecture had the same tools and the same spend. That removes the usual confound, where a multi-agent system “wins” because it quietly used ten times the compute.

Three findings stand out.

The range is enormous, and it depends on the task. Relative to the single-agent baseline, multi-agent performance ranged from +80.8% on decomposable financial reasoning to -70.0% on sequential planning. On sequential reasoning tasks, every multi-agent variant degraded performance, by between 39% and 70%. The same architecture that doubled accuracy on one benchmark destroyed it on another. There is no “best” topology; there is only alignment between topology and task structure.

Capability saturates. Once the single-agent baseline exceeded roughly 45% accuracy on a task, adding coordination yielded diminishing or negative returns. The authors fit this as a statistically significant negative coefficient. The intuition is simple: a strong model already holds the whole problem in one context window, and splitting that context into messages between agents is lossy. The paper names this the coordination tax: every hand-off compresses global state into a summary, and something is lost each time.

Tool-heavy tasks pay more tax. Tasks that required many tool calls incurred extra multi-agent overhead, because tool results now have to be relayed between agents rather than simply read by the one agent that called them.

The authors then did something unusual: they turned the findings into a predictive model and tested it on held-out configurations. It picked the best architecture 87% of the time, and the preferences held on a frontier model released after the study. That is the difference between an anecdote and a science. If you can measure your task’s decomposability, your tool density and your single-agent baseline, you can predict whether a team will help before you build one.

Why they fail: the Berkeley taxonomy

The Google study tells you whether a multi-agent system will underperform. A second paper tells you how. “Why Do Multi-Agent LLM Systems Fail?”, from Mert Cemri, Melissa Pan and colleagues at UC Berkeley, was accepted to the NeurIPS 2025 Datasets and Benchmarks track and introduced MAST, the Multi-Agent System Failure Taxonomy.

The method was borrowed from social science rather than machine learning. The authors collected execution traces from seven popular open-source multi-agent frameworks, including ChatDev, MetaGPT, HyperAgent, AG2 and others, and had six expert annotators read more than 150 of them end to end, coding failure patterns as they emerged, in the grounded-theory tradition. Inter-annotator agreement was high (Cohen’s kappa of 0.88), and the team then trained an LLM-as-judge to scale the annotation to the full dataset, which they open-sourced.

The headline number is the failure rate. Across the frameworks studied, between 41% and 86.7% of runs failed to complete their task correctly. One widely used coding framework achieved 33.3% correctness on the authors’ programming benchmark. These are not toy systems; they are the ones people copy from GitHub.

More useful than the rate is the shape of the failures. MAST sorts them into 14 modes across three categories:

1. System design and specification issues. The orchestration itself was wrong before any agent spoke: roles poorly defined, task constraints violated, conversation history lost, steps repeated. In the published breakdowns this category accounts for the largest share of failures, around four in ten.
2. Inter-agent misalignment. The agents could not coordinate: one ignored another’s input, two reasoned from different assumptions, information that one agent held never reached the agent that needed it, or the conversation derailed into something the user never asked for.
3. Task verification and termination. The system stopped too early, stopped too late, or declared success without checking. Verification was either missing or so superficial that it passed obviously wrong output.

What these three have in common is that none of them is a model problem. Swapping in a smarter LLM does not fix a role definition that overlaps with another role, or a verifier that only checks syntax. The authors proved the point by applying targeted prompt and topology fixes to two frameworks: the interventions improved task completion by about 14 percentage points but left many failures standing, which they take as evidence that the fixes required are structural redesigns, not patches.

For a practitioner, MAST is a checklist in disguise. Every one of the 14 modes is a thing you can test for before shipping: does each agent know exactly what it owns, does the orchestrator carry state across turns, does something independent verify the output, does the system know when it is done.

Read left to right as a run unfolds: the orchestration is specified, the agents coordinate, the output is checked. MAST finds failures at every stage, with the first stage, the one that happens before any model reasons at all, carrying the largest share.

The counterexample that proves the rule

If multi-agent systems are so fragile, how does anyone ship one? The best-documented answer is Anthropic’s account of how it built the Research feature in Claude. It is worth reading closely, because it is simultaneously the strongest case for multi-agent systems and the clearest statement of their limits.

The architecture is orchestrator-worker. A lead agent reads the query, writes a plan, and spins up several subagents in parallel, each with its own context window and a self-contained brief: an objective, an output format, guidance on which tools and sources to use, and explicit boundaries. The subagents do not know about each other. They return condensed findings; the lead synthesises them, and a separate pass attaches citations. On Anthropic’s internal research evaluation, this system outperformed a single agent running the same frontier model by 90.2%.

That is a real result, and the explanation Anthropic gives for it is the most honest sentence in the agent literature: multi-agent systems work mainly because they help spend enough tokens to solve the problem. In their analysis, token usage alone explained about 80% of the performance variance. Parallel subagents are a way to apply far more context than one window can hold, on a task where the pieces are independent enough that the loss from splitting is small.

The cost is stated just as plainly. Agents use about four times the tokens of a chat interaction; multi-agent systems use about fifteen times. The team’s own guidance is that the architecture excels at breadth-first queries that fan out into many independent threads, and is a poor fit for domains where every agent needs the same shared context or where there are many dependencies between agents. Their example of a poor fit is coding, where most agentic effort is spent today.

Put the three studies side by side and they agree. Research is decomposable, breadth-first and tool-heavy in a way that parallelises cleanly; that is the +80.8% end of the Google range. Coding, debugging and sequential planning share state at every step; that is the -70% end. Anthropic succeeded not by ignoring the coordination tax but by picking a task where it was worth paying.

Three questions before you split the work

The findings reduce to a short test you can run on any task before adding a second agent. Answer the three questions below in order; each one can stop you.

1. Does the task decompose into independent parts?

Not “can I describe it as stages” but “can two people work on different pieces at the same time without talking.” Searching ten sources, scoring fifty candidates, translating a document into six languages: yes. Debugging a failing test, planning a sequence of dependent actions, refactoring code where every change constrains the next: no. The Google study’s sequential-planning results and Anthropic’s warning about shared-context domains are the same finding from two directions. If the answer is no, stop. A single agent with a good harness will beat a team, and it will cost a fraction as much.

2. Does each additional agent bring new information, or just more reasoning?

Parallel agents help when they explore different territory: different sources, different hypotheses, different parts of a corpus. They hurt when they are reasoning about the same facts from the same context, because every message between them loses detail and the orchestrator ends up reconciling summaries instead of reading evidence. A quick diagnostic: if you could replace the subagents with one agent that simply thought longer, you do not need subagents. Anthropic’s finding that tokens explain 80% of performance cuts both ways here. Sometimes the cheapest way to spend more tokens is a bigger context and a longer loop, not a committee.

3. What is your single-agent baseline, and can you afford the multiplier?

Get Kameshwar Singh’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Measure the single agent first. If it is already above roughly 45% on your eval, the Google data says a team is more likely to hurt than help. If it is below that, a team might help, but you then have to clear the economic bar: is the task valuable enough to justify something in the range of four to fifteen times the token spend, plus the engineering cost of orchestration, state management and failure handling that MAST catalogues? For a research product sold at a premium, yes. For a customer-support triage flow handling a million tickets a month, almost certainly not.

Only if all three answers favour a team should you build one. And when you do, the Berkeley taxonomy tells you what to build in from the start: unambiguous role boundaries, state that survives hand-offs, and a verifier that is independent of the agents it checks.

Three questions stand between a task and a second agent

A “no” at any question routes to a single-agent design; only three consecutive “yes” answers justify an orchestrator with parallel workers, and even then the Berkeley failure modes have to be designed out from the start.

What a harness gives you that a team does not

The phrase that has replaced “multi-agent” in the more careful engineering conversations of 2026 is harness: the deterministic scaffolding around a single model that gives it the reliability a team was supposed to provide. The distinction matters because most of what people reach for a second agent to do can be done by code.

Decomposition without delegation. A planner agent that breaks a task into steps and hands them to a worker is two LLM calls where one would do, plus a lossy hand-off. The alternative is a single agent with an explicit, machine-maintained plan in its context: a task list it reads and updates, held by the harness rather than reconstructed from conversation. The model gets the benefit of structure without the coordination tax.

Verification without a “critic” agent. The MAST data shows that task verification is one of the three big failure categories, and the usual fix is to add a reviewer agent. But a reviewer that shares the author’s model, prompt lineage and blind spots is a weak check. Deterministic verification is stronger wherever it is available: run the tests, execute the code, check the schema, diff against a known-good output, validate the citation resolves. Reserve an LLM judge for the parts that cannot be checked mechanically, and give it a fresh context so it is grading the output, not its own reasoning.

Parallelism without agents. Half the value of Anthropic’s subagents is simply that they run concurrently. A single agent that issues parallel tool calls, with the harness fanning out the requests and collecting results, gets most of the speed-up with none of the inter-agent messaging. The subagent pattern earns its keep only when each parallel thread needs its own context window because the material exceeds what one window can hold.

Memory without a shared blackboard. Multi-agent designs often introduce a shared memory store so agents can coordinate, and then spend their failure budget on agents reading stale or conflicting entries. A single agent with a harness-managed scratchpad and a compaction step when context fills has one source of truth by construction.

When should you graduate from a harnessed single agent to a real team? The honest answer from the evidence is: when the material will not fit, and the task will split. If a single context window cannot hold what the task needs to read, and the reading can be partitioned into pieces that do not depend on each other, you have Anthropic’s situation, and an orchestrator with isolated workers is the right tool. Until then, you are paying the tax without receiving the service.

The one-page checklist

Before adding a second agent to a system, confirm:

• The single-agent baseline is measured on a real eval set, not estimated.
• That baseline is below roughly 45% on the task, or the task’s material exceeds one context window.
• The task decomposes into pieces that can be worked on without sharing state mid-flight.
• Each additional agent will gather different information, not re-reason over the same facts.
• The expected quality gain is worth a 4x to 15x token multiplier plus the orchestration engineering.
• Every agent has a role boundary a stranger could state in one sentence.
• Plan and task state live in the harness, not only in conversation history.
• Output is verified by something independent of the agents that produced it, deterministically where possible.
• The system has an explicit, testable termination condition.
• You have tried parallel tool calls from a single agent first.

If any box is unchecked, the evidence says build the single agent better.

Earn the team

The multi-agent default took hold because it maps onto how we think about human work, and because for a while nobody measured the alternative. Now the measurements exist, and they are consistent across three independent groups with different incentives: a research lab studying scaling laws, a university cataloguing failures, and a company that actually ships a multi-agent product and wants to explain why it works.

The lesson is not that agents should work alone. It is that coordination is a cost, paid in tokens and in lost context, and like any cost it needs a return. On breadth-first, decomposable, information-heavy tasks the return is large and the architecture is settled. On the sequential, state-sharing work that makes up most of what engineering teams actually automate, the return is negative and the architecture is a liability dressed as sophistication.

Start with one agent and a good harness. Measure it. Then, if the numbers tell you to, add the second agent, and know exactly why you did.

Figures in this article are taken from the papers and posts cited below as of November 4, 2026. The Anthropic result is from an internal evaluation, not a public benchmark, and the MAST failure rates were measured on different benchmarks per framework and are not directly comparable to each other.

References

1. Kim, Y. et al., Towards a Science of Scaling Agent Systems, arXiv:2512.08296, v3 April 8, 2026
2. Kim, Y. et al., full text (HTML), with the 45% capability-saturation threshold and the +80.8% / -70.0% range
3. Cemri, M., Pan, M. Z. et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657, NeurIPS 2025 Datasets and Benchmarks
4. MAST taxonomy, code and MAST-Data on GitHub
5. Anthropic Engineering, How we built our multi-agent research system, June 2025
6. Simon Willison, notes on Anthropic’s multi-agent research system, June 14, 2025
7. ZenML LLMOps Database, Building Production Multi-Agent Research Systems with Claude
8. alphaXiv overview, Towards a Science of Scaling Agent Systems