Failure Analysis

The Story

A multi-agent workflow for procurement goes to production. Within two weeks, the support queue fills with complaints: wrong vendor recommendations, repeated approval steps, premature task termination, contradictory handoffs between the sourcing agent and the compliance agent. The team opens the trace log and sees chaos. Every trace looks like a different failure.

MAST -- the Multi-Agent Systems Failure Taxonomy -- was built because the one-at-a-time instinct is wrong. The Berkeley team analyzed 150 multi-agent traces to develop a taxonomy, verified with inter-annotator agreement at kappa = 0.88, then scaled it across 1,600+ annotated traces. What looked like dozens of unique failures collapsed into 14 failure modes organized into three categories.

A customer support agent crashes regularly. The team assumes the underlying model isn't reliable enough. They plan a model upgrade. But a 2026 empirical study analyzed 998 bug reports across CrewAI and LangChain: API Misuse (32.97%) and API Incompatibility (22.34%) together accounted for more than 55% of all reported bugs. The model wasn't the problem. The interface between the model and its tools was the problem.

A research assistant agent handles document analysis. The team upgrades from one frontier model to another -- measurably better on benchmarks. But in production, the same behavioral patterns persist. A study of cloud-based agents across 1,675 runs on five different models found the same thing: the most common pitfalls persisted across all five models, indicating they originated from the shared agent architecture, not from model-specific weaknesses.

The Core Idea

Every production AI system generates failed traces. The question is what you do with them. The default approach -- read each trace, diagnose, fix, move on -- works at 10 failures a week. At 100, it's a full-time job. At 1,000, it's impossible.

Where This Hits in Production

Aggregation by causal stage, not symptom label. "Hallucination" is almost useless as a diagnostic label. It can originate from bad retrieval, bad generation, bad tool use, or bad harness design. Calling all four "hallucination" tells you nothing about what to fix. Tracing each to its causal stage tells you everything.

Before diving into specific failure families, the Three Gulfs framework from Topic 6 gives the analysis team a useful first-pass categorization. Most "API Misuse" and constraint-violation failures are Specification Gulf problems -- the rules existed but weren't encoded clearly enough. Most "hallucination" and "wrong context" failures are Comprehension Gulf problems -- the system retrieved irrelevant evidence or misinterpreted the query. And the pattern where something works in testing but fails in production is almost always a Generalization Gulf problem -- the system learned the shape of your test distribution but can't handle the long tail of real-world inputs. This mapping gives you a fast triage lens: when a new failure family emerges, asking "which gulf does this cluster under?" points you toward the right system layer before you've opened a trace.

The harness is a suspect, not just a container. Every harness component encodes an assumption about what the model cannot do, and those assumptions go stale as models improve. When symptoms persist across model upgrades, the genealogy points to the harness.

Metadata discipline determines whether genealogy is even possible. Without metadata -- environment, user, correlation IDs, version identifiers -- you can see that a trace failed but not where it came from. Metadata attached at instrumentation time is the raw material that makes genealogy possible months later.

Two failure families deserve explicit naming using the Four Faces of Fake Success vocabulary from Topic 2: Corrupt Success (Face #2), where the system achieves the goal but violates constraints along the way, and Agent Gaslighting (Face #3), where the agent fabricates evidence that it succeeded -- both are primary genealogy targets because they pass outcome-level evaluation while hiding structural rot.

Connecting the Dots

Topic 22 depends on Topic 21's deep rubrics. You cannot build a useful genealogy if every failure is labeled only "pass" or "fail." When a failed trace carries per-dimension scores -- accuracy was high, security was low, risk disclosure was missing -- the genealogy gets structural.

Many failure families that persist across model upgrades are context or harness failures, not model failures. API Misuse failures are overwhelmingly Specification gulf problems -- the prompt didn't constrain tool-calling behavior, or the output format requirements were ambiguous, so the model improvised. Retrieval Gaps are Comprehension gulf problems -- the chunking strategy missed the relevant passage, or the embedding model couldn't bridge the vocabulary gap between the query and the document. Only the "Persistent Logic Failures" family -- where the model consistently produces wrong reasoning despite receiving exactly the right context -- genuinely maps to the Generalization gulf. The Three Gulfs framework from Topic 6 gives failure analysis its diagnostic backbone: once you know which gulf a family clusters under, you know which system layer to fix.

The relationship to production monitoring is upstream: T19 tells you something is wrong, T22 tells you why it keeps being wrong. The connection to the eval flywheel is direct -- labeled failure families are the raw material that feeds the flywheel.

In Practice

Step 1: Build the initial taxonomy from your own traces. Pull the last 100 failed traces. For each, label the visible symptom and the originating component. Cluster the results. You'll likely find 60-80% map to 3-5 structural causes.

Step 2: Separate symptom frequency from causal frequency. Build a symptom dashboard ("what users see") and a causal dashboard ("where fixes live"). The second is where the fixes are. The first is where empathy lives.

Step 3: Automate family detection. Tag every trace with model version, prompt version, environment, tenant, tool versions. Use automation rules to route traces matching family signatures into dedicated annotation queues.

Step 4: Connect each family to the eval pipeline. Add 5-10 representative traces per family to the eval dataset. Verify the CI gate catches each family. Assign an owner. Track incidence over time.

Step 5: Revisit quarterly. Pull the latest 100 failed traces. If more than 20% don't map to existing taxonomy, revise it.