# Compounding errors in agents: why ten steps at 95% each leave you with about 60%

> Each step works when tested alone, yet the whole flow still fails. The cause is a multiplication every FDE should do before making promises to a customer.

Original: https://fdetimes.net/en/guides/compounding-errors-ai-agents/

Picture a customer demo that goes smoothly. You have tested each step of the agent on its own, and every one is right about 19 times out of 20. Then the full ten-step flow runs on real data, and nearly two runs in every five produce a wrong result or stop halfway.

This is not bad luck. It is a multiplication, and you can work it out before writing the first line of code.

For an FDE, this calculation settles two things: how you design the flow at the customer, and which number you dare to promise them. Anyone who reports only per-step accuracy will sooner or later have to explain why production performs worse than the demo.

## Why does 95% become 60%?

The formula is simple. A chain of n sequential steps, each correct with probability p, succeeds as a whole with a probability of roughly p^n. With ten steps at 95%, 0.95^10 gives about 59.9%.

| Number of steps | End-to-end success rate (p = 95%) |
|---|---|
| 1 | 95% |
| 5 | about 77% |
| 10 | about 60% |
| 20 | about 36% |
| 50 | about 7% |

Mirantis built an almost identical table, with about 59% at ten steps, and observed that even at 95% per step, which is already very optimistic, the flow they analysed still failed about 40% of the time. Utkarsh Kanwat, an engineer who builds his own agents, arrived at the same figures and argues that 95% is optimistic for today's LLMs.

Try p = 99% and the point becomes clear: 20 steps still leave only about 82%. Polishing the prompt for each step helps, but a big jump in the number requires cutting steps.

## Why can the real number be worse?

The p^n formula implicitly assumes each step is independent and has fixed accuracy. Mirantis argues that in practice compounding errors are worse than pure multiplication.

A paper at ICLR 2026 gives a concrete reason: a model's per-step accuracy declines as the number of steps grows. The tenth step is no longer right 95% of the time as the first one was, so the "independent steps" model understates the problem.

Anthropic ran into exactly this when building its multi-agent research system. Its team wrote that agents are stateful, so errors compound. In its guide to building agents, it also states plainly that agent autonomy brings higher costs and the risk of compounding errors.

So treat p^n as an optimistic ceiling, not a forecast. If even the ceiling is low, the design needs to be redone.

## An example: an invoice reconciliation agent

Imagine a customer who wants to automate reconciliation of supplier invoices.

In the first version, the LLM drives all ten steps: classify the email, download the PDF, extract the invoice number, extract the total, normalise the date, look up the supplier code in the ERP, find the purchase order, match, write the result to the ERP and send a notification email.

Ten steps at 95% each leave the flow at about 59.9%.

Now ask one question of each step: does it need reasoning? Downloading the file, normalising the date, looking up the code in the ERP, writing the result and sending the email are all jobs for ordinary code. The email classification step disappears if the customer sets up a dedicated mailbox for invoices.

The two extraction steps can also be merged into a single call that returns data according to a schema.

```python
def reconcile(email):
    pdf = download_attachment(email)              # code
    fields = llm_extract(pdf, schema=InvoiceFields)  # LLM step 1
    check_fields(fields)        # positive amount, supplier code exists in ERP
    po = erp.find_po(fields.po_number)            # code
    verdict = llm_match(fields, po)               # LLM step 2
    save_checkpoint(email.id, fields, verdict)
    if verdict.status != "match":
        return queue_for_human(email.id, verdict)  # human gate
    erp.post(fields)            # irreversible action
```

That leaves two LLM steps: 0.95 times 0.95, about 90.25%. The code can still fail, but when it does it raises an exception rather than quietly inventing a number.

The 90.25% figure assumes the code steps never fail, so do not promise it to the customer. Log every end-to-end run, including exceptions from the download or ERP lookup steps, then divide the number of correct results by the total number of runs: that is the number to report.

The `check_fields` function stops obvious extraction errors before they move on. Every mismatch must wait for human review before it is allowed to touch the ERP.

**Key point:** To make an agent more reliable, cutting steps usually does more than polishing the prompt for each one.

## How do you shorten the chain?

The first move is to drop steps. Because probabilities multiply, every step removed lifts the whole flow's rate multiplicatively. Anthropic also advises finding the simplest possible solution and adding complexity only when it is truly needed.

The second is to move into code everything that needs no reasoning, with checks on intermediate results so errors do not spread to the next step. One analysis of long-running agents stresses that step-by-step recoverability has to be attached from outside the model, not left to the model itself.

The third is to check selectively. Checking after every step is expensive. Tian Pan's blog notes that human review is effective only when checkpoints are placed by risk, not on a fixed schedule.

In the invoice example, the riskiest points are right after extraction and right before writing to the ERP. Anthropic describes exactly this kind of design: the agent pauses for human feedback at checkpoints or when it hits a blocker.

The fourth is to let the flow resume after a failure. When an agent fails, Anthropic does not restart from the beginning but lets the system continue from where the error occurred, combining retries with regular checkpoints. The `save_checkpoint` line in the code above serves exactly that purpose.

## Common mistakes

The most common mistake is measuring each step and reporting that figure to the customer. Customers do not experience individual steps; they experience the whole flow. So measure end to end on real data from the first week.

The next mistake is adding a "reviewer" agent after every step. By the same multiplication, each added agent is one more step that can go wrong, not to mention the cost. Splitting a problem into many agents to look modern falls into the same trap.

The hardest mistake to spot is believing errors will reveal themselves. The most dangerous error is a field that is misread yet still looks valid. Checks should therefore compare against a source of truth such as the ERP or a schema, rather than asking the model again.

## Turn this calculation into a career advantage

On your CV, do not just write "built multi-step agents". Write that you cut the number of LLM steps from ten to two, and that the measured end-to-end success rate rose from one figure to another.

When an interviewer asks about agent design, draw the flow, count the steps and work out p^n on the whiteboard. The interviewer will see that you habitually think in terms of whole-flow outcomes, which is exactly what customers need.

The best agent at a customer is usually not the one that does the most steps. It is the one that hands the model only the steps code cannot do.

**Try this week:**

- Take an agent flow you are working on, list every step and mark which ones genuinely need LLM reasoning. Then calculate p^n before and after moving the remaining steps into code.
- Run the whole flow end to end on 20 real inputs and count the correct results, instead of measuring only per-step accuracy.
- Add a checkpoint just before the first irreversible action in the flow, so the next failure can resume from there.

## Sources

- [The Compound Accuracy Problem: Why Your 95% Accurate Agent Fails 40% of the Time](https://tianpan.co/blog/2026-04-20-compound-accuracy-multi-step-agent-pipelines)

- [Why I'm Betting Against AI Agents in 2025 (Despite Building Them)](https://utkarshkanwat.com/writing/betting-against-agents/)

- [Why Multi-Step AI Workflows Fail](https://www.mirantis.com/blog/why-multi-step-ai-workflows-fail/)

- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

- [How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)

- [The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs](https://arxiv.org/html/2509.09677v3)

- [Why Long-Horizon AI Agents Fail: Compounding Error, Memory as Infrastructure, and Step-Level Recovery](https://www.buildmvpfast.com/blog/why-long-horizon-ai-agents-fail-compounding-error-memory-2026)