Turning Production Agent Failures Into Regression Tests

Production agent failures rarely look like failures. The run finishes, the process exits clean, no stack trace fires, and the output still gets logged as a success. But the agent called the wrong tool, violated a policy nobody checked for, or gave an answer that any domain expert would reject on sight. This is the actual failure surface for agentic systems in production: not crashes, but quiet divergence from correctness that never trips an alert. Turning those silent failures into regression tests, the right way, requires a discipline most teams haven't built yet: attribute the failure to a specific harness layer, isolate the failing trace as something you can rerun on demand, and validate any fix by replaying it against that exact trace before it ships.

This math produces outcomes that are not forgiving. Tool calls in production fail somewhere between 3% and 15% of the time, depending on model size and task complexity. Run the arithmetic on a ten-step workflow where each step carries even a modest 5% failure rate, and the whole chain only completes successfully about 60% of the time. Some agent workflows in the wild fail closer to 41% of the time, a rate that would get a normal backend service paged into the ground. Classical regression suites were built for deterministic code paths: same input, same output, every time. Agents don't work that way. Their failures are probabilistic, sensitive to context, and often invisible unless someone is specifically looking for them. That means the old test infrastructure doesn't transfer, and teams need a different starting point altogether: real failures pulled from production, not synthetic test cases dreamed up in a sprint planning meeting.

What failure taxonomy research reveals about where to look first

Before opening a single trace, it helps to know where failures statistically cluster. The MAST taxonomy, presented at NeurIPS 2025, analyzed more than 1,600 production failure traces pulled from systems including ChatDev, MetaGPT, HyperAgent, AppWorld, AG2/AutoGen, Magentic-One, and OpenManus. The finding that matters most: 79% of multi-agent failures trace back to specification and coordination problems, not infrastructure faults, not model limitations, not broken tools.

