Why Failures Compound: The No-Recovery Bottleneck

Why Failures Compound is the arithmetic underneath the curve in Chapter 1. A long task is a chain, not a sample, and the properties of a chain are unforgiving in a way that averages conceal. The bottleneck that results is not intelligence. It is the absence of a path back.

Key takeaways

• Per-step accuracy multiplies. At 99% per step, a forty-step task finishes correctly 67% of the time; at 95% per step, 13%. Nothing about the model changes between those two numbers, and the outcome is unrecognisable.
• Benchmarks average over independent tasks, while a long task chains dependent steps. That single structural difference explains most of the gap between demo behaviour and production behaviour.
• A retry only helps when failures are independent. Re-running a step that inherited a wrong state produces a second confident answer built on the same false premise.
• Wrong state comes in three kinds, and only the first is cheap: in-flight state, persisted internal state, and effects that have already left your system. The third is the one that needs Chapter 6.
• More context does not repair this. One 2026 framework reports that memory scaffolds degraded long-horizon performance in their tests, which is the opposite of the intuition most teams start with.

Read this beside Chapter 1, which measured the horizon, and Chapter 5, which puts the cheapest possible check between steps. Chapter 6 handles the effects that cannot be taken back, and Chapter 7 gives the whole thing somewhere durable to live.

An agent is asked to migrate a service's configuration across forty steps. At step twelve it reads a value from the wrong environment. Everything after that is performed correctly, competently, and against the wrong target.

The run does not error. It completes, reports success, and produces a summary that is accurate about what it did and wrong about what it should have done.

The arithmetic nobody does before deploying

Take a step-level success probability and raise it to the power of the number of steps. That is the whole calculation, and it is rarely done out loud.

At 99% per step, ten steps succeed 90% of the time and forty steps succeed 67% of the time. At 95% per step, ten steps give 60% and forty steps give 13%. A model that looks four points worse per step is six times worse over a forty-step task. That gap is not a fact about intelligence. It is exponentiation.

Two corrections make the picture worse rather than better. Steps are not equally risky, so the effective rate is dominated by the handful of steps involving ambiguous input or irreversible action. And the number of steps is itself a variable the agent controls, which means a model that decomposes more finely can lower its own end-to-end success rate while improving on every individual step.

This is the mechanism behind the horizon curve in Chapter 1. METR's revised estimates of January 2026 measure where it bites for a set of tasks and models. The exponentiation is why the curve has to fall, and why it falls faster for task families with more dependent steps.

Averaging is the wrong mental model

Benchmarks report a mean over tasks that do not depend on each other. If a model scores 80% on a hundred independent problems, the failures are twenty separate events, each contained.

A long task is the opposite shape. Its steps share state, so a failure is not contained: it becomes the input to everything that follows. The distinction sounds obvious written down and it is routinely ignored in evaluation design, which is how teams arrive at production with a number that cannot predict their outcome.

Khanal, Tao and Zhou made the argument formally in March 2026, proposing that single attempt success be replaced with measures shaped for long horizons: a reliability decay curve, a variance amplification factor, a graceful degradation score, and a meltdown onset point. Their headline observation is that decay is domain-specific rather than uniform, with software engineering falling from 0.90 to 0.44 across the horizon while document processing stayed close to flat.

Two of their results deserve to change how teams choose models. Rankings shift at longer horizons, so the winner of your short evaluation may lose your long one. And in their tests, frontier models sometimes failed more, because they attempt multi-step strategies that weaker models never begin.

A retry does not repair an inherited state

The standard response to step failure is to try again. It is cheap, it is built into every framework, and its usefulness depends entirely on an assumption that long tasks violate.

Retries work when failures are independent: a timeout, a rate limit, a transient network fault. Re-running the call gets a different draw from the same distribution. That is the case durable execution frameworks are built for, and Chapter 7 is about using them properly.

Failures of judgement are not independent. If step twelve read the wrong environment because the prompt context made that reading look correct, then step twelve will read the wrong environment again, because nothing about the situation has changed. The retry produces a second wrong answer, with the same confidence, at double the cost.

Worse is the retry that happens after step twenty, on the theory that something downstream went wrong. Now you are re-running correct steps against a corrupted premise, which produces new and unrelated errors and destroys any chance of attributing the failure to its origin.

The rule this yields is simple to state and rarely implemented: retry transport, never judgement. A judgement failure needs detection at the step, not repetition of it, which is what Chapter 5's verification gates exist for.

The three kinds of wrong state

Recovery cost is decided by where the wrong state went, and the three cases are different enough to need different machinery.

