Every run below is individually capped and provably bounded. Nothing here bounds the depth, which is the difference between a bound on a loop and a bound on a system of loops.
| Depth | Runs at this level | Spend at this level |
|---|---|---|
| 1 | 25 | $2,500 |
| 2 | 625 | $62,500 |
| 3 | 15,625 | $1,562,500 |
The arithmetic, so you can check it
End to end. A task that passes through n steps, each correct with probability p, succeeds with probability p raised to the power of n. That is the whole formula, and it is unforgiving because it is multiplication rather than addition.
At 95 percent per step: five steps gives about 77 percent, eight gives about 60, twenty gives about 36, and forty gives about 4. The model does not change across that curve. The prompt does not change. The only variable is how many steps the task took, which is why a three-step demo tells you almost nothing about a forty-step production system.
What the target requires. Invert it. To reach a target t across n steps, each step needs t raised to the power of one over n. For 95 percent across twenty steps that is about 99.7 percent per step.
The reason that gap feels smaller than it is: 95 and 99.7 look adjacent, and on the error rate they are not. Five percent error against 0.3 percent error is roughly a factor of seventeen. For this kind of system, near perfect is not the neighbour of good. Near perfect is the neighbour of failure, and getting from one to the other is the actual engineering.
The call tree. If a run can spawn b further runs and that nests to depth d, the number of runs at each level is b to the power of that level, and the total is the sum across levels. With b of 25, depth one is 25 runs, depth two is 625, and depth three is over 15,000. Every single node is individually and provably bounded. Nothing bounds the depth.
That is the difference between a bound on a loop and a bound on a system of loops, and it is how a system where one run costs about a hundred dollars produces a five-figure invoice without a single call misbehaving.
This assumes steps fail independently, and real systems are worse than that rather than better. Errors inherit: one wrong assumption early becomes the foundation every later step reasons correctly on top of, so the failures correlate in exactly the direction that makes the real number lower. Treat the output as an optimistic bound.
What to do with the number
If the end-to-end figure is below your target, the lever is not a better model. It is fewer steps, or verification between steps so an error cannot propagate, or a step that can reject a bad input rather than doing its best with it. In one real system that last change alone cut the cascading failure by 82 percent, with the same model and the same prompts.
If the call-tree figure is the alarming one, the fix is to carry one task identifier through every nested call and bound the task rather than the call: a wall-clock deadline, a spend budget, and a maximum depth, all enforced outside any individual agent and inherited by every child.
The reasoning behind both halves is in why your AI agents fail and why your agent will not stop.
Questions
Raise the per-step reliability to the power of the number of steps. At 95 percent per step a five-step chain delivers about 77 percent, a twenty-step task about 36 percent, and a forty-step task about 4 percent, with the model and the prompt unchanged across all of them.
About 99.7 percent, not 95 percent. Take the target end-to-end reliability to the power of one over the number of steps. The gap between 95 and 99.7 percent is roughly two orders of magnitude on the error rate, which is why no model release closes it.
Because a bound on a loop is not a bound on a system of loops. If each run can spawn further runs, the tree grows as the branching factor to the power of the depth, so twenty-five runs at depth one becomes 625 at depth two and over 15,000 at depth three, while every individual node remains provably bounded.
A rate limiter bounds requests per minute, and a runaway call tree is usually not fast. It is endless. Slow and endless is a different failure from fast and abusive, and only the second one trips a rate limit.