More Agents Isn’t Better: The Coordination Tax

In the summer of 2025 two of the most credible teams in the field published, within weeks of each other, directly opposite advice. Anthropic explained how a swarm of agents beat a single one by ninety percent. Cognition published a piece titled, more or less, don’t build swarms of agents. If you were trying to decide how to architect an agent product, this was maddening. It is also the most useful disagreement in the field, because the resolution is a rule you can actually use.

01The architecture war, and its truce

Anthropic reported that an orchestrator–worker system — a lead agent spawning parallel sub-agents, each with its own context window — outperformed a single agent by 90.2% on an internal research eval vendor. Their own honest caveat: it’s the wrong choice when agents must share context or have many dependencies, “most coding tasks” included.

Cognition’s counter, from building Devin: parallel sub-agents can’t see each other’s decisions, so they produce mutually inconsistent work — ask two sub-agents to build a game and one returns Mario art for a Flappy Bird clone verified. Their prescription is a single continuous-context thread; if it overflows, compress, don’t split. Academia tempers everyone: multi-agent debate rarely beats a strong single-agent self-consistency baseline without careful tuning.

02The coordination tax

The defining economic fact: multi-agent systems buy performance mainly by spending more tokens. Anthropic’s disclosure that token usage alone explains ~80% of performance variance means quality and cost are nearly the same dial.

So the break-even rule writes itself: multi-agent pays only when task value > ~15× token cost AND the work is genuinely parallel with low inter-agent dependency. This is the quiet force behind outcome-based pricing — nobody will pay per token for a 15× multiplier, so vendors must price the result.

02Why multi-agent fails: it’s a design problem

UC Berkeley’s MAST study hand-annotated 1,600+ traces across seven frameworks and distilled 14 failure modes in three buckets. The counterintuitive headline: a stronger base model rarely fixes them — structural redesign (+15.6%) beats prompt-patching (+9.4%) verified.

The middle bucket — agents withholding information, ignoring peers, never asking for clarification — is the failure surface that cannot exist in a single agent. The most common single modes are step repetition (~17%) and reasoning–action mismatch (~14%, where the chain-of-thought says one thing and the tool call does another). And verifier agents mostly rubber-stamp: they check “does it compile?” not “is it correct?”

04The plumbing standardized — and so did the attack surface

Underneath the debate, the protocols consolidated fast and complementarily: MCP for agent-to-tool, A2A for agent-to-agent (donated to the Linux Foundation, 150+ orgs; IBM’s ACP merged into it), with the decentralized ANP trailing. The mantra: “MCP inside each agent, A2A between agents” verified.

But a swarm is not one agent × N — it’s a qualitatively larger attack surface. Because inter-agent channels are trusted and unfiltered, a prompt injection can self-replicate as a worm: in one study, an infection saturated a 50-agent society by turn ~11 and drove harmful actions in >80% of cases.

05The build / don’t-build rule

• Default to one agent. If you can’t name which sub-tasks are independent, you have a context-engineering problem, not a multi-agent one.
• Keep writes single-threaded. Add agents as read-only intelligence — research, critique, verification — never as parallel actors mutating shared state. This “single-writer” rule resolves most of the debate.
• Fan out only for independent breadth (research, large sweeps), and budget the ~15× tokens.
• For a second opinion, sample one model (self-consistency) before reaching for debate.
• Multiply only what you can verify. If reconciling conflicting outputs is itself hard, more agents add risk, not value.