Broken down by mode, the top three by prevalence were step repetition at 15.7% (a termination condition that was missing or too vague to act on), reasoning-action mismatch at 13.2% (the agent's plan and what it actually did drift apart), and unaware-of-termination at 12.4% (the agent just keeps going after the task is already done). Rolled up into root categories, specification problems accounted for 41.77% of failures, coordination failures for 36.94%, and verification gaps for 21.30%.

One caveat matters here. Most of this research runs on benchmark tasks, which are artificial by design. A separate analysis looking at 639,381 execution steps across 23,624 runs on a real production agent platform found a noticeably different profile: failures clustered around task incompleteness and verification gaps rather than coordination breakdowns. Agents that stopped short of finishing, or marked work as done without ever checking it, occurred far more often in the logs than agents that mishandled handoffs between each other.

A separate line of work, AgentErrorTaxonomy, breaks each agent run into five operational modules, memory, reflection, planning, action, and system-level operations, and attributes failures down to the specific module responsible. That's a finer-grained map than MAST offers. And ToolScan, presented at an ICLR 2025 workshop, narrows in specifically on tool use, cataloging seven recurring error types: insufficient API calls, wrong argument values, wrong argument names, wrong argument types, redundant repeated calls, wrong function names, and invalid format errors.

None of this tells an engineer what broke in this specific run. What it gives is a prior, a reasonable starting assumption that specification and verification layers are the most likely place to look first, statistically speaking. Confirming that in any given trace still takes real attribution work, which is where things get genuinely hard.

Why layer-specific attribution is harder than it looks, and why getting it wrong is expensive

The step where a failure becomes visible is almost never the step that caused it. That gap between symptom and cause is the core difficulty in agent debugging, and it's a bigger problem than it sounds.

Take an example from AgenTracer research: the actual root cause is at step 2, where a Web Surfer agent pulls a file with the wrong date attached. But that mistake doesn't become visible until step 11, once the evidence trail makes it obvious. Eleven steps that all look individually reasonable end up hiding a single upstream error. This is the pattern that trips up naive debugging every time: whoever's holding the bag when the failure surfaces (usually the last agent in the chain, reporting "no results found") gets blamed, when the real fault sits upstream in an agent that wrote an overly narrow search query three steps earlier.

Statistical, correlation-based diagnostic approaches make this worse, not better. They tend to misidentify downstream symptoms as upstream causes, generating attribution results that look confident and are wrong. Research on production incident diagnosis has documented a persistent attribution error rate around 10%, where diagnostic models blame technologies simply because they were mentioned in the incident thread, not because they caused anything.

Scale AI's Continual Search research adds another wrinkle: as execution logs get longer, LLMs tend to settle early on a plausible-sounding explanation and stop examining the rest of the trace. Evidence that would overturn the early guess sits unread further down the log. Attribution, in other words, is a search problem before it's a reading problem. Reasoning models built specifically for this task still struggle: step-level accuracy on failure attribution benchmarks like Who&When ranges from below 10% for smaller models on handcrafted traces up to roughly 13% to 32% for the strongest current models.

Misattribution carries a real cost. It's expensive. An engineer who fixes the wrong layer burns real time, leaves the actual failure sitting in production untouched, and sometimes introduces new instability on top of it: a prompt gets rewritten when the tool schema was the actual problem, and the next incident looks eerily familiar. Attribution has to be treated as a hypothesis that gets tested by rerunning the system, not a conclusion reached by staring at logs. That's the core of what's sometimes called the DoVer principle in this research, and it's the hinge the rest of this workflow turns on.

The six harness layers a failed trace must be attributed to before any fix is written

A useful equation from harness engineering: agent equals model plus harness. The harness, not the model, is where most of the actual engineering leverage sits, and it's where most failures live too.

Six layers separate cleanly. Prompt covers the system prompt, task specification, role definitions, and termination criteria, and specification problems, which MAST found account for 41.77% of failures, are closely tied to this layer. Tool covers tool selection logic, how arguments get built, schema compliance, and how outputs get interpreted downstream. Workflow covers orchestration: step sequencing, handoffs between agents, loop bounds. Memory covers retrieval correctness, whether context is fresh, and what gets truncated and when. Model is the LLM itself. Product logic covers task definition and what "done" actually means, and it's frequently where verification gaps originate.

Model should be treated as the residual category, the layer you land on only after ruling out the other five, not the default first guess. Given that MAST found 79% of failures sitting in specification and coordination, both categories that map onto the harness layers above the model, starting an investigation at the model wastes time pointed in the wrong direction from the start.

AgentDebugX frames debugging as a closed loop: Detect, Attribute, Recover, Rerun. The attribution step in that loop isn't just flagging that something crashed, it localizes the specific step and specific agent responsible. The six-layer model is what makes that localization something you can actually act on rather than just describe. Silent failure research backs this up directly: failures that keep every monitoring dashboard green and don't get discovered for hours or months very often trace to tool schema drift or prompt ambiguity, not model degradation.

Each layer tends to leave its own signature. Prompt-layer failures appear in step repetition, reasoning-action mismatch, or an agent that doesn't know it's done. Tool-layer failures appear in schema compliance errors, hallucinated arguments, and output that rots as it moves downstream. Workflow-layer failures appear in unbounded loops, missing step ceilings, and context that gets silently truncated. Memory-layer failures appear in stale retrievals or a context window holding the wrong information entirely. Labeling the layer at the moment of attribution is what makes the resulting regression test worth anything: a test tagged tool/schema gets exercised on a completely different axis than one tagged prompt/termination.

How tool schema drift and prompt ambiguity produce the failures that are hardest to catch before they become regressions

Tool schema drift is the quiet one. A field gets renamed, a new required property shows up, a flat key becomes a nested object, an enum changes, a validator gets stricter, a nullability rule flips. None of that throws an error most of the time. It produces a response that's malformed but still plausible-looking, and that response passes right through downstream logic until a human eventually notices the outputs are wrong.

The canonical version has an agent looking completely healthy in staging, sailing through every happy-path eval, then quietly falling apart in production because one tool argument changed from customer_id to account_id somewhere upstream. No outage banner. No stack trace. Just a slow drop in task completion and answers that get progressively stranger. Once that bad argument lands at step 2, it corrupts every step downstream that depends on it, and the corruption keeps compounding until it becomes visible, several steps later, as a wrong answer or an incomplete result. Benchmarks mostly measure final-output accuracy rather than checking whether intermediate tool calls were actually well-formed, so at the context lengths typical of real multi-step production workflows, schema failures slip past benchmark scores that look fine on paper.

Prompt ambiguity is the other big driver, and it maps directly onto the MAST numbers already mentioned: step repetition at 15.7% when termination conditions are missing or vague, reasoning-action mismatch at 13.2% when planning and execution drift apart, unaware-of-termination at 12.4% when completion criteria simply aren't specified clearly enough. Available evidence on production failures suggests that clarification failures tend to be a meaningful driver of breakdowns, which argues for treating ambiguity as a first-class branch to design around in an agent's decision graph, not an edge case to patch later.

Workflow loops round out the picture. An agent that can call tools indefinitely, retry without any ceiling, or spawn sub-agents recursively has no natural stopping point built in. A related trigger: the LLM hits its token limit, the framework quietly truncates the oldest messages, and the agent keeps operating with no signal that it just lost context it needed. Setting loop limits is a genuine calibration problem: too tight, and legitimate long-running tasks get cut off mid-flight; the right threshold comes from looking at observed p99 session lengths in actual production traffic, not a guess.

These three modes each demand a different kind of regression test. Schema drift needs fixtures that freeze what the tool actually returned. Prompt ambiguity needs assertions built around the termination condition specifically. Loop failures need step-count ceilings written in as explicit pass/fail criteria, not vibes.

Isolating the broken trace as a reproducible test case

A raw production trace is noisy. It carries the actual failure signal buried inside a pile of irrelevant context, environment state that can't be rebuilt later, and tool responses that were live and may never return the same thing twice. None of that is usable as a test on its own.

A trace that's actually reproducible needs four things. The exact input state at the attributed failure step, not the beginning of the run. Frozen fixtures capturing exactly what each relevant tool returned at each step, so a replay doesn't depend on a live API happening to answer the same way twice. A pass/fail criterion that's specific to the layer in question, "does the tool call argument match the expected schema" for a schema drift failure, "does the agent halt within N steps" for a termination failure. And the layer label itself, so the resulting test lands in the right part of the harness test suite rather than a generic pile.

AgentDebugX's portable, framework-agnostic trace format is what makes this practical rather than theoretical. It converts events from whatever framework produced them into a shared representation that can be re-analyzed, compared, and handed to another engineer. Without something like that, a trace captured in one runner simply can't be replayed against a fix written in a different one. AgentDebugX also proposes an Error Hub pattern: scrubbed bundles of failure, diagnosis, and repair, shared across teams so the debugging work accumulates as institutional memory rather than getting solved from scratch by whoever's on call that week.

What isolation is not: a full re-run of the agent starting from the original user input. That reintroduces exactly the variability that made the failure hard to catch in the first place. The better principle is to start at the attributed failure step, freeze everything that happened before it, and assert only on the layer-specific criterion. Smaller surface area, faster feedback, and no noise from steps that had nothing to do with the actual break.

Validating a fix by replaying it against the isolated trace before shipping

Attribution without rerunning the system is a guess dressed up as a diagnosis. That's the core of the DoVer principle mentioned earlier, and it applies just as directly to validating a fix as it does to finding the cause in the first place: apply a targeted edit at the layer you've implicated, rerun, and judge success by whether the milestone or utility outcome actually improved.

AgenTracer's counterfactual replay mechanism gives a concrete version of this logic. It annotates failed trajectories by swapping in oracle-corrected actions at the point of failure, and annotates successful trajectories through programmed fault injection, producing a dataset called TracerTraj. The same idea works for fix validation: the fix is the intervention, the replay is the test that either confirms it worked or doesn't.

Replay catches things code review misses on its own. A prompt edit that fixes the termination condition but introduces a brand-new reasoning-action mismatch a few steps later. A schema fix that resolves the immediate argument error but breaks a downstream step that was quietly depending on the old output shape. A loop bound that stops the runaway loop but also cuts off a legitimate long-horizon task before it finishes.

The benchmark evidence backs the structured version of this approach. AgentDebugX's DeepDebug repaired 13 of 73 failed GAIA tasks in a single rerun, compared with 4 to 6 for decoupled self-correction baselines that skip the attribution step, lifting overall accuracy from 55.8% to 63.6%. Separate causal inference work out of University of Illinois Urbana-Champaign and Stanford generates targeted fix suggestions and checks them through counterfactual simulation, and validated fixes there lifted overall task success by an average of 22.4% on the Who&When benchmark. Attribution followed by rerun consistently beats correction attempted blind.

Passing a replay means the isolated trace now runs to the correct outcome under the proposed fix, with the layer-specific assertion satisfied. That's the bar for promoting a fix into the regression suite. It does not mean the fix is safe across the entire distribution of production traffic, since replay only validates against the one failure it was built to catch. Broader safety comes from the wider eval suite, which this new regression test now becomes one small, permanent part of.

Promoting a validated fix into a durable, layer-labeled regression test

Once a fix passes replay, the promotion step is mechanical: the isolated trace, its frozen fixtures, and the layer-specific assertion together become one regression test, and the fix itself becomes the new baseline that test checks against from that point forward.

Organizing tests by layer label pays off the moment someone touches the harness again. A change to a prompt should automatically trigger every test tagged prompt/termination and prompt/specification, without anyone having to remember which tests are relevant by hand. That's the entire point of labeling at attribution time instead of after the fact: the label is what turns a one-off bug fix into something the team can actually build institutional memory on top of, trace by trace, layer by layer.