Multi-Agent Failure Modes: Coordination Overhead and Emergent Behavior#

TL;DR#

Multi-agent systems don't just inherit single-agent failure modes at a larger scale - they add an entire new failure surface that only exists because more than one agent is deciding and acting: coordination overhead that grows faster than the number of agents, redundant or duplicated work from agents that can't see each other's progress, conflicting concurrent actions on shared resources, and emergent behavior that nobody explicitly designed and that only shows up when the agents actually run together. Research validated across 1,642 execution traces puts multi-agent production failure rates at 41-87%, and attributes most of it to coordination defects, not base-model capability - which makes this a staff-level system-design problem, not a prompting problem.

The idea#

Lesson 01 argued for splitting work across agents when the benefits (parallelism, specialization, context isolation) outweigh the coordination cost. Lessons 02-05 built the machinery for that coordination: delegation, coordination mechanisms, orchestration architecture. This lesson is about what that machinery does not fully solve - failure modes that are specific to the multi-agent case and have no single-agent analogue, because they arise from the interaction between agents, not from any one agent's individual reasoning.

This distinction matters at the staff level because it changes where you look for the bug. A single-agent system that fails usually fails because of something local: a bad prompt, a missing tool, a model that made a wrong call. A multi-agent system can fail with every individual agent behaving reasonably at every individual step - the failure only exists in aggregate, in how the agents' locally-reasonable actions combined. That is exactly the class of failure that reviewing any one agent's transcript in isolation will not surface, and it is why multi-agent debugging requires a different diagnostic habit than single-agent debugging: look at the interaction trace, not just each agent's individual trace.

The empirical picture backs this up. The MAST taxonomy (Cemri et al., arXiv:2503.13657), validated on 1,642 annotated execution traces from seven production multi-agent frameworks, found multi-agent systems failing in production at rates between 41% and 87%, and classified those failures into three root categories - the taxonomy this lesson is organized around.

How it works#

The MAST taxonomy: three root categories of failure#

MAST groups the 14 failure modes it identified into three categories, by where in the system's lifecycle the failure originates:

1. Specification and system design issues (~42% of observed failures). The system was set up wrong before it ever ran: ambiguous role definitions, absent or unclear termination criteria, unclear task specifications. Concretely: an agent disobeying its assigned role's boundaries, repeating steps unnecessarily because nothing told it the step was already done, or not recognizing that a task is actually complete.
2. Inter-agent misalignment (~32% of observed failures). The system was set up reasonably, but agents diverged while actually interacting: broken information flow between agents, conflicting assumptions each agent independently made, incomplete context propagation from one agent to the next, one agent ignoring another's input, or a mismatch between an agent's stated reasoning and the action it actually took.
3. Task verification and termination failures (~26% of observed failures). The work product itself was not adequately checked: incorrect or incomplete verification of another agent's output, or premature termination - the wrong agent (or no agent) declaring the task done before it actually was.

The category weights matter for where you invest debugging and design effort: the largest bucket (specification/design) is failures you can catch before any agent ever runs, by writing sharper role boundaries and termination criteria - the kind of design review a single-agent system doesn't need, because there's no inter-agent boundary to specify.

Worked example: redundant work from missing visibility#

