---
slug: compounding-error
type: concept
summary: "Small per-step failure rates multiply across a long chain of dependent agent steps, so a model that is usually right still fails most long runs."
created: 2026-10-23
updated: 2026-10-23
related:
  agent:
    relation: depends-on
    note: "An agent takes many dependent steps toward one goal, which is what turns a per-step error rate into a per-run one."
  prompt-chaining:
    relation: depends-on
    note: "A fixed chain of model calls, each consuming the last one's output, is the simplest series the multiplication applies to."
  task-horizon:
    relation: informs
    note: "Task Horizon measures where the product of per-step reliabilities falls below usefulness; Compounding Error is the mechanism behind the measured curve."
  pass-k:
    relation: informs
    note: "Pass^k multiplies reliability across repeated runs of a whole task, while compounding multiplies it across the steps inside one run, and the two stack."
  hallucination:
    relation: enabled-by
    note: "A hallucinated false premise is the typical sticky early error that every later step builds on."
  context-rot:
    relation: enabled-by
    note: "Context Rot lowers per-step reliability late in a long session, exactly where the product is already smallest."
  verification-loop:
    relation: mitigated-by
    note: "Checking each change before building on it catches an error at the step that made it instead of at the end of the run."
  feedback-sensor:
    relation: detected-by
    note: "Compilers, tests, and linters report a bad step back to the agent before the next step consumes it."
  shift-left-feedback:
    relation: mitigated-by
    note: "Moving checks earlier in the run shortens the stretch of unchecked steps an error can travel through."
  fail-fast-and-loud:
    relation: mitigated-by
    note: "Surfacing invalid state immediately keeps a wrong intermediate result from becoming the premise of later steps."
  checkpoint:
    relation: mitigated-by
    note: "Verified checkpoints cut a long chain into segments, so a failure costs one segment rather than the whole run."
  git-checkpoint:
    relation: mitigated-by
    note: "A commit at each verified stage gives the agent a known-good state to return to when a later segment fails."
  task-decomposition:
    relation: mitigated-by
    note: "Breaking work into short, independently checkable units keeps each chain short enough to finish reliably."
  parallelization:
    relation: mitigated-by
    note: "Voting over several attempts at a step lowers that step's error rate, but only as far as the attempts fail independently."
  generator-evaluator:
    relation: mitigated-by
    note: "A separate evaluator at a hop boundary is redundancy that helps when its blind spots differ from the generator's."
  agent-teams:
    relation: informs
    note: "Every hop between agents adds a factor to the product, which is why more agents can mean lower end-to-end success."
  human-in-the-loop:
    relation: mitigated-by
    note: "A human review placed before an irreversible action is a verification step at the point where an uncaught error costs most."
---
# Compounding Error

> **Concept:** Vocabulary that names a phenomenon.

*Compounding error is the way small per-step failure rates multiply across a chain of dependent steps, so an agent that's right almost every time still fails most long runs.*

*Also known as: Compounding Errors, Compound Accuracy Problem, Lusser's Law (in reliability engineering)*

You've seen the demo. The agent reads the ticket, finds the right file, writes the change, runs the tests, and opens a clean pull request. Then you hand it a task four times as long and leave it overnight. In the morning you find the run went wrong somewhere around step 12 and kept going. Nothing about the agent changed between the two runs. The task got longer, and length is what this entry is about.

## Understand This First

- [Agent](agent.md) — an agent pursues one goal across many dependent steps.
- [Prompt Chaining](prompt-chaining.md) — the simplest chain, where each model call consumes the last one's output.

## What It Is

If each step of a run succeeds with probability p, and the run needs all n steps to succeed, the whole run succeeds with probability p to the power n. Reliability engineers call this Lusser's law: the reliability of components in series is the product of their individual reliabilities. Robert Lusser, a German engineer who had worked on the V-1 flying bomb, formalized it in the 1950s during missile-reliability work with Wernher von Braun's team in Huntsville, Alabama.

The product falls faster than intuition expects. Per-step reliability that sounds excellent turns into run-level reliability that doesn't:

| Per-step success | 10 steps | 20 steps | 50 steps | 100 steps |
|---|---|---|---|---|
| 90% | 34.9% | 12.2% | 0.5% | ~0% |
| 95% | 59.9% | 35.8% | 7.7% | 0.6% |
| 99% | 90.4% | 81.8% | 60.5% | 36.6% |
| 99.9% | 99.0% | 98.0% | 95.1% | 90.5% |

A "step" here is any action whose output the next action depends on: a tool call, a file edit, a handoff from one agent to another, a model call in a chain. An agent working on a real ticket can take dozens of these in a few minutes.

Agents add a second effect that the plain product hides. In a series of hardware components, a failed part stops working. In an agent's run, a wrong step usually produces an *output*, and the next step consumes it as input. A guessed test command, a misread requirement, or an invented config key becomes a premise, and every later step builds on it. That's how a run ends with a confident success report and a wrong result: each later step was locally correct given a false starting point. [Hallucination](hallucination.md) is a common source of these sticky early errors.

