Fourteen Agent Failure Modes. Three Root Causes. One Triage Question Each.

The MAST dataset shows failure rates from 41% to 86.7% across seven leading open-source multi-agent systems.^[1] That's not the alarming part. The alarming part is what engineering teams do after the failure fires: they tune the prompt when the spec was wrong, add retries when the coordination protocol had no clarification gate, or upgrade the model when the verification layer was missing entirely. Three structurally distinct problems. Three different intervention timings. Each invisible from the vantage point of the other two.

MAST — the Multi-Agent System Failure Taxonomy, published at NeurIPS 2025 by researchers at UC Berkeley — is the first empirically grounded classification of why multi-agent systems fail.^[1] It identifies 14 fine-grained failure modes validated with inter-annotator agreement of κ = 0.88 across six expert annotators.^[1] The taxonomy is organized into three overarching categories that are operationally meaningful: Specification Issues (FC1, 41.77% of failures), Inter-Agent Misalignment (FC2, 36.94%), and Task Verification (FC3, 21.30%).^[1]

The taxonomy is real. The operational playbook is missing. No published guide tells an engineering leader how to determine which of the three categories their current failure belongs to, or which layer the fix targets. That gap is what this article closes.

The MAST paper's most important finding is not the 14 failure modes. It's the three-category structure and what each category implies about where the fault lives.

FC1 — Specification Issues are failures that originate before execution. The agent misunderstood the task, violated its role definition, repeated steps already completed, lost conversational context, or didn't know when to stop. Every FM-1.x mode traces back to a design decision made before the first token was generated. This means they're largely preventable — not through better models, but through tighter specs.

FC2 — Inter-Agent Misalignment emerges during execution as agents coordinate, hand off state, and negotiate task progress. Agents proceed on wrong assumptions, reasoning doesn't match action, crucial information gets withheld, task objectives drift mid-run. The MAST paper offers a pointed insight here: solutions focused on communication protocols are often insufficient for FC2 failures — they demand deeper coordination design.^[1] You can't add retries to fix a clarification failure. You need a gate that forces the agent to ask before proceeding.

FC3 — Task Verification is the most expensive category to miss. Three modes — premature termination, incomplete verification, and incorrect verification — all produce the same external signature: the workflow completes, no alert fires, output looks plausible. The MAST paper shows that relying on final-stage verification alone is structurally inadequate.^[1] You need multi-level verification, not a single check at the end.

The operational consequence of this structure: FC1 failures are preventable pre-deploy. FC2 failures are detectable at runtime. FC3 failures are only catchable with an active eval layer. Each category requires different tooling and a different team cadence to address.

FC1 failures feel like model failures because they manifest as incorrect agent behavior. The agent ignores task requirements (FM-1.1), steps outside its role (FM-1.2), repeats work it already completed (FM-1.3), loses prior context (FM-1.4), or runs indefinitely without finding a stopping condition (FM-1.5). The model is working correctly. The spec was incomplete.

The diagnostic signal for FC1 is this: when you look at the failed trace and can identify exactly what constraint was missing from the system prompt or role definition — that's FC1. The agent didn't hallucinate the behavior; the behavior was consistent with an underspecified instruction.

Step repetition (FM-1.3) is the most visible FC1 mode in production because it generates volume — a looping agent produces trace data that's hard to miss. The AppWorld benchmark had the highest concentration of this mode in MAST-Data.^[1] The fix is an explicit state-tracking mechanism: the agent should check at each step whether the target state has already been achieved. This is a spec addition, not a prompt tone adjustment.

Agents unaware of termination conditions (FM-1.5) is the subtler FC1 failure. The agent has no explicit completion signal, so it continues past the point where the task is done — or worse, treats the absence of failure as permission to keep going. Every agentic workflow needs a stated terminal condition that the agent can evaluate against its current state. 'Return when the task is complete' is not a termination condition. 'Return when the output file matches the expected schema and all validation checks pass' is.

FC2 failures are where most multi-agent debugging tools fall short. The failures emerge from agent interaction — not from any single agent's behavior in isolation — so neither the orchestrator logs nor the individual agent logs clearly isolate the cause.

The most frequent FC2 mode is reasoning-action mismatch (FM-2.6, 13.98% of all MAST failures^[1]). The agent explains in its reasoning step that it will take action X, then takes action Y. This produces outputs that are internally incoherent — the reasoning chain looks valid, the action looks valid, but they describe different things. Teams that review only action outputs miss this entirely. You need to compare stated reasoning to actual action at each agent step.

The second most common FC2 mode is failure to ask for clarification (FM-2.2, 11.65%^[1]). An agent encounters an ambiguous instruction, makes a plausible assumption, and proceeds — sometimes correctly, often not. The critical design gap is the absence of a clarification gate: a decision point that checks whether the agent has enough information to proceed with confidence before continuing. Most MAS designs skip this gate because it requires additional latency. The alternative is a wrong execution at scale.

Task derailment (FM-2.3, 7.15%^[1]) is the hardest FC2 mode to catch retrospectively because the agent looks productive throughout. It's completing steps, returning results, interacting with other agents — just on the wrong objective. The point at which the task went sideways is usually many turns before the point at which the output reveals it.

The MAST paper's FC2 insight is worth stating plainly: communication protocol improvements — cleaner message formats, more structured handoffs — are insufficient to prevent FC2 failures.^[1] These failures require structural coordination design: explicit clarification gates, shared task state that all agents can inspect, and reasoning traces that are checked against action outputs, not just presented as justification.

FC3 is where the gap between technical observability and actual quality lives. All three FC3 modes produce the same surface signature: the workflow completes, every span succeeds, no circuit breaker trips, no budget ceiling fires. Your dashboard is green. The output is wrong.

Premature termination (FM-3.1, 7.82%^[1]) is the most benign-looking FC3 mode. The agent stops when it shouldn't have — it reached a partial completion state that satisfied its termination condition but not the user's intent. The trace looks like a successful short run. Downstream systems process truncated output without knowing it's truncated.

Incomplete or absent verification (FM-3.2, 6.82%^[1]) is the architectural pattern where the system produces output but never checks whether that output is correct. Teams that rely on final-stage checks only — a single validation at the end of a long pipeline — find that multi-step errors compound before the check runs. The MAST paper specifically calls this out: multi-level verification is needed, not just terminal verification.^[1]

Incorrect verification (FM-3.3, 6.66%^[1]) is the most expensive FC3 mode to discover because the team believes they have quality controls. The verifier runs. The verifier says 'pass.' The output is wrong. This happens when the verifier is not testing the right property — checking format when correctness matters, checking syntax when semantics matter, or checking against stale expectations.

The ReliabilityBench study independently confirms the verification gap: pass@1 metrics overestimate production reliability by 20–40% because they measure single-run success, not whether the agent's output is actually correct.^[6] FC3 failures are what that 20–40% gap is made of. Teams without an active eval layer — an LLM-as-judge or domain-specific validator sampling production outputs — are flying blind on the entire FC3 category, which accounts for 21.30% of documented failures.

MAST's most useful contribution is not the 14 failure modes. It's the proof that these 14 modes are not a flat list — they're three structurally distinct failure surfaces, each requiring a different intervention at a different stage. Treating FC3 with spec changes is as wrong as treating FC1 with an eval layer. The failure mode determines the fix timing. The fix timing determines which team owns it.

Thirty days of MAST-tagged postmortems tells you whether your recurring failures cluster in FC1 (spec discipline problem), FC2 (coordination design problem), or FC3 (eval coverage problem). That's not a diagnosis of a single incident. It's a map of which architectural layer has the structural gap.

The fix is never the model.