Ninety-five per cent is not ninety-five per cent

Take an agent that is 95 per cent reliable at every individual step. Give it a task that requires twenty steps.

0.95²⁰ = 0.36

Thirty-six per cent. Roughly one task in three completes correctly, and the other two fail somewhere in the middle.

Now notice the part that makes this dangerous rather than merely disappointing. Every single step passed its own check. Nothing in your monitoring registered an error. The dashboard is green. The only party who experiences the failure is the person the work was for.

This is not a property of AI

It is the oldest result in numerical analysis, and it did not stop applying because we started calling the system an agent.

Some variants worth carrying around:

• 0.99²⁰ = 0.82. Even ninety-nine per cent per step loses roughly one task in five.
• 0.95¹⁰ = 0.60
• 0.95⁵⁰ = 0.077
• 0.999¹⁰⁰⁰ ≈ 0.368, which is 1/e, and which is worth saying out loud to any mathematician in the room.

The shape of the curve is the point. Per-step reliability that sounds excellent produces end-to-end reliability that is unusable, and the longer the trajectory the worse it gets. Agentic systems are being pushed toward longer trajectories precisely because that is where the value is.

The Vancouver Stock Exchange lost half an index this way

January 1982. The Vancouver Stock Exchange launches a new index at exactly 1000.000. It is recalculated on every trade, about three thousand times a day, and the result is truncated to three decimal places. Not rounded. Truncated, with the last digit simply dropped.

Each individual error is at most one thousandth of a point. Invisible. Undetectable. And every single one is in the same direction.

By November 1983 the index reads 524.811. It has apparently lost half its value during a bull market. Nobody can explain it. Over the weekend of 25 to 28 November 1983 the calculation is corrected and the index reopens at 1098.892.

Half an index, over twenty-two months, from an error too small to see. Nobody was negligent. Every individual calculation passed.

That is what is happening inside your twenty-step agent.

Two harder examples, for when the room needs them

Ariane 5, Flight 501, 4 June 1996. A 64-bit floating point value was converted into a 16-bit signed integer. The number did not fit. The rocket destroyed itself about forty seconds after launch. The code that failed was not even needed after lift-off; it had been inherited from Ariane 4, where the flight profile made the overflow impossible.

Dhahran, 25 February 1991. A Patriot missile battery had been running for around a hundred hours. Its internal clock accumulated a tiny error because 0.1 seconds cannot be represented exactly in binary. After a hundred hours the drift was about a third of a second, enough to misplace an incoming Scud by several hundred metres. Twenty-eight soldiers were killed.

I include the second one carefully and I never use it as a punchline. It is the most vivid illustration of accumulated rounding error in existence, and it deserves to be delivered soberly or not at all.

Why your monitoring is measuring the wrong thing

Most agent observability reports step-level metrics, because step-level metrics are what the system naturally emits. Each tool call returns success or failure. Each model response is scored for format, safety, latency. These aggregate into a comfortable dashboard.

The problem is that step success and task success are different quantities related by an exponent, and the exponent is doing all the work.

If your team reports step accuracy, they are reporting the wrong number. Politely, and usually without realising it, because the wrong number is the one the infrastructure hands them for free.

Measure the finished task. End-to-end success against a fixed set of real cases, scored the way the business would score it. Did the ticket actually get resolved? Did the claim get adjudicated correctly? Not: did every intermediate call return 200.

What this implies for how you build

Three consequences follow, and they are design decisions rather than tuning.

Shorten the trajectory. Every step you can remove improves reliability multiplicatively. A great deal of what agents are asked to do is deterministic workflow that has been handed to a model because the model was available. Decompose it: put the deterministic parts in code, and reserve the model for the ambiguous middle where judgement is actually required. A five-step agent at 95 per cent is 77 per cent reliable. A twenty-step one is 36 per cent.

Add checkpoints, not just retries. Retrying a failed step in isolation does not help if the failure was silent. The system needs points at which the whole trajectory is validated against the actual goal, not just against the last action.

Build the evaluation set before the agent. A fixed collection of real cases with known correct outcomes is the only instrument that can see the exponent. It is also the single most commonly skipped artefact in agentic delivery, because it is expensive, unglamorous and produces no demo.

The human version of the same problem

There is a mirror of this in how people use these systems, and it is worth naming.

An operator who is good at instructing a model but poor at judging its output will ship errors faster and more fluently than one who is bad at both. Strong description plus weak discernment is not neutral. It is negative, because it increases throughput of confidently wrong work.

The compounding happens in the organisation too, not only in the trajectory.