Why One AI Agent Isn't Enough: The Case for Multi-Agent Systems

Ask two of the most credible names in AI agent engineering whether you should build a multi-agent system, and you'll get two confident, opposite answers — both backed by real production data.

The case for multiple agents

Anthropic's own engineering team published a detailed account of how they built Claude's multi-agent Research system, and the headline number is hard to ignore: a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent working alone by 90.2% on Anthropic's internal research evaluation. Their explanation is intuitive — research is a "breadth-first" problem where pursuing several independent leads in parallel beats working through them one at a time, and subagents operating in separate context windows can each dig deep without crowding each other out.

A separate, independently conducted study points the same direction from an entirely different field. Researchers at the Icahn School of Medicine at Mount Sinai, publishing in npj Health Systems in March 2026, compared a single all-purpose clinical AI system against a coordinated network of specialized agents overseen by an orchestrator, under simulated hospital workloads of up to 80 simultaneous tasks. The single agent's accuracy collapsed to 16% at peak load while burning 65 times more compute than the orchestrated system, which held its accuracy steady. As co-author Mahmud Omar put it: "When a single agent handles everything, you can't trace where it went wrong. With the orchestrator, every step is logged... that kind of transparency isn't optional in medicine."

The case against it

But Anthropic's own post includes the caveat that undercuts a blanket "always go multi-agent" reading: multi-agent systems used roughly 15 times more tokens than a simple chat interaction in their data, and the gains only pay for themselves on tasks valuable enough to justify that cost. Anthropic is explicit that domains requiring shared context or tight dependencies between steps — most coding tasks, for instance — are "not a good fit for multi-agent systems today."

Cognition, the company behind the coding agent Devin, goes considerably further. In Don't Build Multi-Agents, engineer Walden Yan argues that splitting a task across agents that can't see each other's full context is what causes it to break, not what makes it scale — his example is two subagents asked to jointly build a Flappy Bird clone, each unaware of the other's stylistic choices, producing mismatched, unusable results. Cognition's prescription is close to the opposite of Anthropic's architecture: default to a single-threaded agent with continuous context, and only reach for added complexity — like a dedicated model that compresses history into a shared summary — once a single agent genuinely runs out of context window.

An April 2026 study on arXiv adds a methodological wrinkle to the debate: when researchers normalized for the amount of "thinking" compute each approach was allowed to use, single-agent systems matched or beat multi-agent architectures on multi-hop reasoning tasks across three separate model families. Their conclusion was blunt — many of the multi-agent performance gains reported elsewhere are better explained by the extra compute multi-agent setups quietly consume than by any architectural advantage.

Reconciling the two camps

Read together, the disagreement is less about whether multi-agent systems work and more about what kind of task is in front of you. Anthropic's and Mount Sinai's wins both come from breadth-first, loosely-coupled work — independent research threads, or independent clinical subtasks like retrieval, extraction, and dosing calculations — where subagents genuinely don't need to know what each other are doing moment to moment. Cognition's warning and the arXiv paper's finding both target tightly-coupled work — like writing one coherent piece of software — where every decision depends on the last one, and splitting that across agents with partial context creates exactly the kind of contradictions Cognition's Flappy Bird example illustrates.

What this means for teams building with AI agents going forward

The decision isn't "multi-agent or not" in the abstract — it's whether the task in front of you decomposes into pieces that can run genuinely independently, or whether every step depends on full awareness of the last. Breadth-first, parallelizable, high-value work is where the evidence for multi-agent orchestration is strongest. Sequential, tightly-coupled work is where a single well-context-engineered agent, or Cognition's compression-based scaling approach, still wins. Getting that classification right, before architecting the system, is what separates the 90% performance gain from the fragile, contradiction-prone system both camps warn about.

Frequently asked questions

Do multi-agent AI systems really outperform single agents? It depends on the task. Anthropic measured a 90.2% improvement on breadth-first research tasks, and Mount Sinai measured sustained accuracy under heavy clinical workloads where a single agent's accuracy collapsed — but an April 2026 arXiv study found single agents matched or beat multi-agent setups on tightly-coupled reasoning tasks once compute was held equal.

Why wouldn't you always use a multi-agent system if it can perform better? Cost and coordination risk. Anthropic reports multi-agent systems use about 15 times more tokens than a simple chat interaction, and tasks requiring shared context or step-by-step dependencies are prone to the kind of miscommunication Cognition's research highlights.

What kind of tasks are the best fit for multi-agent systems? Breadth-first work with genuinely independent subtasks — research that branches into multiple threads, or clinical workloads that split cleanly into retrieval, extraction, and calculation — rather than sequential work like writing a single piece of code.