Failure modes

Multi-Agent Failure Modes

Multi-agent systems fail less like a single bad answer and more like a distributed system: partial state, hidden retries, stale assumptions, runaway cost, and errors that compound across boundaries.

Cost blowup

The first failure mode is economic. A multi-agent system can spend more tokens, call more tools, run longer, and create more traces than a single-agent baseline. That may be exactly the point for a valuable research task. It may be absurd for a simple support answer.

Cost should be designed as an explicit budget, not discovered on an invoice. Each agent needs a maximum turn count, tool budget, stop condition, and rule for when to return partial work. The coordinator needs to know when more exploration is likely to improve the answer and when it is just widening the bill.

Error compounding

Agent errors compound because downstream agents often treat upstream output as context. A worker may misunderstand a subtask. A reviewer may critique the wrong artifact. A coordinator may synthesize confident prose from weak evidence. A tool failure may send the system down a different path on the next run.

Anthropic's production write-up notes that minor changes can cascade into large behavior changes in complex agents. MetaGPT's paper makes the same point from the research side: naive chains of LLM agents can amplify hallucinations unless coordination is structured by standard operating procedures and intermediate checks.

"cascading hallucinations caused by naively chaining LLMs"
Source: MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework

Context fragmentation

Context fragmentation happens when each agent has only a local slice of the problem and no durable way to recover the decisions made elsewhere. The result is not merely missing information. It is conflicting style, conflicting goals, duplicated tool calls, and incompatible assumptions that look reasonable in isolation.

Cognition's critique is useful because it focuses on implicit decisions. Every tool call, discarded source, naming choice, and partial edit carries a decision. If another agent cannot see the relevant part of that history, it may repeat the work or make a conflicting decision. Passing only the final answer is often too lossy.

The mitigation is not "share everything forever." That runs into context limits and cost. The mitigation is to promote important decisions into artifacts: source notes, interface contracts, accepted plans, blocked actions, and test results. Agents should exchange durable state, not vibes.

Eval blindness

Multi-agent systems are hard to evaluate because valid paths differ across runs. If the test expects the exact same sequence of steps every time, it will reject useful variability. If the test only checks the final text, it may miss bad sources, excessive tool calls, or unsafe intermediate actions.

A stronger eval suite checks outcomes and process. Did the final answer satisfy the task? Did cited sources support the claims? Were primary sources preferred? Did the system stop when it should? Did tool calls produce new information? Did a high-risk action trigger human oversight?

Controls that actually help

Useful controls are boring and explicit: small evals before big launches, trace IDs, artifact stores, cost budgets, retry limits, source-quality rules, human approval for high-risk actions, and rollouts that avoid changing the behavior of long-running agents mid-task.

OpenAI's guide emphasizes guardrails and human intervention for threshold failures or high-risk actions. Anthropic emphasizes tracing, checkpoints, source-quality heuristics, and flexible evals. The shared lesson is that multi-agent systems need deterministic scaffolding around probabilistic work.

A good failure-mode review ends with a go/no-go question: can you explain how the system will fail, see that it failed, stop it from spending indefinitely, and recover without making a user start over? If not, the architecture is not ready for production.

Read next

Sources used on this page