Failure modes in multi-agent teams: how a crew of agents breaks differently

Originally published on Loop & Retry — field notes on building LLM agents that survive production.

The pitch for multi-agent systems is redundancy and specialization: split the task, let a planner plan and a critic critique, and the whole is more reliable than the parts. Sometimes. But a team of agents also opens a class of failures that a single agent simply cannot have — failures of coordination, not of competence. And several of them get worse, not better, as you add agents.

This is the companion to how agent failures cascade: that post was about one bad step propagating down a single trajectory. This one is about the failures that need more than one actor to exist at all.

Failure mode 1: correlated collapse

The redundancy argument assumes independence. Three agents voting on an answer beats one if their errors are uncorrelated — then a majority is unlikely to be simultaneously wrong. But agents on the same base model, given the same prompt framing, fail in the same direction. They share the base model's blind spots, they read the same poisoned tool output, they inherit the same ambiguous instruction. Their errors are correlated near 1, so the "vote" doesn't average out error — it amplifies confidence in it. You get three agents agreeing on the wrong answer and a system that now reports high consensus, which downstream logic reads as high reliability.

The tell: your ensemble's agreement rate is high and its accuracy isn't. High agreement with mediocre accuracy is the signature of correlated failure, and it's exactly what you'd wrongly celebrate as "the agents are confident." Measure the conditional accuracy — accuracy given the agents agreed — and if it's not much above the base rate, your redundancy is decorative.

Failure mode 2: diffused responsibility

Give one agent a task and it owns the outcome. Give five agents a task and each one can plausibly assume another handled the hard part. This is the software version of the bystander effect, and it shows up concretely: the planner assumes the executor will validate inputs; the executor assumes the planner already did; nobody validates. Each agent's local transcript looks reasonable — "I was told the input was clean" — and the gap lives between them, in the handoff, where no single transcript records it.

This is why multi-agent debugging is so much harder. The bug isn't in any agent's reasoning; it's in the assumption each made about the others. You can read every transcript in full and see nothing wrong, because the failure is the absence of an action that every agent believed was someone else's job. Explicit contracts on every handoff — "the executor validates, the planner does not, and this is written down" — are the only fix, and they're the first thing an under-specified multi-agent design omits.

Failure mode 3: context fragmentation

A single agent has one context window — one cache — and everything it knows is in it. Split the work across agents and you've split the context, on purpose. Now the planner knows the user's real goal, the executor knows the tool results, the critic knows the rubric, and no single agent has all three. Each reasons correctly over its fragment and the fragments don't compose. Every inter-agent handoff is a lossy compaction — you're compressing and filtering what the next agent sees, and the load-bearing constraints are the first thing to disappear.

The concrete failure: the user wanted a fast approximate answer, the planner knew that, but the executor — never told — grinds toward a precise one and blows the latency budget. No agent is wrong locally. The goal just never made it across the membrane. Every handoff is a lossy summary (you can't forward the whole window without collapsing back into one agent), so multi-agent architectures are compaction by design, with all of compaction's information loss — except now the loss happens at organizational boundaries you drew yourself.

Failure mode 4: livelock and the consensus that converges on nothing

Two agents that can revise each other's work can loop: the critic flags an issue, the executor fixes it in a way that trips a different check, the critic flags that, the executor reverts. Both are "making progress" by their local view and the system as a whole is stuck — the multi-agent version of loop drift, except no single transcript reveals it because the drift lives in the ping-pong between agents. Each agent's history looks like productive iteration.

The bound is the same shape as a retry budget: cap the total back-and-forth across the team, not per agent, and make an exhausted budget a real outcome — escalate to a human or ship the best candidate so far, rather than letting two agents negotiate forever on your token budget. Per-agent caps don't help; two agents each "reasonably" allowed ten rounds is twenty rounds of livelock.

The uncomfortable summary

The through-line: adding agents adds coordination surface, and coordination is where multi-agent systems fail. More agents means more handoffs, more shared blind spots voting together, more fragments of a goal that has to survive more membranes. That doesn't mean don't build them — it means the reliability case for a multi-agent system has to account for the failures multi-agent-ness creates, not just the ones specialization is supposed to prevent. Before you split a task across a team, ask whether a single agent was ever the bottleneck, because a team inherits every failure mode of one agent and adds four of its own. And make sure you're measuring the whole trajectory, not just the final answer — correlated collapse and livelock won't show up in your pass rate, they'll show up in agreement metrics and loop counts.

These failure modes are architecture-level and provider-independent — they follow from splitting a task across actors, not from any specific model. The measurements (conditional accuracy, handoff ownership, goal survival, cross-agent round count) are the instruments; thresholds are workload-specific.