The Half-Life of a Loop

July 25, 2026 · markdown version

In 1821, Charles Babbage and John Herschel sat comparing two independently computed sets of astronomical tables, looking for discrepancies. They found them. Babbage’s reaction, as he told it later, was the sentence every engineer eventually says in some form: “I wish to God these calculations had been executed by steam.”

Two men in Regency dress at a desk, each bent over a separate stack of handwritten tables, comparing them line by line by candlelight — Two sets of tables, computed separately, read against each other line by line. It is the oldest verification method there is, and it tells you only that an error exists somewhere.

Look past the wish, at what they were doing. Two computations, run by hand, compared against each other, because a table is a long chain of small steps and every step carries a small chance of going wrong. Nobody could point at the error. They could only detect that one existed somewhere, and then go find it.

That procedure has a cost structure, and two centuries later it is the cost structure of every unsupervised agent run.

The schedule

Take a loop of n steps. Each step has some probability of going wrong, call it ε, and a step that goes wrong is not corrected: the mistake rides along to the end. Then the chance of a clean run is (1 − ε)ⁿ.

That formula is not the useful thing. The useful thing is the question you get by setting it to one half. After how many steps has the chance of a clean run been cut in half?

I call this the loop half-life, and the approximation is good to under one percent for any ε below two percent. At a one percent error rate per step, the half-life is 69 steps. At a tenth of a percent, 693.

Probability of a clean run, plotted against steps. The curves are computed, not drawn. A loop does not stop working at some length: it halves on a fixed schedule set entirely by the per-step error rate.

Nobody says “my agent gets unreliable somewhere past a few hundred steps” and means a decay constant. They mean a feeling. The half-life turns that feeling into a number you can compute from failure logs you already have, and the number tends to come in well under the ambition.

Why verification looks like overhead until it doesn’t

Now the part that actually changes decisions. Suppose you add a check that catches nine out of ten mistakes. You have improved ε by a factor of ten. Linear, unglamorous, and expensive: in the language of the last post in this series, you climbed one rung of the verifier gradient, and rungs cost real work.

At 300 steps, that factor of ten takes your chance of a clean run from 4.9% to 74.1%.

The same three error rates, read at one fixed run length. Each tenfold improvement in the per-step rate is linear work. What it buys at 300 steps is not linear at all.

So the value of a check scales with the length of the loop it sits in. In a five-step workflow, hardening verification is close to invisible, and the people calling it ceremony are describing their own experience accurately. In a six-hundred-step run it is the only thing that matters. Both camps are reading the same graph from different x-positions and concluding the other one is naive.

Detection is not correction

Here is where the arithmetic stops helping and starts misleading, because it suggests the strategy is to keep pushing ε down. That strategy is a treadmill. Every decade of improvement costs a new class of infrastructure, and all you have bought is a longer schedule of the same decay.

The way out is not a smaller ε. It is a different shape.

Suppose that instead of accumulating mistakes, each round of your loop takes whatever is still wrong and makes it less wrong, by some factor L. If L is below one, the remaining error after n rounds is Lⁿ times what you started with, and it goes to zero. Banach proved the general version in 1922: a contraction on a complete space converges to exactly one fixed point, from any starting position, regardless of how many steps you take.

The same number of iterations, two different shapes. On the left, length is exposure. On the right, length is progress. Nothing about the model changed between these two pictures, only where the findings go.

The sign flip is total. In a chain, running longer is exposure you have to survive. In a contraction, running longer is how you get there. Success stops being a die roll you passed and becomes an attractor you fall into.

Which gives a test you can apply to a single check, without any of the mathematics:

Does this step reduce the error, or does it only detect it?

A linter whose failure aborts the run is detection. It bounds the damage, it tells you something true, and it leaves ε exactly where it was. The same linter, with its findings fed back into the next iteration, is a contraction. Same tool, same output, opposite effect on how long the loop can safely run.

The only difference is where the arrow goes. Left, the finding leaves the system and the run ends. Right, the finding re-enters the work. One caps your damage, the other buys you length.

Babbage and Herschel were doing detection. Two tables, compared, discrepancy found, error hunted by hand. His engine went after the structure instead: a procedure with no room to drift, rather than a better check bolted onto one that did.

Close detail of the stacked brass gear columns of a nineteenth century mechanical calculating engine, front wheels sharp, the columns receding into soft focus — The engine was not a faster clerk. Each column constrains the next, so the arithmetic has nowhere to drift, which is a different thing from checking it afterwards.

The dangerous middle, again

The previous post landed on a warning: a weak verifier is worse than no verifier, because it launders trust into something that resembles evidence. The contraction view adds a second, independent way for a verifier to be weak, and this one is easier to miss because nothing about it looks broken.

A check can be perfectly valid and still buy you nothing. It reports correctly, every time, and the next iteration is no better than the last, because the report went into a log nobody reads or into a pass/fail gate with no path back into the work. Your dashboard is green about the check. Your loop is still a chain.

And the failure mode below that one has no name in most engineering vocabularies: L above one. A loop that breaks slightly more than it fixes on each pass. It does not stall, which is what makes it hard to spot. It runs, it looks busy, every round produces a diff, and after fifty rounds the error is eleven and a half times what you started with.

Left: any L below one converges, and how fast matters far less than whether. Right: at L = 1 the loop is pure activity, and just above it the loop is actively destructive while producing a diff every round.

The practical consequence is a bound rather than a policy. If you cannot show that your loop contracts, cap the iterations and escalate when the cap hits. That is the correct move under an unknown L, not a concession, and L is unknown far more often than people assume.

What I still can’t measure

ε is countable: failures per step, over enough runs, and you have it. L is the part I have not solved. Measuring contraction needs a distance to the goal, something you can evaluate against the target every iteration, and a diff between consecutive outputs is not that.

The diff is what everyone reaches for, though. A common convergence heuristic compares iteration N against N−1 and declares convergence when the change drops below a threshold. I have used it. It cannot distinguish a loop that arrived from a loop that got stuck, which are exactly the two cases at issue: a confidently wrong output that stops changing passes with full marks.

My best candidate is unglamorous. Where a loop already checks deterministic criteria, the satisfaction rate across iterations is a distance to the goal, and its slope from round one to round two estimates L. No new instrumentation, just arithmetic over logs that already exist. I have not run it yet.

Mathematics needed 2,300 years to stop trusting the searcher. It never had to think hard about whether its checking improves the next attempt, because there it always did: a rejected proof comes back with a reason attached, and the next version answers that reason. The feedback is so natural nobody bothered to name it.

We have to name it. The last post asked what would catch your agent being wrong. One more question, in the same breath: when it catches something, does the next round know?

A follow-up to The Verification Changelog, five posts on 2,500 years of verification history.
← The Untrusted Searcher