Why AI Agents Keep Failing in Production, and What the Math Says About Fixing Them Part 2

Part 1 established the math: compounding errors make autonomous multi-step workflows fail far more often than builders expect, and the benchmark numbers once corrected for contamination, scaffolding, and how "solved" is defined put frontier agents at 25%–60% per-step accuracy on real production work. Part 2 asks two harder questions: where, specifically, do the failures concentrate, and what has the research literature tried in response?

How agents actually fail

The most rigorous answer in 2026 is the MAST paper, "Why Do Multi-Agent LLM Systems Fail?" (arXiv 2503.13657, Cemri et al., last revised October 2025). The author lineup is unusually strong: Mert Cemri, Melissa Pan, Shuyi Yang and colleagues, supervised by Ion Stoica, Matei Zaharia, Joe Gonzalez, and Dan Klein at Berkeley with Stanford collaborators. The methodology: 1,600+ annotated traces across seven popular multi-agent frameworks, manually categorized by six expert human annotators. Cohen's kappa on inter-annotator agreement is 0.88 high enough to take the categories seriously. MAST identifies 14 distinct failure modes in three categories.

Category 1: Specification issues (44.2% of failures)

Nearly half of all failures trace to how the task and agent's role were specified at design time not to the model's in-the-moment reasoning. Disobey task specification (15.7%): the agent ignores or misinterprets an explicit instruction. Replit Incident 1152 lives here the agent was instructed to freeze code and refused to honor the freeze. Step repetition (13.2%): the agent unnecessarily repeats work it already did, wasting tokens and sometimes corrupting state. Loss of conversation history (8.2%): the agent forgets what was said earlier in the run. Unaware of termination conditions (6.2%): the agent does not know when to stop, so it keeps going past the goal, sometimes destructively. Disobey role specification (1.5%): the agent steps outside its assigned scope.

This is the failure family most amenable to engineering: clearer prompts, tighter role definitions, explicit termination conditions, deterministic memory management. It is also the family that disappears most slowly in practice, because every new task requires the design work to be redone, and the operator usually does not know which design choices matter until something breaks.

Category 2: Inter-agent misalignment (32.3% of failures)

Fail to ask for clarification (12.4%): the agent makes assumptions when it should have asked. This shows up constantly in real deployments the agent picks an interpretation, runs with it, and downstream work is wrong. Task derailment (7.4%): the conversation drifts away from the original goal. Information withholding (6.8%): one agent has critical information and fails to share it the MAST paper describes a phone agent that discovered correct login credentials but did not share them with the calling agent, which kept trying with wrong credentials. Reasoning-action mismatch (2.8%): the stated reasoning does not match the action taken, producing the eerie post-hoc confessions we saw in Incident 1152.

This category is the most distinctly multi-agent. Single-agent systems do not have inter-agent communication failures by definition. The implication: adding more agents to a system does not monotonically improve performance. MAST's broader finding is that multi-agent systems often show minimal performance gains over single-agent baselines. Every additional agent adds an interface, and every interface is a place where information can be lost, withheld, or ignored.

Category 3: Task verification (23.5% of failures)

No or incomplete verification (9.1%): the agent never checks its work, or checks only part of it. Premature termination (11.8%): the agent ends the task before completion. Incorrect verification (2.2%): the verification step exists but is flawed, missing real errors or flagging false positives. A quarter of all observed failures concentrate at the last mile. The agent did the work sometimes correctly but failed to confirm or terminated too soon. This is the category most directly addressable by human-in-the-loop, for the obvious reason that humans are good at verifying a small number of high-stakes outputs and the verification step batches naturally in a way the rest of the workflow does not.

What the SSRN paper adds

The SSRN paper "Nonstandard Errors in AI Agents" (Gao and Xiao, March 2026) deployed 150 Claude Code agents to independently analyze NYSE TAQ data and test six hypotheses about market quality. The interquartile range of effect-size estimates across agents was 2.43% per year for one hypothesis, ranging from -0.74% to +1.7% per year. Same data, same hypothesis, dramatically different conclusions. This frames the same underlying phenomenon agents are stochastic and inconsistent as analytical degrees of freedom rather than a failure taxonomy. Both framings are valid.

The most useful finding from SSRN is what worked and what did not in their three-stage feedback protocol. AI peer review agents critiquing each other's work in writing had minimal effect on dispersion. Exposure to top-rated exemplar papers reduced the interquartile range by 80%–99% within converging measure families. Agents do not converge by talking to each other. They converge by being shown what good work looks like. This cuts against pure self-correction architectures and in favor of architectures that surface high-quality reference outputs as part of the agent's context.

Three families of resolution

If compounding math is the disease, what are the cures? The literature offers three serious families, each of which works in its domain and none of which generalizes cleanly to non-technical operators running messy multi-step workflows.

Decomposition and voting

The strongest published result is the MAKER paper (arXiv 2511.09030, Meyerson et al., November 2025). The headline claim: a system that solves a task with over one million LLM steps, zero errors. Two pieces. First, decompose the task to an extreme degree, breaking it into the smallest possible atomic subtasks. Second, at each subtask multiple agents vote, and a "first-to-ahead-by-K" protocol resolves the vote with statistical guarantees on correctness. The result is real. The math is correct. It is demonstrated on Towers of Hanoi a closed-form domain with provably correct answers for each subtask. The hard question MAKER does not yet answer: whether the decomposition can be done at all for open-ended messy real-world tasks where there is no canonical decomposition and no oracle to check each subtask against.

For workflows a non-technical operator runs manage the customer pipeline, send the weekly investor update, chase outstanding invoices, post to social with brand-consistent voice the decomposition is the part they cannot do. They are not technical. MAKER's resolution is real and important and does not transfer.

Trust-aware orchestration

The IEEE Access paper "Agentic AI with Orchestrator-Agent Trust" (Roumeliotis et al.) builds an architecture that separates perception from meta-reasoning. The orchestrator uses calibration metrics and similarity-based retrieval to decide when to trust an agent and when to trigger re-evaluation, achieving a 77.94% accuracy improvement in zero-shot on a narrow domain. Two structural problems generalize: verification is sometimes harder than production (for tasks with no clean ground truth, a verifier agent has no real way to know whether the producer agent is correct), and calibration is hit-or-miss across models and domains. The SSRN finding that AI peer review had minimal effect is the cleanest evidence of the second problem.

Exemplar-based convergence

The most interesting SSRN finding: peer review had minimal effect; exemplar exposure reduced variance by 80%–99%. The implication: the most effective way to reduce agent variance is not to add another verifier to the pipeline, but to give the agent access to high-quality reference examples of correct work. In a production context, those reference examples are typically generated by humans approving or rejecting agent outputs over time, building a corpus of "this is what good looks like" for that specific workflow. This gestures at a hybrid architecture: human-in-the-loop approval as a mechanism for building the exemplar corpus, not just a safety gate.

What none of these solve

None of the three families fully solves the non-technical operator case. MAKER's decomposition requires technical sophistication the operator does not have. Trust-aware orchestration requires calibration signals that are unreliable in general-purpose settings. Exemplar-based convergence requires a corpus that does not exist on day one. What works structurally for this operator profile is putting a human in the loop at the right places. That argument is Part 3.