Two agents, researcher-A and researcher-B, are both given the sub-task "find the top three competitors to Company X" as part of a larger market-analysis task, because the orchestrator split "gather competitive intelligence" into parallel sub-tasks without checking whether the sub-tasks actually overlapped. Neither agent can see what the other is doing mid-task (no shared state on in-progress work, only a final task list per lesson 04's terminology). Both spend a full research cycle - web searches, source reading, synthesis - arriving at nearly identical answers. The system pays for the work twice, and worse, if the two answers disagree even slightly (one found "Company Y" as a top-3 competitor, the other found "Company Z"), a downstream synthesis step now has to adjudicate a conflict that only exists because of duplicated effort, not because of any real ambiguity in the world. This is a coordination-overhead failure with a specific, fixable cause: the task decomposition didn't check for overlap, and no coordination mechanism gave either agent visibility into what the other had already claimed.

Worked example: conflicting concurrent actions on shared state#

A code-review multi-agent system has a linter-fix-agent and a feature-agent both operating on the same file concurrently - feature-agent is adding a new function, linter-fix-agent is reformatting the file to fix style violations flagged before the new function was added. Both read the file, both compute a diff against what they read, both write back. Whichever writes second silently overwrites the first's change - not because either agent reasoned incorrectly, but because neither had a way to know the file had changed underneath it between its read and its write. This is a textbook lost-update race condition, translated into agent-coordination terms: the same class of bug that database systems solve with locks, optimistic concurrency control, or transactions has a direct analogue here, and a multi-agent system that lets independent agents read-modify-write shared resources without any of those mechanisms will hit it - not as an edge case, but as a predictable consequence of the architecture.

Worked example: emergent behavior nobody designed#

A negotiation-style multi-agent system has a buyer-agent and a seller-agent, each individually reasonable: the buyer is instructed to "get the best price, but don't be unreasonable," and the seller to "maximize revenue, but keep the customer." Run individually, each agent's behavior is sensible turn by turn. Run together over many turns, the two agents can settle into a pattern nobody designed: incrementally escalating counter-offers that drift toward an outcome neither agent's individual instructions anticipated (a price far below the seller's actual floor, reached because each individual concession looked locally reasonable and neither agent was tracking the cumulative trend). This is emergent behavior in the precise sense - a property of the interaction between agents over time, not a property either agent's individual policy predicts in isolation, and it is structurally the same shape as the two-agents-stuck-re-prompting-each-other failure from tool-use-agentic-loop/08: locally reasonable steps, only visible as a problem in aggregate. The fix is not "make the agents smarter" - it's adding a mechanism external to either agent's reasoning that bounds the interaction (a maximum number of negotiation rounds, a hard floor/ceiling either side cannot cross regardless of what the conversation's momentum suggests) - the same architectural instinct as the hard backstops in tool-use-agentic-loop/08, applied to a failure that only exists because two agents are interacting.

Why coordination overhead is a structural cost, not just friction#

Coordination overhead is often described loosely as "agents spend time talking to each other," but it has a more precise shape: work attributed to monitoring and reconciling state across agents, distinct from the work of actually solving the task, and it does not scale linearly. A system where N agents each need some visibility into U shared updates carries coordination cost that scales with N times U, not with N alone - meaning coordination cost grows faster than the team as both the number of agents and the amount of shared state they need to track grow together. This is why doubling the number of agents on a task rarely halves the time to completion the way doubling workers on a perfectly parallelizable task would - part of the added capacity is consumed by the added coordination the extra agents now require, and past some team size the coordination cost can exceed the marginal value of the additional agent. This is the same shape as Brooks's-law-style coordination cost in human teams, and the multi-agent case doesn't escape it just because the "workers" are models instead of people.

Error amplification: why uncoordinated failure compounds#

When agents operate with minimal cross-checking, an error introduced early doesn't stay contained - it propagates and compounds as downstream agents build on an upstream agent's already-wrong output, each treating the upstream result as ground truth. Measured comparisons found uncoordinated multi-agent pipelines amplifying an initial error by as much as 17x by the time it reached the final output, versus roughly 4.4x in architectures that included a centralized validation bottleneck - a single point where an agent's output is checked against ground truth or against another agent's independent result before being trusted downstream. The gap between those two numbers is the concrete, measured value of verification as a coordination mechanism, not merely a nice-to-have: architectures that never pass a value forward without some check on it contain error propagation to roughly a quarter of what unchecked architectures produce.

Pros#

Framing failure modes this way (as a distinct taxonomy) is itself the benefit: it gives you a checklist to design against and a vocabulary to diagnose against, rather than treating every multi-agent bug as a one-off mystery. Concretely: - Specification-issue failures are catchable before runtime - a design review checking role clarity and termination criteria against the taxonomy's ~42% bucket catches the largest failure category before it costs a single token. - Coordination and verification failures point at architecture, not prompts - knowing that 26% of failures are verification gaps tells you to invest in a validation step, not a better prompt for the agent that's failing. - The error-amplification numbers (17x vs 4.4x) give a concrete, arguable case for a validation bottleneck to a stakeholder who might otherwise see it as unnecessary latency.

Cons#

• The taxonomy describes failure after the fact; it doesn't automatically tell you which specific mechanism to add - "verification gap" is a diagnosis, not a fix, and choosing the right fix still requires system-design judgment.
• Coordination mechanisms that prevent these failures (locking, validation bottlenecks, shared-state visibility) all cost latency and complexity, and over-applying them to a low-stakes task reintroduces the coordination-overhead cost this lesson warns about, in service of preventing a failure that task didn't actually risk.
• Emergent behavior is, by definition, hard to fully anticipate - you can bound it with backstops (round limits, hard floors/ceilings) but you cannot exhaustively enumerate every interaction pattern two or more agents might settle into, especially as team size grows.

Alternatives#

• Single-agent design (sidestepping the entire failure surface) — if lesson 01's threshold for splitting isn't clearly met, the correct response to this lesson's failure modes is sometimes "don't build the multi-agent system" rather than "build it more carefully" - none of these failures exist in a single-agent architecture.
• Heavier deterministic-script orchestration (lesson 05) to remove agent-to-agent negotiation entirely — if code, not agents, decides the sequence and reconciles shared state, several of these failure modes (conflicting concurrent writes, emergent negotiation drift) become structurally impossible rather than merely mitigated, at the cost of the adaptability role-based or graph-based orchestration would have offered.
• Formal contracts / trace-based assurance testing between agents — treating each agent's input/output boundary as a testable contract (2026 work on trace-based assurance frameworks for agentic orchestration) catches inter-agent misalignment failures via automated testing before production, at the cost of the upfront engineering effort to define and maintain those contracts.

When to use it#

Apply this taxonomy whenever you are designing, reviewing, or debugging a system with more than one agent: use the three categories as a design checklist before launch (are roles and termination criteria unambiguous? is there a verification step for agent output before it's trusted downstream? is shared-state access to overlapping resources safe under concurrency?), and use it as a diagnostic frame when a multi-agent system misbehaves in a way no single agent's transcript explains - the bug is very likely inter-agent, and the fix belongs in the coordination layer, not in any one agent's prompt.

When NOT to use it#

Don't over-apply verification bottlenecks, locking, or negotiation backstops to a system where agents don't actually share mutable resources or interact iteratively - a set of genuinely independent, parallel agents each producing an isolated output for a human to review has no lost-update risk and limited emergent-behavior risk, and adding these mechanisms there is pure overhead paid against a failure mode that architecture doesn't have. Similarly, don't treat every multi-agent bug as automatically belonging to this taxonomy - a failure fully explained by one agent's individual reasoning (a bad tool call, a hallucinated fact) is still an ordinary single-agent failure mode and doesn't need an inter-agent diagnosis.

Key takeaways / mental model#

Multi-agent failures split into three questions, in the order they're worth checking: was the system specified clearly before it ran (roles, termination criteria)? did the agents actually stay aligned while interacting (information flow, shared assumptions)? was the output verified before being trusted downstream? Two failures deserve their own mental hook because no single-agent transcript reveals them: redundant work from agents that can't see each other's progress, and emergent behavior that only appears in the interaction over time, never in any one agent's individual policy. When every agent's transcript looks locally reasonable and the system still failed, the bug is in the coordination layer - look at the interaction trace, not each agent alone.

Self-check questions#

1. A multi-agent system fails and every individual agent's transcript, read in isolation, looks locally reasonable. Using the MAST categories, list two different root causes this observation is consistent with, and describe what evidence (beyond individual transcripts) would distinguish between them.
2. Two agents are both writing to the same shared file with no locking or optimistic-concurrency check. Using the coordination mechanisms from lesson 04, propose a specific fix, and explain which MAST category this failure belongs to.
3. Your team wants to add a centralized validation step before every downstream agent consumes another agent's output, citing the 17x-vs-4.4x error-amplification finding. A colleague objects that this doubles latency on every pipeline, including low-stakes ones. How do you decide where the validation bottleneck is worth its cost and where it isn't?
4. A negotiation-style two-agent system (buyer/seller) drifts to an outcome neither agent's individual instructions predicted. Explain why this is categorized as emergent behavior rather than a bug in either agent's individual prompt, and propose a bound that would catch it without requiring either agent to reason its way out.
5. You're reviewing a new multi-agent system design before it ships. Using the ~42/32/26 percent split across MAST's three categories, where would you spend the majority of your review time, and why does that allocation make sense given what each category actually catches?

References#

• arXiv:2503.13657 - Why Do Multi-Agent LLM Systems Fail? (MAST taxonomy; validated at NeurIPS 2025 on 1,642 execution traces from seven frameworks)
• Augment Code: Multi-Agent AI Systems - Why They Fail and How to Fix Coordination Issues (2026)
• arXiv:2605.03310 - Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems: An Information-Controlled Empirical Study on Prediction Markets (2026)
• arXiv:2603.18096 - A Trace-Based Assurance Framework for Agentic AI Orchestration: Contracts, Testing, and Governance (2026)
• agentic-engineering/tool-use-agentic-loop/lessons/08-when-to-stop.md (prerequisite context: two-agents-stuck-re-prompting-each-other as a related emergent failure, and hard backstops as the general pattern for bounding it)
• agentic-engineering/multi-agent-orchestration/lessons/04-coordination-mechanisms.md (prerequisite: shared state and message passing as the mechanisms whose absence or misuse produces several failures here)