AskpertWhen Not to Build a Multi-Agent System
Multi-agent architectures fail for structural reasons, not weak models. Here is what the research measured across five frameworks, why better prompts only partly help, and the threshold where multiple agents genuinely earn their cost.
On this page
Terms, definedthe jargon, decoded
- Multi-agent system
- An architecture where several AI agents each handle part of a task and pass work between them, usually coordinated by a lead agent.
- Single agent
- One agent that handles the whole task itself, using tools and careful context management rather than delegating to peer agents.
- Coordination boundary
- The seam where one agent hands work to another. Each seam is a place state can be lost, distorted, or go stale.
- Inter-agent misalignment
- A failure where agents are individually working correctly but on incompatible understandings of the task.
- Task verification
- Checking that a stage's output is actually correct before the next stage builds on it.
Multi-agent architecture is the default aspiration in AI engineering right now. Gartner recorded a 1,445% surge in multi-agent system inquiries between Q1 2024 and Q2 2025, and separately predicts that more than 40% of agentic AI projects will be canceled by the end of 2027 on cost and unclear business value.
This is the counter-case, argued from evidence rather than taste. It is not an argument that multi-agent systems are bad. It is an argument that there is a threshold, that most systems sit below it, and that the honest engineering move is usually one capable agent.
Why do multi-agent systems fail?
They fail on coordination and specification, not on model quality. "Why Do Multi-Agent LLM Systems Fail?" analysed five popular frameworks (MetaGPT, ChatDev, HyperAgent, AppWorld and AG2) across more than 150 tasks with six expert human annotators, and built the MAST taxonomy: 14 distinct failure modes in three categories. Specification and system design accounts for five of them, inter-agent misalignment for six, and task verification and termination for three.
The finding that should change your plans is what the authors say about the distribution: no single error category disproportionately dominates. There is no one bug to fix. The failures are spread across how the system was specified, how the agents understood each other, and whether anyone checked the output, which is what "structural" means in practice.
How bad does it get in a real system?
Bad enough to be worth quoting directly. The paper reports that the correctness of a state-of-the-art open-source multi-agent system, ChatDev, "can be as low as 25%" on its ProgramDev benchmark. That is a well-regarded system, not a toy, producing a usable result one time in four.
The more interesting number is what happened when the researchers tried to fix it. Improved prompting lifted ChatDev from 25.0% to 34.4%. A redesigned agent topology reached 40.6%. Both interventions worked, and neither got the system past a coin flip.
| Intervention | ChatDev on ProgramDev |
|---|---|
| Baseline | 25.0% |
| Improved prompts | 34.4% |
| New topology | 40.6% |
Read that as a warning about the usual remedies. When your multi-agent system underperforms, prompt engineering and re-drawing the org chart are the two things you will reach for. They are worth real points and they did not rescue this system, because the defects were in the architecture rather than the wording.
What actually breaks when you split one agent into several?
State and meaning break at the handoffs. Four patterns recur, and they are the practical shape of what MAST calls inter-agent misalignment. One agent receives another's full conversation history rather than a focused summary, and drowns. Context that one agent discovered never reaches the agent that needed it. Information from an earlier stage goes stale after a later stage supersedes it. And one agent communicates a finding that the next interprets under a different schema, quietly distorting its meaning.
The last of these is the dangerous one, because nothing errors. The receiving agent reasons confidently from a corrupted premise and produces a clean, well-formatted, wrong answer. A downstream agent then builds on it. By the time the mistake is visible it has been laundered through three handoffs, which is why these systems are so much harder to debug than the single-agent version.
When does a single agent win?
On most real tasks, and for reasons that have nothing to do with model capability. With one agent the whole trajectory sits in one place, so you can read what happened. There is no serialization cost, no routing overhead, and no context transfer burning tokens at every boundary. When it goes wrong, it goes wrong where you can see it.
Cognition, the team behind the Devin coding agent, argued this directly in "Don't Build Multi-Agents" and later documented what changed in "Multi-Agents: What's Actually Working." The core claim is that adding agent boundaries adds error-compounding seams, and the same compounding arithmetic that governs tool selection across a long catalog applies here: small per-stage losses become large task-level failure rates.
| Dimension | Single agent | Multi-agent |
|---|---|---|
| Coordination overhead | None, one context | High, every handoff is a failure seam |
| Traceability | Full trajectory in one place | Errors propagate before surfacing |
| Cost per task | One context, no serialization | Tokens spent on handoffs and routing |
| Best-fit task | One coherent job | Independent, parallel, or isolated subtasks |
| Main risk | Context overflow | Coordination and specification defects |
The single agent's real constraint is context, not coordination. That makes it the failure mode you already know how to manage, with progressive loading and a memory layer rather than an org chart.
When does multi-agent genuinely earn its cost?
When the task decomposes into subtasks that are actually independent and whose outputs can be verified separately. Anthropic documented its multi-agent research system doing exactly this: a lead agent splits a question into parallel subtopics, separate agents retrieve and summarise each one, and a synthesis step combines them. It works because the subtopics do not depend on each other and each result can be checked on its own.
Three cases justify the cost. Parallel research and retrieval, where the subtasks genuinely do not interact. Distinct tooling or security boundaries, where you want an agent that cannot reach something. And a task that exceeds one context window but decomposes into stages with contractable outputs. Microsoft's decision guidance and LangChain's architecture guide both land in the same place: start with a single agent and escalate only on evidence.
What is the decision rule?
Four questions, and a single agent wins unless every answer is yes. Can the task split into genuinely independent subtasks? Does each subtask need its own context, toolset, or security boundary? Can you write an explicit, verifiable contract for each output? Do you have automated validation of each stage before the next one consumes it?
If any answer is no, you are about to build the failure modes the MAST work catalogued. Subtasks that share state, depend on an upstream stage that can go stale, or lack a clean output contract are the specification and misalignment categories, restated as your architecture diagram. Start with one agent, find the actual bottleneck, and escalate against that evidence rather than the ambition. If you do split the work, the practical rules for running subagents cover where parallel execution is safe.
When should you not use a multi-agent system?
Do not use one when a single agent can finish the task with careful context management. If your subtasks share state, depend on each other's outputs, or lack a verifiable handoff contract, you have recreated the coordination failures that research across five frameworks catalogued as 14 distinct failure modes. Start with one agent and escalate only when you have measured a real bottleneck.
What causes most multi-agent system failures?
They fail on specification and coordination rather than model quality. The MAST taxonomy identifies 14 failure modes across specification and system design, inter-agent misalignment, and task verification, and reports that no single category dominates. Context handoff, stale state, and schema mismatch between agents are the recurring practical causes, and none of them has one fix.
Are multi-agent systems better than single-agent systems?
Not generally. Research found the correctness of a leading open-source multi-agent system falling as low as 25%, with improved prompts reaching 34.4% and a redesigned topology 40.6%. A single agent keeps the whole trajectory in one place, costs less because nothing is spent on handoffs, and fails in ways you can actually see.
Can better prompts fix a multi-agent system?
Only partly. In the published evaluation, improved prompting lifted a system from 25.0% to 34.4% correctness and a redesigned topology reached 40.6%. Both are real gains and neither passed a coin flip, because the defects were architectural rather than in the wording. Treat prompt fixes as tuning, not as a repair for a structural problem.
When is a multi-agent system worth building?
When subtasks are genuinely independent, each needs its own context, tools or security boundary, and every output has a verifiable contract with automated validation. Parallel research and retrieval is the clearest case, which is the pattern Anthropic documented for its multi-agent research system. If any of those conditions fails, a single agent is the lower-risk build.