### Why the simple product is only a model

The p-to-the-n formula assumes each step succeeds or fails independently, with the same probability throughout. Real runs break that assumption in both directions.

**It can be too optimistic.** Errors correlate. The same blind spot that caused one wrong step tends to cause the next, and a false premise doesn't fail once; it shapes everything downstream. Per-step reliability also drifts down late in long sessions as [Context Rot](context-rot.md) sets in, which is exactly where the product is already smallest.

**It can be too pessimistic.** Agents notice and recover from many of their own mistakes. A failed compile or a red test is a step that went wrong and got fixed, not a run that died.

The measurements bear this out, though it took a revision to see it. Toby Ord found in 2025 that METR's agent results fit a constant failure rate for each minute a human would take on the task, which gives each agent a "half-life." He offered this entry's mechanism as the reason: long tasks are made of many subtasks, and failing one fails the whole. In early 2026 he revised the model. A reanalysis by Gus Hamilton fitted Weibull curves, a standard reliability model that lets the failure rate rise or fall over time, to the same data and found that for every model tested, the failure rate *falls* as a task goes on (shape parameters below 1, clustered near 0.6). Agents that survive the early part of a task are more likely to finish it than a constant-rate model predicts.

So treat p to the n as a mental model for why length hurts, not as a predictor. It tells you which direction length pushes and roughly how hard. Recovery, correlation, and drift decide the actual curve, and [Task Horizon](task-horizon.md) is where that curve gets measured.

## Why It Matters

The arithmetic sits under a whole family of patterns in this book that otherwise look like unrelated techniques. Each one changes a different term in the product.

**Shorter chains.** Fewer steps means a smaller exponent. Deterministic work done in code (formatting, file moves, schema generation) is a step the model doesn't have to get right. [Task Decomposition](task-decomposition.md) turns one long chain into several short ones that each finish reliably.

**Checks between steps.** A check doesn't make a step more likely to succeed. It stops a failed step from becoming the premise of the next one, so the error costs a retry instead of the run. The [Verification Loop](verification-loop.md), [Feedback Sensors](feedback-sensor.md), [Shift-Left Feedback](shift-left-feedback.md), and [Fail Fast and Loud](fail-fast-and-loud.md) all work this way. Checks pay most where an error would otherwise travel farthest: right after the first step, at branch points, before irreversible actions, and before a final summary that a human will trust.

**Saved progress.** A [Checkpoint](checkpoint.md) or [Git Checkpoint](git-checkpoint.md) bounds what a failure costs. Instead of one 30-step chain, you have six 5-step segments, and a failure sends you back one segment.

**Redundancy at each step.** Voting raises the per-step success rate itself. The extreme case is MAKER, from Elliot Meyerson and colleagues at Cognizant AI Lab in November 2025. In earlier experiments, models working through long tasks like Towers of Hanoi derailed within a few hundred steps. MAKER solved the 20-disk version, over a million moves, with zero errors by giving each move to its own minimal agent call, sampling several answers per move, and accepting one only when it led the others by three votes. It also threw away responses that were overly long or badly formatted, which the authors treated as signs of an unreliable sample. The model they chose for the full run erred on well under 1 percent of individual steps; voting took care of the rest.

The catch is independence, and it's easy to skip. Khush Patel and colleagues' *Six Sigma Agent* paper (January 2026) proves that majority voting over n independent samples, each wrong with probability p, gives a system error on the order of p raised to half of n, rounded up. In their experiments, a single agent wrong on 5 percent of actions dropped to about 0.11 percent with five voters.

The same paper bounds what happens when the voters' errors correlate, and estimates that correlation at about 0.4 for samples from the same model and about 0.08 across different model families. Plug those into the bound and it promises only that five same-model voters stay under about 2 percent error, while five diverse voters stay under about 0.5 percent. Clones with the same blind spot vote together for the same wrong answer. The paper's numbers cover model families; varying prompts or methods should help by the same logic, though that's an inference, not a measurement. No amount of voting fixes an error that every voter shares.

### The demo-to-product gap

Andrej Karpathy, describing why self-driving cars took so long, called the work "a march of nines." In his October 2025 conversation with Dwarkesh Patel, he said: "When you get a demo and something works 90% of the time, that's just the first nine." And: "Every single nine is a constant amount of work."

Compounding is why the nines matter so much for agents. Over 20 dependent steps, 90 percent per step finishes 12 percent of runs, 99 percent finishes 82 percent, and 99.9 percent finishes 98 percent. A demo shows you a short chain at the first nine. A long unattended run needs the third.

## How to Recognize It

