Why do multi-agent systems fail more often than a single agent?

Splitting work across a team of agents feels like the obvious upgrade. In practice every handoff is a new place to fail. Here is what the failure data actually shows, and when more agents genuinely pay off.

B

Balagei G Nagarajan

4 MIN READ


Several agents passing work between each other, with the handoffs lighting up as the points where the task breaks
7% of all cases, where agents redo work because no one owns the state.
— from “Why do multi-agent systems fail more often than a single agent?”
 <p><b>Key facts.</b></p>
 <ul>
   <li>Across 1,642 annotated traces from seven popular multi-agent frameworks, failure rates ran 41% to 86.7%, with one benchmark (AppWorld) failing 86.7% of the time (Cemri et al., <a href="https://arxiv.org/abs/2503.13657" target="_blank" rel="noopener">MAST</a>, 2025).</li>
   <li>The failures cluster into three buckets: system design 41.8%, inter-agent misalignment 36.9%, and task verification 21.3%. The single most common mode is step repetition at 15.7%, followed by reasoning-action mismatch at 13.2% (<a href="https://arxiv.org/abs/2503.13657" target="_blank" rel="noopener">MAST</a>).</li>
   <li>Multi-agent is not always worse. Anthropic's orchestrator-worker research system beat a single-agent Claude Opus 4 by 90.2% on their internal research eval, on breadth-first tasks that parallelize well (<a href="https://www.anthropic.com/engineering/multi-agent-research-system" target="_blank" rel="noopener">Anthropic Engineering</a>, 2025).</li>
   <li>That win is not free: the same system burned roughly 15 times the tokens of a chat, versus about 4 times for a single agent (<a href="https://www.anthropic.com/engineering/multi-agent-research-system" target="_blank" rel="noopener">Anthropic</a>), and the Cognition team argues most multi-agent setups are fragile because context cannot be shared thoroughly enough between agents (<a href="https://cognition.ai/blog/dont-build-multi-agents" target="_blank" rel="noopener">Don't Build Multi-Agents</a>, 2025).</li>
 <li><!-- conviction-start -->MAST found 41 to 86.7% failure; the handoff bug outlives a newer model.<!-- conviction-end --> (<a href="https://arxiv.org/abs/2503.13657" target="_blank" rel="noopener">arXiv:2503.13657</a>)</li></ul>
 <h2>Why does adding agents add failures?</h2>
 <p>Every agent boundary is a new interface. When one agent hands work to another, it passes a compressed summary, not its full reasoning. The receiving agent fills the gaps with its own assumptions. MAST put numbers on this: 36.9% of failures were inter-agent misalignment. One agent ignoring another's input. Quietly resetting the conversation. Derailing the task. Another 41.8% were system design issues: agents disobeying the task spec or never recognizing the task was done. A single agent carries one continuous context and never has to re-explain itself to a teammate. That entire class of failure does not exist for it.</p>
 <h2>What actually goes wrong between agents?</h2>
 <p>The most common failure is mundane. Step repetition, 15.7% of all cases, where agents redo work because no one owns the state. Close behind: reasoning-action mismatch at 13.2%. An agent says one thing, does another, and the next agent trusts the words. Roles blur, so two agents solve the same piece and conflict, or each assumes the other handled it. Cognition's team illustrated this with a Flappy Bird clone where one sub-agent built a Super Mario style background because nothing pinned down shared intent. None of this is a weak model. It is the cost of splitting one coherent task across agents that cannot see each other's full context.</p>
 <div class="fig"><img src="/blog/article5-diagram.png" alt="A multi-agent path of several connected agents passing work, above a single-agent path running one continuous thread"/></div>
 <h2>So when do more agents actually help?</h2>
 <p>When the work is genuinely parallel and wider than one context window. Anthropic's research system beat a single Claude Opus 4 by 90.2% on breadth-first queries. A lead agent spawns sub-agents that each explore an independent direction at the same time, then synthesizes. That win comes specifically from tasks that decompose into chunks that do not depend on each other. The tell is independence. If subtasks can run without talking to each other and only meet at the end, multi-agent shines. If each step depends on the last, you are adding handoffs to a chain that wanted to stay whole.</p>
 <h2>Single agent or many? The honest comparison.</h2>
 <table style="width:100%;border-collapse:collapse;margin:1.5rem 0;font-size:0.97rem;"><tr><th style="text-align:left;padding:10px 12px;border-bottom:2px solid #e5e7eb;color:#5E6AD2;font-weight:600;">Dimension</th><th style="text-align:left;padding:10px 12px;border-bottom:2px solid #e5e7eb;color:#5E6AD2;font-weight:600;">Single agent</th><th style="text-align:left;padding:10px 12px;border-bottom:2px solid #e5e7eb;color:#5E6AD2;font-weight:600;">Multi-agent</th></tr>
   <tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Best for</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Sequential, tightly-coupled work</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Parallel, independent subtasks</td></tr>
   <tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Failure surface</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">One chain, compounding errors</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Every handoff adds coordination failures</td></tr>
   <tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Context</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">One continuous thread</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Fragmented, re-summarized at each seam</td></tr>
   <tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Cost</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">About 4x a chat in tokens</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Around 15x; coordination is expensive</td></tr>
   <tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Right default</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Yes, start here</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Only when the work is truly parallel</td></tr>
 </table>
 <p>One agent with the right tools and full context is the stronger baseline for most work. Reach for a team only when the task genuinely splits into independent pieces. Which workflows decompose cleanly and which only look like they do is a pattern question, not a framework question. That is the reliability VibeModel builds as the Pattern Intelligence Layer: which parts of a workflow are safe to parallelize and which must stay whole.</p>
 <aside class="jaside v-warn"><span class="col"><svg class="hook" width="28.5" height="34.5" viewBox="0 0 57 69" fill="none" preserveAspectRatio="none" xmlns="http://www.w3.org/2000/svg"><path fill="var(--pageBg)" d="M54 0V0.716804C54 25.9434 35.0653 47.1517 10 50L0 57V0H54Z"/><path fill="var(--acc)" d="M56.9961 4.15364C57.0809 2.49896 55.8083 1.08879 54.1536 1.00394C52.499 0.919082 51.0888 2.19168 51.0039 3.84636L56.9961 4.15364ZM9.09704 51.7557L8.49716 48.8163L9.09704 51.7557ZM6 69V59.2227H0V69H6ZM9.69692 54.6951L14.3373 53.7481L13.1375 47.8693L8.49716 48.8163L9.69692 54.6951ZM14.3373 53.7481C38.202 48.8777 55.7486 28.4783 56.9961 4.15364L51.0039 3.84636C49.8967 25.4384 34.3213 43.5461 13.1375 47.8693L14.3373 53.7481ZM6 59.2227C6 57.0268 7.54537 55.1342 9.69692 54.6951L8.49716 48.8163C3.55195 49.8255 0 54.1756 0 59.2227H6Z"/></svg><span class="rail"></span></span><span class="glyph"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="m21.73 18-8-14a2 2 0 0 0-3.48 0l-8 14A2 2 0 0 0 4 21h16a2 2 0 0 0 1.73-3Z"/><path d="M12 9v4"/><path d="M12 17h.01"/></svg></span><h4>Watch out</h4><p>They fail more on tightly-coupled, sequential work because of coordination overhead, but they win on genuinely parallel tasks.</p></aside>

Frequently asked questions

Are multi-agent systems just worse than single agents?
No. They fail more on tightly-coupled, sequential work because of coordination overhead, but they win on genuinely parallel tasks. Anthropic's research system beat a single agent by 90.2% on breadth-first queries. The question is whether your task decomposes into independent pieces.

What is the most common multi-agent failure?
Step repetition, 15.7% of cases in the MAST study, where agents redo work because no one clearly owns the state. Most multi-agent failures are coordination and verification problems, not weak models.

If multi-agent can score higher, why not always use it?
Cost and fragility. The same system that scored higher used roughly 15 times the tokens of a chat, and context cannot be shared fully between agents, so subtasks drift on conflicting assumptions. The gain only shows up when the work is truly parallel.

How do I decide between one agent and many?
Test for independence. If the subtasks can run without talking to each other and only combine at the end, multi-agent helps. If each step depends on the previous one, keep it a single agent and avoid the handoffs.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.