The hype said: decompose every task, spin up specialists, let them collaborate, debate, and synthesize. Then the controlled studies landed: 260 configurations, seven papers, matched compute budgets. The verdict is blunt. Coordination helps only under narrow structural conditions, and most of the “intelligence” was redundant rearrangement of the same information. This is the reckoning, by the numbers.
“More agents means more intelligence.”
For two years the dominant architectural instinct in agent design has been to multiply. Decompose the task, assign each piece to a specialist agent, let them collaborate, debate, and synthesize. Enterprise adoption followed the instinct: one platform reported a 327% increase in multi-agent workflow usage in four months, drawing on telemetry from more than 60% of the Fortune 500. The pattern spread faster than anyone validated it.
Then the controlled studies arrived, and they're brutal in the way only matched-budget experiments can be. The headline result, from a Google Research / MIT study spanning 260 configurations across six agentic benchmarks and three model families, with single- and multi-agent systems given equal total compute: multi-agent coordination helps only under specific structural conditions, and outside those conditions it ranges from neutral to catastrophic. Performance across the 260 runs spanned from −70% to +80.8% depending on task structure and topology.
The “equal compute” part is what makes this credible. Most earlier claims for multi-agent superiority compared a multi-agent system to a single agent without normalizing the total tokens spent. Give the multi-agent system five agents' worth of compute and of course it looks better: it had five times the thinking budget. An information-theoretic follow-up put it bluntly: many reported multi-agent advantages are better explained by unaccounted computation and context effects than by any inherent architectural benefit. When you give a single agent the same total budget the multi-agent system burns, the single agent often matches or beats it.
Five topologies, measured.
The cleanest way to read the data is by coordination topology. Each is a structural variation on two questions: is there an orchestrator, and do the agents talk to each other? The numbers below are from the matched-compute study: mean performance, error amplification (how much a single mistake compounds), and token overhead versus a single-agent baseline.
| Topology | What it is | Error amp. | Token overhead | Verdict |
|---|---|---|---|---|
| Single-agent | One agent, no coordination. The baseline. | 1.0× | n/a | Default |
| Centralized | Orchestrator decomposes, assigns, synthesizes. Verification bottleneck. | 4.4× | Conditional | |
| Decentralized | All-to-all peer debate, rounds of exchange toward consensus. | 7.8× | Narrow | |
| Hybrid | Orchestrator + peer communication. Most flexible, most expensive. | 5.1× | Rarely | |
| Independent | Parallel agents, no communication, outputs merged. Errors duplicate uncorrected. | 17.2× | Avoid |
Two things jump out. First, the cheapest multi-agent topology is also the most dangerous. Independent MAS adds “only” 58% token overhead, but with no orchestrator to catch mistakes, a single agent's error gets duplicated across the fleet and amplified 17.2×. It's the worst mean performer in the study. The thing teams reach for first because it's simple is the thing the data says to avoid.
Second, the orchestrator earns its keep as a verification bottleneck, not a coordinator. Centralized MAS contains error amplification to 4.4× precisely because a single agent reviews everything before it propagates. But that containment costs 285% in tokens. You're paying nearly 3× the compute to buy a checker. Whether that's worth it depends entirely on the task.
Decomposability, not complexity.
The single most useful finding in the whole literature is what separates the tasks where multi-agent wins from the tasks where it collapses. It isn't difficulty. Two benchmarks in the study had nearly identical domain-complexity scores (0.41 and 0.42) and produced opposite results. One gained +80.8% from coordination. The other lost up to 70%.
The rule that falls out: multi-agent coordination only pays when the task naturally decomposes into independent subtasks. If the work is a sequential chain where each step needs the last step's output, splitting it across agents introduces coordination overhead that fragments what should be a single clean trajectory. Conceptual modularity isn't enough either: if each sub-agent still needs most of the same context and the synthesis step is expensive, you've modularized the diagram without parallelizing the work.
This is the same lesson as our note on why we stopped writing custom orchestrators, arriving from a different direction. There, the argument was that building a bespoke runtime trades control for maintenance surface. Here, the argument is that adding agents trades a clean trajectory for coordination surface. Both are versions of one principle: complexity you add to the architecture has to earn its place against a strong simple baseline, and usually can't.
What a single accuracy point costs.
Even where multi-agent wins on accuracy, the win has a price tag, and the price tag is often the whole story. The benchmark gains have to clear an economic bar, and the bar is high.
That 2.1-point gain at roughly 2× the cost is the recurring shape across the literature, and it gets worse, not better, over time. There's a counterintuitive long-term implication buried in the data: as frontier models improve, the bar for multi-agent to add value rises. Coordination yields diminishing returns once a single-agent baseline clears roughly 45% on these benchmarks. Above that threshold the model is already capable enough that coordination overhead outweighs the benefit. Every model release pushes more tasks above the line where adding agents stops helping.
And the token cost is only the visible part. Multi-agent systems expand the debugging surface in a way that's easy to underestimate. When an output is wrong, you have to reconstruct which agent saw which state, which handoff introduced the error, and whether the failure came from reasoning, routing, or a stale context snapshot. Coordination becomes a distributed-systems problem (synchronization, handoff fidelity, replayability) on top of the reasoning problem. That maps directly onto our note on cost as a first-class metric: every coordinating agent is more steps on the trace, and the orchestration overhead is exactly the kind of invisible spend the cost tracer exists to surface.
Three principles that held across families.
The study extracted three scaling principles that were consistent across OpenAI, Google, and Anthropic model families: coefficient of variation under 0.02, meaning these are structural facts about coordination, not quirks of one model.
It isn't one paper.
A single study, however well-controlled, is a data point. What makes this a reckoning rather than a result is that six independent research efforts reached complementary conclusions in the same window. The convergence is the signal.
Read together, the pattern is unambiguous: multi-agent benefits are highly conditional, compute normalization is essential for honest evaluation, architecture matters more than agent count, and single-agent baselines are stronger than the hype assumed. The debate finding is the one that stings most. The entire justification for multi-agent review architectures was independent verification, and the data says the agents mostly just agree with each other.
The decision rule that's left.
None of this means multi-agent is dead. It means the default flipped. The 2026 production rule is: start with a strong single agent, and make the architecture earn every added agent. “Strong single agent” is load-bearing. It means optimized tool use, good retrieval and context engineering, caching, a local verifier loop, and skill-based routing all in place before you reach for a second agent.
The phased migration the literature recommends is exactly the discipline the custom-orchestrators note argued for with runtimes: establish a single-agent baseline, pilot multi-agent on your single highest-ROI workflow only, measure incremental cost against incremental accuracy, and expand only if the value clearly clears the cost. The common failure is adopting multi-agent org-wide before validating it helps on even one workflow.
If you're staring at a multi-agent diagram and wondering whether it should be one box, the contact form is the fastest way in. We do 30-minute reviews for production agent stacks, free.