Multi-agent architecture gets treated as a natural upgrade from single-agent systems — more agents, more capability, better results. The data says otherwise. For a large and predictable class of tasks, adding agents makes things slower, more expensive, less reliable, and harder to debug. For a specific, narrower class of tasks, multi-agent is necessary and clearly superior.
This post documents where that line is, with numbers. You should finish reading knowing which architecture to choose for your system — not with a framework that tells you to “consider your requirements.”
The Real Costs of Multi-Agent Architecture
Before discussing when multi-agent wins, document what it costs. Most coverage skips this part.
Error Amplification
When a single agent makes an error, that error affects one context. When independent agents make errors, those errors multiply and compound across the network. A comprehensive study spanning 180 configurations across five agent architectures found that independent multi-agent systems amplified errors 17.2x relative to single-agent baselines, while centralized coordination contained amplification to 4.4x [1]. Neither number is good. Single-agent contains errors by definition — they stay in one reasoning chain.
This is not a failure of implementation. It is structural. Each agent brings its own reasoning errors, hallucinations, and misinterpretations. In a networked system, these feed downstream. An agent acting on a misread task brief produces an output that the next agent treats as ground truth.
Coordination Overhead at Scale
In densely connected multi-agent networks, communication cost grows quadratically with agent count. A system with 10 agents doesn’t have 10x the coordination cost of a single agent — it potentially has 100x. Real systems avoid full-mesh topologies, but any multi-agent design requires explicit choices about who talks to whom, when, and how to resolve conflicts. Each of those choices is an engineering surface that single-agent systems do not have.
Message passing latency compounds at every hop. A task requiring three sequential agent handoffs pays three round-trip costs before producing output. In production, this translates directly to user-facing latency and API cost.
Sequential Reasoning Degradation
Here is the most underappreciated finding in the literature: for sequential reasoning tasks, every multi-agent variant degraded performance by 39-70% compared to single-agent [1]. Not some variants. Every variant tested — independent, centralized, decentralized, and hybrid architectures all performed worse than a single capable agent on tasks requiring step-by-step reasoning.
The mechanism is context fragmentation. Splitting a sequential task across agents splits the reasoning chain. Agent B cannot hold Agent A’s full reasoning in context — it receives a summary, an output, a structured handoff. Reassembly is lossy. The single agent that reasoned through steps 1-5 builds understanding that doesn’t survive translation to the next agent’s prompt.
Failure Mode Multiplication
Single-agent systems have well-understood failure modes: hallucination, context overflow, tool misuse, prompt drift. Multi-agent systems inherit all of these at per-agent granularity, then add a layer of coordination-specific failures on top.
A systematic study of 1,600+ annotated execution traces across seven multi-agent frameworks identified 14 distinct failure modes organized into three categories [2]:
- Specification and system design failures: Underspecified agent roles, conflicting objectives baked into different agents’ system prompts, missing tool definitions that agents assume will be handled downstream.
- Inter-agent misalignment: Agents pursuing incompatible interpretations of the same task, state synchronization failures where two agents act on stale views of system state, message format mismatches that silently corrupt data across handoffs.
- Task verification and termination failures: No agent owns quality control for the final output. Systems loop indefinitely because no agent is designated to assess completion. Errors caught late in the pipeline require expensive upstream re-execution.
These failure modes do not exist in single-agent systems. A single agent cannot have inter-agent misalignment. It cannot have orphaned verification responsibilities. The coordination failure modes are not edge cases — they account for a substantial share of production failures in observed systems.
ChatDev, one of the most studied multi-agent frameworks, achieved 25% baseline accuracy on custom task benchmarks — and reached only 40.6% with improved prompts and topology redesign [2]. That ceiling matters: a 60% failure rate after significant engineering investment reflects coordination failure modes that prompt engineering cannot fully address. Adding agents does not simply add capability; it adds failure surface that constrains peak performance.
Observability Tax
Debugging a single-agent failure requires reading one context window. Debugging a multi-agent failure requires reconstructing which agent took which action in which order, which messages passed through the system, and where the first reasoning error occurred. This is qualitatively different work.
The scale of the difference is concrete: in the MAST study, annotated execution traces averaged over 15,000 lines of text per trace [2]. That is not a context window — it is a document. Human expert annotators in that study required multiple passes and structured taxonomies to correctly classify failures, reaching only weak inter-annotator agreement (kappa = 0.24) on first pass before refining their frameworks. Reproducing failures requires reproducing multi-agent coordination state — agent roles, message sequences, tool call results, inter-agent dependencies — not just replaying a single prompt-response chain. The diagnostic tools for single-agent systems (prompt replay, context inspection, deterministic re-runs) provide limited leverage in multi-agent failures because the failure often depends on the specific ordering and content of inter-agent messages, which may not be logged at sufficient resolution.
When Single-Agent Outperforms Multi-Agent
Given those costs, single-agent is the correct default for the following task types:
Sequential tasks with tight context dependency. Any task where step N requires the full reasoning context from steps 1 through N-1 is a single-agent task. Code debugging is the canonical example: following a stack trace requires holding the entire execution context simultaneously. Investigation tasks — reading logs, forming hypotheses, testing them — require chain continuity that handoffs break.
Tasks with fewer than 10-15 steps. Spawning an agent costs tokens, time, and coordination overhead. For short tasks, that overhead exceeds the value of parallelism. There is no efficiency gain from splitting a 5-step task across two agents when spawning the second agent requires half the tokens the task itself requires.
High-coherence output tasks. Writing, analysis, and synthesis tasks where logical consistency across the full output matters require single authorship. A 3,000-word technical article written by five agents each responsible for different sections will show seams. Argument continuity, tone consistency, and logical flow across section boundaries require one reasoning entity to hold the whole.
Tasks where single-agent baselines exceed 45%. This is the capability saturation threshold: once a single agent achieves around 45% success rate on a given task type, coordination benefits diminish or go negative [1]. At that capability level, the task is within the model’s reliable performance range, and adding agents introduces coordination variance without meaningfully raising the ceiling.
Low-latency requirements. If your system needs to respond in under a second, multi-agent coordination is structurally blocked. Even a single agent-to-agent message adds hundreds of milliseconds. Systems requiring interactive response times are single-agent systems by necessity.
When Multi-Agent Pays Off
Multi-agent architecture earns its complexity cost under specific, identifiable conditions:
Genuine task parallelism with low context overlap. The precondition is that the task contains 2+ subtasks that are (a) truly independent and (b) share less than 20% context dependency. Research tasks often qualify: “summarize paper A” and “summarize paper B” can run in parallel with no coordination cost mid-task. Web scraping pipelines, parallel data extraction, simultaneous experiment runs — these benefit from multi-agent parallelism. The metric to check: can each subtask be fully specified with a self-contained prompt, without referencing the other agent’s output?
Long-horizon tasks exceeding context limits. For tasks requiring processing of more than ~100,000 tokens or extending across many days of real-world operation, single-agent faces a hard structural ceiling. Multi-agent architectures enable a lead agent to delegate subtasks with bounded scope, collect structured results, and maintain coordination without holding the entire execution history in context. Centralized multi-agent coordination improves performance by 80.8% on genuinely parallelizable tasks compared to single-agent approaches [1].
Specialist capability requirements. Some tasks require fundamentally different instruction sets in different phases. A system that needs domain expert behavior in phase one and critical review behavior in phase two may benefit from separate agents with separate system prompts calibrated to each role. The test: would the same model, with the same system prompt, perform both roles adequately? If yes, single-agent. If the behaviors are in tension, separate agents.
Failure isolation requirements. In production systems processing many independent user requests, multi-agent architecture allows failures in one task to be isolated from others. A single agent handling 100 concurrent tasks in one context window creates global failure risk. Multi-agent systems contain blast radius per task.
Scale beyond single-thread throughput. When the constraint is throughput rather than task complexity — processing 10,000 documents per hour, running 500 concurrent research tasks — multi-agent is the only path. No single-agent system scales horizontally. This is distinct from task complexity; it’s a raw throughput argument.
The Decision Framework
Use this decision tree before committing to an architecture. Work through it sequentially — the first condition that resolves your question ends the decision.
Step 1: Is the task sequential with tight step dependencies?
If yes, stop here. Use single-agent. Parallelism does not help sequential tasks, and context fragmentation actively hurts performance by 39-70% [1].
Step 2: Does the task contain 2+ genuinely independent subtasks?
“Independent” means: subtask B can be fully specified without knowing subtask A’s output, and B’s output doesn’t need to be integrated with A’s output mid-execution. Apply this test rigorously — most tasks that feel parallel are actually sequentially dependent when examined at the level of individual reasoning steps. “Research competitors A and B” is parallel. “Research competitor A, then compare to competitor B” is sequential. If no subtasks meet this bar, use single-agent.
Step 3: Does total task scope exceed your context limit?
If the task requires processing more input than fits in one reliable context window, single-agent will degrade. Multi-agent with structured handoffs is necessary.
Step 4: Does your single-agent baseline exceed 45% on this task type?
If yes, coordination is likely to provide marginal benefit. Further improvement comes from better prompting, better models, or task reformulation — not more agents. Unless you have a throughput requirement (Step 5), single-agent is the right choice.
Step 5: Is the requirement throughput rather than per-task quality?
If you need horizontal scale — more tasks per unit time than one agent can produce — multi-agent is the answer regardless of task complexity.
If none of Steps 2-5 resolve to multi-agent, use single-agent. The default is single.
Comparison Table
| Dimension | Single-Agent | Multi-Agent (Centralized) | Multi-Agent (Independent) |
|---|---|---|---|
| Error amplification | 1x (baseline) | 4.4x [1] | 17.2x [1] |
| Sequential task performance | Baseline | -39% to -70% [1] | -39% to -70% [1] |
| Parallel task performance | Baseline | +80.8% [1] | Varies |
| Context coherence | Full — one reasoning chain | Partial — structured handoffs | Fragmented — per-agent context |
| Latency | Minimum — no coordination | Medium — 1-3 round-trips | High — N × round-trips |
| API cost | 1x | 2-5x typical | N × agents |
| Failure modes | ~4 categories | 14 identified categories [2] | 14+ (plus cascade) |
| Observability | One context to debug | Multi-trace reconstruction | Complex — 15,000+ lines [2] |
| Throughput ceiling | Single-thread | Linear with agent count | Linear with agent count |
| Deployment complexity | Low | Medium | High |
The table makes the tradeoff visible. Multi-agent systems do not generalize well across dimensions. They win on throughput and parallel task performance. They lose significantly on error amplification, failure surface, and sequential task performance. Making the architecture choice without recognizing both sides of this table is guesswork.
Hybrid Patterns That Capture Multi-Agent Benefits at Lower Cost
Two hybrid patterns avoid the worst of multi-agent coordination cost while preserving specific benefits:
Lead + stateless worker. A single lead agent handles reasoning, planning, and synthesis. It calls stateless, specialized workers for specific operations — web search, code execution, document retrieval. Workers are not reasoning agents; they are structured function calls. The lead maintains the full context; workers never need to understand the broader task. This captures parallelism for specific operations (multiple searches, multiple retrievals) without the coordination overhead of peer agents with their own system prompts and state.
This pattern is appropriate when: you need to augment a single reasoning agent with capabilities it lacks natively, but the core reasoning is sequential and context-dependent.
Sequential specialist handoff. Each phase of a task runs as a separate, single-agent session with a structured output format. Phase 2 receives Phase 1’s structured output as its input — it does not need Phase 1’s full reasoning chain. This works when phases have genuinely different role requirements and when the interface between phases can be fully specified. The key constraint: the handoff contract must be explicit. Structured JSON output from Phase 1 that Phase 2 consumes as input. Unstructured handoffs defeat the pattern.
This pattern is appropriate when: task phases require different expertise, and the output of each phase can be fully specified as a structured object. It fails when phase outputs are inherently lossy summaries of rich reasoning chains.
Centralized vs. independent multi-agent: If you commit to full multi-agent architecture, use centralized coordination. Independent multi-agent produces 17.2x error amplification compared to 4.4x for centralized [1] — a 4x difference in error containment for similar parallelism benefits. Centralized coordination means a lead agent routes tasks, collects results, and handles arbitration. Independent multi-agent, where agents act without a coordinating entity, provides the worst of both worlds: high coordination overhead without error containment. The only exception is tasks with so little inter-agent dependency that no coordination is needed at all (pure embarrassingly-parallel workloads), where independent agents running without coordination approximate multiple single-agent runs.
What the Research Says About the Trajectory
A notable finding from 2025: the benefits of multi-agent over single-agent diminish as frontier model capabilities improve [3]. Models like GPT-5 and Gemini 2.5 Pro have reduced the historical advantage of multi-agent designs through improved in-context reasoning, better tool use, and longer effective context windows. Tasks that required multi-agent decomposition in 2023 are increasingly solvable by a single capable model in 2026.
This has a concrete implication for architecture decisions: if you’re choosing multi-agent because “the task is too complex for a single agent,” test that assumption against the current frontier model first. The answer may surprise you. The best single-agent interventions — few-shot calibration, improved prompting, structured tool use — often improve performance by 20-26% without any coordination complexity [4]. In essay assessment tasks, for instance, adding just two calibration examples per scoring level improved quality-weighted kappa by 26% for both single- and multi-agent architectures equally — the same gain without the added coordination cost.
The practical implication: before designing a multi-agent system, establish a single-agent baseline on the current frontier model. If that baseline is already above 45%, coordination is unlikely to help. If it’s below 45%, investigate whether prompt engineering or tool improvements can close the gap before adding agents. Multi-agent architecture should be a deliberate choice made after simpler approaches have been exhausted, not a starting point.
Conclusion
For tasks under 15 steps with sequential context dependency, single-agent is simpler, cheaper, and measurably more reliable. Every multi-agent variant tested degraded performance on sequential reasoning by 39-70% [1]. The cost savings, lower error amplification, and observability advantages are not marginal — they are large enough that choosing multi-agent for these tasks is an active mistake.
Multi-agent architecture is a solution to three specific problems: genuine task parallelism, task scope exceeding single-agent context limits, and horizontal throughput requirements. Outside those cases, multi-agent adds failure modes, coordination overhead, and debugging complexity without improving outcomes.
The architecture choice is not a one-time decision — it’s task-specific. A system with a mix of task types should use a mix of architectures. Route short, sequential, high-coherence tasks to single-agent. Route parallel, long-horizon, throughput-constrained tasks to multi-agent. The routing decision — knowing when to invoke each pattern — is where most of the engineering value lives. Hybrid routing systems that classify task complexity and delegate accordingly have shown 1.1-12% accuracy improvements with up to 20% cost reduction compared to committing to either architecture universally [3].
Multi-agent is not a default upgrade. It is a solution to specific, identifiable problems. Identify the problem first.
References
[1] Li, J. et al. “Towards a Science of Scaling Agent Systems.” arXiv:2512.08296 (December 2025). [https://arxiv.org/abs/2512.08296]
[2] Cemri, M., Pan, M.Z., Yang, S. et al. “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657 (March 2025). [https://arxiv.org/abs/2503.13657]
[3] Shen, X. et al. “Single-agent or Multi-agent Systems? Why Not Both?” arXiv:2505.18286 (May 2025). [https://arxiv.org/abs/2505.18286]
[4] Alikaniotis, D. et al. “Specialists or Generalists? Multi-Agent and Single-Agent LLMs for Essay Grading.” arXiv:2601.22386 (January 2026). [https://arxiv.org/abs/2601.22386]