Multi-agent failure modes are the specific ways a system of cooperating AI agents produces a wrong result that no individual agent produced — errors created by handoff, delegation and verification rather than by any single model’s reasoning. They matter because the usual remedy, a better model, does not touch them.
Key takeaways
- The published research locates most multi-agent failure in system design and inter-agent coordination, not in model capability. Replacing the model leaves the failure in place.
- A multi-agent failure is usually silent. One agent accepts another agent’s output as fact, and the error is discovered downstream in a system of record rather than in a log.
- The containment controls are unglamorous and mostly predate agents: typed handoff contracts, a verification step that does not share the producer’s context, step and spend budgets, and an identity per agent.
- Detection is a trace problem before it is a model problem. If you cannot see which agent produced the claim that became the answer, you cannot assign the fix.
- The cheapest fix for several of these failure modes is to collapse the design back to one agent with more tools. Complexity should be earned per handoff, not per project.
Most enterprise teams reach multi-agent designs for an organizational reason rather than a technical one: different teams own different systems, so each gets an agent. The result is a distributed system whose messages are natural language and whose contracts are implicit. That combination produces a category of error an application architect would recognize immediately — unvalidated input, no schema, no idempotency, no circuit breaker — wearing unfamiliar clothes.
What are multi-agent failure modes?
They are failures of the system around the agents, not of the agents themselves.
A single-agent failure is legible: the agent got the task wrong, and the trace shows where. A multi-agent failure is a composition problem. Agent A produces an output that is defensible given what A was asked. Agent B treats that output as ground truth because nothing told it not to. Agent C acts on B’s conclusion. The final action is wrong, every individual step is locally reasonable, and no agent in the chain holds enough context to notice.
The most-cited systematic study of this is the MAST taxonomy — Why Do Multi-Agent LLM Systems Fail?, Cemri, Pan, Yang et al., arXiv:2503.13657, first submitted 17 March 2025 and revised to v3 on 26 October 2025. The authors annotated execution traces from seven multi-agent frameworks and derived 14 failure modes across three categories: system design issues, inter-agent misalignment, and task verification. The taxonomy was developed from 150 traces with an inter-annotator agreement of kappa = 0.88, and released alongside a larger annotated dataset.
Microsoft’s AI Red Team publishes a complementary taxonomy from an adversarial angle — Taxonomy of Failure Modes in Agentic AI Systems, first issued April 2025 and updated on 4 June 2026, which added seven failure modes including goal hijacking, inter-agent trust escalation, session context contamination and MCP or plugin abuse. Read together, the two documents cover the same territory from opposite ends: one from traces of systems trying to work, one from a team trying to break them.
Neither is an enterprise design document, which is the gap this piece fills.
Design Multi-Agent Systems for Production
Evaluate system dependencies, security controls, recovery strategies, and performance requirements before deploying multi-agent solutions into live operations.
Where do multi-agent systems actually fail?
In three places, and the first one is a specification problem rather than a runtime one.
| Category (MAST) | What it looks like in an enterprise workflow | Why a better model does not fix it |
|---|---|---|
| System design and specification | The task boundary between two agents is described in prose. Both agents interpret an ambiguous edge case, and they interpret it differently | The ambiguity is in the brief. A stronger model resolves it more confidently, not more correctly |
| Inter-agent misalignment | Context is lost or compressed across a handoff. A constraint stated to the first agent never reaches the third | The constraint was never in the third agent’s input. No amount of reasoning recovers it |
| Task verification | The final answer is checked by an agent that shares the originating context, or is not checked at all | A verifier with the same context inherits the same assumption and confirms the error |
The third row is the one most enterprise designs get wrong in the same way. Teams add a “reviewer agent” and treat the system as verified. If the reviewer receives the producer’s reasoning along with the output, it is not an independent check; it is a second opinion from someone who read the first opinion first.
Which failure modes does a system of record make worse?
The ones where an error becomes a durable record rather than a wrong answer on a screen.
An agent that drafts a summary and gets it wrong produces a bad summary. An agent that posts a journal entry, closes a ticket, updates a customer record or releases a payment produces a state change that other processes now depend on. Three of the taxonomy’s modes change character completely under those conditions.
Cascading error through accepted output. In a read-only system this is an annoyance. In a write-enabled chain it is a sequence of committed transactions built on a first premise that was wrong, and the reversal is a reconciliation exercise rather than a retry.
Role and boundary violation. Two agents whose scopes overlap both act. In a drafting workflow you get duplicate text. In an ERP you get a duplicate posting, and the duplicate is indistinguishable from a legitimate one without a correlation identifier that nobody designed in.
Premature or missing termination. An agent concludes the task is finished when a step was skipped, or loops without converging. Under a per-call cost model the loop is a spend incident. Under a write model the skipped step is a half-completed process with no owner and no exception queue entry, because as far as the orchestrator is concerned it succeeded.
The design response to all three is the same shape: the handoff has to be a contract rather than a message.
How do you contain each failure mode in the design?
With nine controls, each attached to a specific failure rather than to a general principle.
Three of the nine deserve expansion, because they are the ones most often described and least often implemented.
Provenance on every claim. When an agent asserts something — a balance, a status, a customer attribute — the assertion carries where it came from: a tool call with arguments and a response, a retrieved document with an identifier, or an inference the agent made. Downstream agents are then able to treat inference differently from retrieval. Without provenance, every claim arrives with identical authority, which is the mechanism by which a cascading error propagates at full confidence.
A single-writer rule per resource. Exactly one agent in the system may write to a given resource. Others propose. This eliminates the duplicate-action class of failure structurally rather than by instructing agents to coordinate, and it has the useful side effect of making the permission model obvious — covered further in why agents need their own identities.
An independent verifier. The verification step receives the output and the original task, and not the producing agent’s reasoning trace. Where the task is checkable deterministically — a total, a date range, a referential integrity constraint — it should be checked by code rather than by a model. The research category is called task verification because that is where the leverage is.
What does a handoff contract have to specify?
Six fields, and the absence of any one of them maps to a named failure mode.
| Field | What it carries | Failure mode it closes |
|---|---|---|
| Task identity | A correlation ID that survives every hop and appears on every write | Duplicate action; unattributable error |
| Input schema | Typed, validated, rejected on mismatch rather than coerced | Specification ambiguity |
| Carried constraints | The constraints from upstream that must still hold, restated explicitly rather than assumed in context | Context loss across hops |
| Provenance | For each claim: retrieved, computed, or inferred, with the source | Cascading error |
| Completion predicate | What “done” means, stated as a checkable condition | Premature termination |
| Budget | Remaining steps, remaining spend, deadline | Unbounded loops |
This is a plain interface definition, and that is the point. The failure modes that dominate multi-agent systems are the failure modes of distributed systems without contracts. The orchestration layer is where the contract is enforced — see orchestration patterns for enterprise workflows for where that layer sits.
How do you detect these in production before a user does?
By alerting on trace shape, not on error rate, because almost none of these failures raise an error.
The verifier signal is worth stating plainly because it inverts the usual intuition. A reviewer agent that agrees with the producer on essentially every case is not evidence that the system is working. It is the expected reading when the reviewer shares the producer’s context, and it is indistinguishable at the metrics layer from a reviewer that is genuinely redundant. The test is to inject known-bad cases into the live flow and confirm the verifier catches them — which is an evaluation-harness job rather than a monitoring job.
Capturing enough to run these checks is the subject of agent observability. The relevant point here is that per-agent traces are insufficient. The failures live in the edges between agents, so the trace has to be the whole run, with handoffs as first-class spans.
When should you collapse a multi-agent design back to one agent?
Whenever the handoff is not buying you something you can name.
| Keep the split when | Collapse it when |
|---|---|
| The agents hold genuinely different permissions, and merging them would create an identity with more access than any task needs | The split exists because two teams own two systems, and one agent could hold both tool sets under a scoped role |
| The sub-tasks run in parallel and the latency saving is measured | The sub-agents run sequentially and the only effect is more hops |
| One sub-task needs a different model, context size or deployment location | Every agent uses the same model with a different system prompt — these are instructions, not agents |
| Each agent’s output is independently verifiable | Verification only happens at the end, so the intermediate agents add failure surface without adding checkability |
The last row is the strongest signal. A multi-agent design with a single end-of-chain check has all the coordination failure modes and none of the containment benefit. Collapsing it to one agent with the same tools removes an entire category of error at no cost in capability. The single-agent versus multi-agent decision covers the choice in full; this is the re-decision, taken after the system has run.
Improve Multi-Agent Orchestration and Control
Establish clear agent responsibilities, execution boundaries, communication protocols, and escalation paths for dependable workflow execution.
The decision
Treat a multi-agent system as a distributed system whose messages happen to be natural language, and apply the controls you would apply to any other one: typed contracts at every boundary, a correlation identifier that survives every hop, provenance on every claim, exactly one writer per resource, explicit budgets and completion conditions, and a verifier that does not read the producer’s reasoning.
Then re-decide the architecture against what the system actually does. A design where every agent uses the same model with a different prompt, runs sequentially, and is checked once at the end carries the full coordination failure surface and returns none of the benefit — collapse it to one agent with the same tools. Keep the split where the agents hold genuinely different permissions, run genuinely in parallel, or need genuinely different models, and make each handoff pay for itself.
GrowExx builds and reviews these systems through AI agent development and enterprise AI development.
FAQs
What are the most common failure modes in multi-agent AI systems?
The published MAST taxonomy (arXiv:2503.13657) groups 14 failure modes into three categories: system design and specification issues, inter-agent misalignment, and task verification. In enterprise deployments the ones that cause recorded incidents are cascading error through accepted output, context loss across handoffs, role and boundary overlap producing duplicate actions, unbounded loops, premature termination, and verification collapse where the checking agent shares the producing agent's context.
Why do multi-agent LLM systems fail even when each agent works?
Because the failure is in the composition rather than the components. Each agent is evaluated on its own task and passes; the system fails at the joints, where one agent's output becomes another's input without a schema, a provenance marker or a constraint set. This is the same class of problem as an unvalidated interface between two services, with the added difficulty that the messages are natural language and therefore always parse.
Does using a better model reduce multi-agent failures?
Not for the dominant categories. A stronger model improves individual task performance, but specification ambiguity, context loss across handoffs and absent verification are properties of the system design. A more capable model resolves an ambiguous instruction more fluently, which can make the resulting error harder to spot rather than less likely.
How do you test for multi-agent failure modes before production?
Build an evaluation set from real task instances and include adversarial cases targeting the joints specifically: an upstream output that is confidently wrong, a constraint stated only at step one that must still hold at step four, two agents with overlapping scope presented with the same resource, and a task that is genuinely unfinishable. Score the trajectory and the handoffs, not only the final answer. Running the agent against a full historical period in shadow mode, with writes disabled, is the cheapest way to surface the edge cases a curated set will not contain.
Is a reviewer agent enough to catch multi-agent errors?
Only if it is independent. A reviewer that receives the producing agent's reasoning inherits its assumptions and will tend to confirm them, which shows up as an agreement rate close to 100% and is easily mistaken for quality. An independent verifier receives the output and the original task without the producer's trace, and anything deterministically checkable — totals, dates, referential integrity, policy limits — is checked by code rather than by a second model.
Reduce Risk in Enterprise Multi-Agent AI
Book an AI Strategy Call