Most agent architectures treat all three identically, which is why they can recover from none of them. The design consequence is that the boundary between the second and third rows is the most important line in your system. Everything before it is recoverable with local machinery, and everything after it involves somebody else's state.

Garcia-Molina and Salem named the general problem in 1987, in the paper that introduced sagas: a long-lived transaction is written as a sequence of transactions, and the system guarantees either that all complete or that compensating transactions amend the partial execution. Agent frameworks have spent two years rediscovering this and calling it reflection.

More context does not fix it

The intuitive remedy is memory. Give the agent a longer window, a summary of its own history, a retrieval store of past steps, and it will notice its own error.

The evidence does not support the intuition. The same March 2026 framework reports that memory scaffolds universally degraded long-horizon performance in their tests, which is a finding worth sitting with rather than explaining away. A plausible mechanism, and this is my reading rather than theirs, is that memory faithfully carries the wrong state forward: a summary of a run that went wrong at step twelve is a summary of the wrong premise, now compressed and authoritative.

That is the difference between memory and verification. Memory tells the agent what it believed. Verification tells it what is true. Only one of those catches a wrong commitment, and the cheap version of it is a comparison against an external source rather than an act of introspection.

Anthropic's engineering guidance from December 2024 arrives at a compatible position from a different direction, warning that agentic systems introduce the potential for compounding errors and recommending that complexity be added only where it is needed. The complexity worth adding is the kind that makes a wrong step visible.

Variance is the failure mode nobody plans for

Beneath the average sits a second effect that damages operations more than the average does.

The reliability-science framing names it variance amplification. As tasks lengthen, outcomes do not merely get worse on average, they spread out. Some runs finish cleanly, some fail early and cheaply, and some run for hours producing elaborate wrong work. Their finding that high variance correlates with capability level rather than with instability makes it stranger: the more capable system produces the wider distribution.

Operationally, that is the difference between a system you can plan around and one you cannot. A pipeline that fails 30% of the time predictably can be scheduled with retries and a human queue. A pipeline that fails 30% of the time with occasional four-hour excursions into confident nonsense cannot be scheduled at all, because the cost of a bad run is unbounded until something bounds it.

That is what the budgets in Chapter 9 are for, and it is why they include a wall-clock ceiling rather than only a token one.

The bottleneck, stated precisely

Put the pieces together and the constraint is specific enough to design against.

Failures are locatable. Wang and colleagues, working across four domains and more than 3,100 trajectories in April 2026 with a judge validated at a kappa of 0.84 against human annotation, show that long-horizon failures can be attributed to identifiable steps and causes. If failure were diffuse, only a better model would help. It is not diffuse.

What is missing in most systems is everything that would let you act on that. No record of the state before the failing step, so there is nothing to return to. No check at the step, so the failure is not observed when it is cheap. No compensation for effects already emitted, so an externalised error is permanent. And no bound on the run, so the cost of an unnoticed failure grows until someone intervenes.

That is the no-recovery bottleneck. It is an architecture gap rather than a model gap, which is the good news, because architecture is the part you control.

Chapter summary

Long tasks fail because chains multiply rather than average: at 99% per step a forty-step task lands at 67%, and at 95% per step it lands at 13%, so a small difference in step quality becomes an unrecognisable difference in outcome, made worse because risk is concentrated in a few steps and because the agent chooses how many steps to take. Benchmarks measure independent tasks and long work is dependent, which is the structural reason demo numbers do not transfer, and the 2026 reliability-science framing makes the point with domain-specific decay curves, software engineering falling from 0.90 to 0.44 while document processing held flat, along with rankings that reorder at longer horizons. Retries are the wrong instrument for judgement failures, because a step that inherited a wrong premise will produce the same wrong answer again, so the rule is to retry transport and never judgement. Wrong state comes in three kinds, in-flight, persisted internal, and externalised, with recovery cost rising sharply across that boundary and only the third requiring compensating actions of the kind sagas described in 1987. More context does not repair any of it, and one 2026 framework found memory scaffolds degrading long-horizon performance, because memory carries the wrong premise forward while verification checks it against something outside the agent. Variance amplification then turns a bad average into an unplannable operation. What is missing in most architectures is the record, the check, the compensation and the bound, and that gap is the no-recovery bottleneck.

Closing it starts with the plan. Chapter 3 is Decomposition as an Engineering Artifact, Not a Prompt: why the step list has to be a structure the runtime can read, check and resume from, what belongs in it besides the steps, and how a plan written as prose quietly removes every recovery option this chapter has just argued for.