When should an agent loop stop?
When the errors stop shrinking.

BPOS stops an agent loop by convergence, not by a count. After every pass, the errors it produced are compared with the passes before: no errors means done; fewer errors means go on; the same errors, returning errors, more errors, or as many different errors means stop. A fixed cap remains only as a last resort, and has not ended a single loop.

This article belongs to What BPOS runs. It covers what happens inside a job when a step fails its check; The quality gate covers what happens when the whole job is judged.

The problem with a cap

Until September, each of our retry loops ran to a fixed number of attempts. Two of them stopped early only when the error text came back exactly the same, which a shifted line number is enough to defeat. Everything else counted as progress: a loop alternating between two errors, a loop whose errors grew with each attempt. They ran to the cap.

A cap is a number, not a judgement. It lets a loop that is making things worse spend its whole allowance, and it cuts off a loop that was one step from finishing. It answers how many times, when the real question is whether the next attempt is worth paying for. Backoff, the usual companion of retries, answers when to try again. Neither answers whether.

Bounded is not converging

The first rule we wrote was simple: if the loop stays within bounds, let it finish; if it does not, kill it. It was not quite right, and mathematics says why. The Bolzano–Weierstrass theorem guarantees that a sequence that stays bounded has a part that converges, not that the sequence itself does. It can cycle forever. Our own records showed exactly that: an analysis of 2,799 multi-pass executions in May found loops trapped between two states and loops stuck in place.

What guarantees convergence is contraction, the condition of Banach's fixed-point theorem: each step smaller than the last by a ratio below one. A loop that contracts will arrive, and the ratio even estimates how many steps remain. So the rule became: a loop may go on only while it contracts.

How the errors are measured

A pass is measured by the errors it reported, whatever reported them: a compiler, a type checker, a build, a validator. Each line of the report becomes a signature, with every number masked, so an error that moves down three lines is still the same error. No language is parsed; the method reads plain lines, which keeps it the same for every language and every kind of check.

The signatures are counted as a multiset, not a set. Five copies of the same error in five places are five errors; fixing three of them is progress, not standing still. And errors from different checks are never compared with each other: when the check that produced them changes, the count starts again.

Seven verdicts

• Done: the pass is clean.
• Stuck: exactly the same errors as the previous pass. Stop; something has to change.
• Too early: fewer than three passes, too few to estimate the ratio. One more.
• Oscillating: the same errors as two passes ago. Stop.
• Growing: more errors than before. Stop.
• Continue: fewer errors than before. Go on.
• Flat: as many errors as before, but different ones: bounded, not shrinking. Stop.

There are no tuned thresholds. Fewer errors goes on and more errors stops; any finer threshold needs enough recorded stops to tune it, and every decision is recorded for that purpose.

What it has decided

Since 26 September the rule has decided 112 loops over 156 passes. 88 ended clean. 16 were stopped as stuck. Five were killed: two growing, two flat, one oscillating. Two ended because the step declared it was blocked, and one on an error. The last-resort cap, which is still there, ended none.

It started in five kinds of loop. Three of them, a compile retry, an inner correction loop and a claims validation, were retired on 29 September, when every job moved onto its skillset's procedure; as of 25 October 2026, the records of the last 10 days carry four kinds of loop: a job's own retries, and three loops that plan a job's units, composing them, reading each unit file, and listing the files they name. The record of the retired three stays, and all six loops the rule judged on a third pass came from them.

Starved, not idle

"Continue" has never fired, and five kills are far below the thirty or so it would take to tune anything. That does not mean the rule is useless. It means it has had almost nothing to judge. A contraction can only be seen from the third pass, and most loops never get there:

The six that reached a third pass were all stopped there, each on exactly the pattern a cap would have let run: errors that went 3, then 1, then the same 1 (stuck); twice 1, 1, 1 with different errors each time (flat); 9, then 1, then 3, and 7, then 8, then 9 (growing); and one loop that returned to its first errors (oscillating).

And the caps left it almost no room. The rule needs three passes before it can judge; the inner correction loop was capped at three, the unit correction loop at four, and the platform's review could send a job back only twice. Where the cap sits at the first pass the rule can judge, "continue" is cut off the moment it could be said. That was the defect, not the rule, and on 11 October it was removed: both limits are now parameters set to eight, kept only as a safety net far above the rule's window.

How we are feeding it

The retries that matter now happen at the level of the whole job: the platform's review sends a job back, or a person runs it again. Each attempt already records which acceptance criteria failed, which is the same kind of measure the rule uses.

• Wired to the job's attempts. Done, 11 October. Before the platform sends a failed job back, the rule now reads the series of its attempts and decides first whether another one is worth paying for.
• Given room. Done, 11 October. The limits that cut it off are now parameters set to eight, far above the three passes the rule needs.
• Replay the history. Next. Since 27 June, 55 jobs have three or more scored attempts, and 157 have two or more. Running the rule over them gives the first real picture of how often work contracts, and a check on the rule itself: after a stop verdict, did any later attempt succeed?
• Point it at the learning. Later. The same test applies to the platform's own learning: whether its readings of the record are settling from one night to the next, or still moving.

The numbers above are the record before those changes. The next measurement will be the first with room for "continue" to be said.

Common questions

Sources

• Stefan Banach, the contraction mapping principle (1922); the Bolzano–Weierstrass theorem.
• Our own records: every loop decision since 26 September 2026, to 11 October; scored attempts per job since 27 June 2026; the May 2026 analysis of 2,799 multi-pass executions.