- **Success falls with length, not difficulty.** The agent handles each piece of a task fine in isolation but fails the whole thing. Short tickets land; long ones don't.
- **Failures cluster mid-run, and the run keeps going.** Read a failed transcript backward from the end. If the visible failure traces to an earlier step that looked fine at the time, you've found a sticky error.
- **The final report is confident and wrong.** Every step after the bad one did its job correctly against a false premise, so the summary reads cleanly.
- **Adding a stage lowers end-to-end success.** A new agent hop, a new transformation, or a new handoff makes the pipeline worse even though the new stage is good on its own.
- **Retries without checks barely help.** Rerunning the whole task gives the same odds every time. Rerunning from a verified checkpoint gives far better ones.

> **💡 Tip:** To estimate how exposed a task is, count the dependent steps between checks, not the steps in the whole run. A 40-step task with a verified checkpoint every five steps behaves like eight 5-step tasks. At 95 percent per step, the unbroken chain finishes about 13 percent of the time, while each segment finishes about 77 percent of the time and a failure costs only that segment.

## How It Plays Out

A team asks an agent to migrate six database tables to a new schema overnight: for each table, write the migration, run it against a copy, backfill, verify row counts, and update the access code. That's about 30 dependent steps. The agent gets an individual step right roughly 97 percent of the time, which sounds safe, but 0.97 to the 30th is about 40 percent, and that matches what they see: most mornings, something went wrong partway and the later tables were built on it. They restructure the job so each table is its own segment, ending in a row-count check and a commit. A 5-step segment succeeds about 86 percent of the time on the first try, a failed segment rolls back to the last commit and retries, and the overnight run starts finishing.

A product team builds a three-stage agent pipeline to answer support tickets: one agent classifies the ticket, a second drafts a fix, a third writes the customer reply. Each stage is about 92 percent reliable alone, so the pipeline lands about 78 percent of the time. When they add a fourth agent to "polish" replies, end-to-end quality drops further, because a polished reply built on a wrong draft is still wrong. They remove it and put a reviewer at the boundary after the drafting stage instead, running on a different model family with a prompt that checks the draft against the ticket. Because its blind spots differ from the drafter's, it catches most of the drafter's wrong turns before the reply stage can build on them.

A developer is pleased with an agent that scaffolds new services: in her demos it gets a scaffolding step right nine times out of ten. She lets it run unattended on a larger job that chains 50 of those steps across a monorepo, and it fails almost every time. Nothing regressed. Ninety percent was the first nine, and 50 steps asked for the third.

## Consequences

**Benefits.** The concept gives you a reason to place each check, not a rule to check everything. You can ask how many unchecked steps an error could travel through, and put verification where that number gets large. It explains why decomposition, checkpoints, and verification loops work, so you can judge when one is worth its cost. It also corrects two common misreadings: that a model which usually gets things right is safe to run for long unattended stretches, and that running more copies of the same agent and voting always buys reliability.

**Liabilities.** The formula is easy to over-trust. Real per-step rates are rarely known, steps aren't equal, and recovery bends the curve in ways the simple product misses, so the table above is an illustration, not a forecast for your repository. Counting "steps" is fuzzy too: a single tool call can hide several decisions. And every remedy has a price. Checks cost time and tokens, checkpoints need state that can be rolled back, and voting multiplies inference cost by the number of voters.

Compounding error is also distinct from [Cascade Failure](cascade-failure.md), which is about failures spreading through coupled running services rather than errors multiplying through one run's sequential steps. The remedies overlap, but the mechanisms are different.

## Sources

- Robert Lusser's series-reliability rule, described in the *[Lusser's law](https://en.wikipedia.org/wiki/Lusser%27s_law)* entry, is the reliability-engineering origin of the product rule this entry applies to agent steps.
- Erik Schluntz and Barry Zhang, *[Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)* (Anthropic, December 2024), named "the potential for compounding errors" as a cost of agent autonomy and recommended sandboxed testing and guardrails.
- Toby Ord, *[Is there a half-life for the success rates of AI agents?](https://arxiv.org/abs/2505.05115)* (May 2025), modeled METR's results as a constant failure rate per minute of human task time and tied it to tasks built from many subtasks.
- Toby Ord, *[Hazard Rates for AI Agents Decline as a Task Goes On](https://tobyord.com/writing/hazard-rates-for-ai-agents-decline)* (February 2026), revised that model after Gus Hamilton's Weibull reanalysis showed failure rates falling over the course of a task.
- Elliot Meyerson and colleagues, *[Solving a Million-Step LLM Task with Zero Errors](https://arxiv.org/abs/2511.09030)* (November 2025), demonstrated extreme decomposition with per-step voting and red-flagging on a task of over a million steps.
- Khush Patel, Siva Surendira, Jithin George, and Shreyas Kapale, *[The Six Sigma Agent](https://arxiv.org/abs/2601.22290)* (January 2026), proved the error bound for majority voting over independent samples and quantified how correlated errors erode it.
- Andrej Karpathy's "march of nines" comes from his *[conversation with Dwarkesh Patel](https://www.dwarkesh.com/p/andrej-karpathy)* (October 2025), in the discussion of why self-driving took so long.

---

- [Next: Agent Workflow Graph](agent-workflow-graph.md)
- [Previous: Task Horizon](task-horizon.md)