MAST Agent Failure Triage: 14 Failure Modes, 3 Root Causes, 1 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]

Separate validation from Patronus AI's TRAIL benchmark makes the diagnostic challenge sharper: even the best long-context LLMs (Gemini-2.5-pro) score only 11% when asked to debug agent execution traces.^[7] Your model cannot diagnose its own failures. You need a structural framework — and that's precisely what this playbook provides.

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 makes them 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 makes a pointed observation 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] Multi-level verification is required, not a single check at pipeline end.

The operational consequence of this structure is strict: 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, different ownership, and a different cadence.

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: 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.

A 2026 paper on Agent Behavioral Contracts (ABC) formalizes what MAST implies: when contracted agents operate with explicit preconditions, invariants, and recovery rules, they detect 5.2–6.8 soft violations per session that uncontracted baselines miss entirely.^[8] The implication is that the gap between MAST's FC1 failures and spec-complete systems is real and closable — but it requires treating behavioral constraints as first-class artifacts, not incidental prompt additions.

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 where 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 checked against action outputs, not just presented as justification.

The LumiMAS monitoring framework (AAMAS 2026) offers a concrete detection path: its three-layer architecture — monitoring, anomaly detection, and anomaly explanation — detects FM-2.6-style coordination failures in under 0.07 seconds with a low false positive rate.^[10] The key observation is that system-wide anomaly detection, not per-agent log review, is what surfaces FC2 failures reliably.

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 required, 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 tests the wrong 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. Survey data from 2025-2026 shows LLM-as-judge adoption at 52% among teams doing model-based evaluation, but the critical constraint is what the judge evaluates: it must check task-level correctness, not schema validity or format compliance.^[5]

A single MAST-tagged postmortem tells you what went wrong. Thirty days of them tells you where your system has a structural gap.

If FC1 failures cluster — agents repeatedly violating spec, stepping out of role, or running past termination conditions — the problem is a process gap in how behavioral specs are written and reviewed before deploy, not individual agent failures. The fix is a spec review gate in your deployment pipeline.

If FC2 failures cluster — coordination breakdowns, reasoning-action mismatches, agents proceeding on wrong assumptions — the problem is that your coordination design is treating inter-agent interaction as incidental rather than structural. The fix is redesigning the coordination layer: shared state, explicit clarification gates, handoff validation.

If FC3 failures cluster — outputs that pass infrastructure checks but fail at correctness — the problem is that your eval coverage is measuring the wrong thing. The fix is an eval layer that assesses task-level correctness, not just format or schema validity.

Tag 30 postmortems. Query the distribution. That distribution is your architectural backlog. MAST doesn't just explain what went wrong — it tells you where to invest before the next incident fires.

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.