A self-correcting agent loop works only when two conditions both hold: the marginal cost of one more iteration is trivial against the value it adds, and there is a convergence signal the loop cannot fake. Miss the first and the loop is a money fire. Miss the second and it never converges on anything real, it converges on the model's own sense of being finished. Most loops shipped today are missing the second, and their authors have not noticed because the demo looked autonomous.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.
Engineering commentary from someone who runs a lot of these in production, not a warning against agents.
What is everyone actually claiming about loops?
The claim is that reliability is a loop away, that if a model gets it wrong, you wrap it in a retry-reflect-improve cycle and the system heals itself. Generate, critique, revise, repeat until good. It is the most repeated architecture pattern of the year and it is on nearly every agent-framework landing page.
The pattern is real and sometimes correct. What is missing from the pitch is the two conditions that decide whether a specific loop is an improvement or an expensive way to stand still. Nobody sells you the conditions, because the conditions disqualify most of the loops.
What does a loop actually cost?
A loop costs its per-iteration price multiplied by however many iterations it takes to converge, and the second number is the one nobody puts on the slide. A single call has a knowable cost. A loop that runs until "good" has a cost that depends on how far the first attempt was from good, which is exactly the thing you could not predict or you would not have needed the loop.
The arithmetic is unforgiving on open-ended work. Five reflection passes is five times the tokens and five times the latency for one answer, and if the task is genuinely hard the loop does not stop at five. This is fine when tokens are effectively free relative to what the output is worth, a coding task that saves an engineer an afternoon justifies a lot of iterations. It is ruinous when the token cost per iteration is real and the value per iteration is small, which describes most of the loops being built to paper over a model that is not quite good enough at the job.
A loop converts a model's unreliability into a bill. Whether that is a good trade depends entirely on how cheap the iterations are and how much each one actually buys.
Cost visibility is its own problem, because provider spend alerts are delayed and account-level. A loop that fails to converge does not ring a bill until the invoice lands. What that actually costs to run is a separate post; the point here is that an unbounded loop is the fastest way to discover it.
What is the signal the loop converges on?
The signal is whatever tells the loop it is getting closer, and it is the entire ballgame, because a loop with no real signal is not iterating toward correctness, it is doing a random walk with a confidence meter attached.
Here is the failure almost everyone ships. The loop generates an answer, then asks a model, usually the same model, whether the answer is good. The model says yes. The loop stops. This feels like self-correction and is nothing of the kind, because the judgement is produced by the same weights that produced the error, carrying the same blind spots and the same self-preference bias that makes a model rate its own output generously.
A real convergence signal is external and cannot be talked into agreeing. A compiler either accepts the code or does not. A test suite passes or fails. A schema validates or rejects. A real-world action succeeds or throws. Those are signals a loop can genuinely climb, because the loop cannot argue with them. "The model thinks it is done" is not one of those, and a loop scored on it converges on self-satisfaction at whatever the model's error rate happens to be.
A loop without a verifiable signal is not self-healing. It is self-soothing, it stops when the model feels finished, which is not the same as being right.
When is a loop worse than a person?
A loop is worse than a person whenever it has neither cheap iterations nor a real signal, because at that point you have built a system that needs a human to judge every pass, and you are paying tokens for the privilege.
The comparison worth sitting with is the offshore team everyone is quietly trying to replace with one of these. A team is also a loop: attempt, feedback, revise. But the team's loop has a fixed and known cost, a feedback signal grounded in a real client and real consequences, and human judgement that improves across iterations rather than resetting each time. An agent loop missing the token economics and the signal has none of those three. It costs an unknown amount, it converges on its own opinion, and it does not learn between runs.
| Cost per iteration | Convergence signal | Learns across runs | |
|---|---|---|---|
| Loop with a real signal (code + tests) | Low, bounded by the checker | External, unfakeable | No, but does not need to |
| Loop with no real signal (model judges itself) | Unbounded | The model's own confidence | No |
| An offshore team | Fixed and known | Reality, and the client | Yes |
| A single deterministic function | One call | Not applicable, it is correct by construction | Not applicable |
The bottom row is the one to reach for more often. A great many loops exist to make a model do something a plain deterministic function does correctly on the first try, for free, forever.
What are the named failure modes?
Four, and each one is a loop that looked autonomous in a demo and became a liability in production.
The infinite reflection. No hard iteration cap, no real signal, so the loop runs until a timeout or a budget alert stops it. The output at the end is not better than the output at pass two, because nothing was pushing it toward better, only toward longer.
The self-graded loop. The generator and the judge are the same model, or two instances of it. It terminates quickly and confidently on wrong answers, which is worse than not terminating, because a confident wrong answer ships.
The human-in-every-turn. The loop technically runs, but each iteration needs a person to say whether it is closer. The autonomy was theatre; you have built a very expensive assistant for a human who is now doing the actual judging at every step, plus reading model output between each one.
The signal that was gameable. There was a checker, but the model learned to satisfy the checker without satisfying the goal, passing the test by special-casing the test, validating the schema with a technically-conformant but useless payload. A gameable signal is worse than no signal, because it manufactures false confidence.
When should you actually build one?
Build a loop when both conditions hold, and not otherwise. The two questions are cheap to ask and they save you from the four failure modes above.
SHOULD THIS BE A LOOP?
The Hopium Lab · v1.0 · 22 July 2026 · take it, fork it, argue with it
GATE 1, THE TOKEN ECONOMICS
[ ] What does one iteration cost, in tokens and in latency?
[ ] What is the value of the improvement one iteration buys?
[ ] If iterations were 10x the price, would you still run the loop?
If no, your margin is the token price, not the capability
GATE 2, THE SIGNAL (the one everyone skips)
[ ] What tells the loop it is getting closer?
[ ] Is that signal EXTERNAL, a compiler, test, schema, real outcome?
[ ] Or is it the model judging its own work? If so, it is not a signal
[ ] Can the model satisfy the signal WITHOUT satisfying the goal?
If yes, the signal is gameable and the loop will game it
THE HARD CAP
[ ] Set a maximum iteration count before you run it, not after
[ ] Decide what happens at the cap: escalate to a human, or fail loud
[ ] Never let "until it's good" be the termination condition
THE TEST: if you removed the loop and ran the model once, then had a human
judge it, would the loop still be cheaper and better? If you cannot answer
yes with a number, you have built a random walk with a confidence problem.
Both gates pass most cleanly for code with a test suite, structured extraction with a schema, and anything where a cheap deterministic checker already exists. They fail for open-ended generation with no ground truth, judgement calls a human would disagree about, and any task where the only available critic is the model itself.
The loop is not the saviour of AI reliability. It is a lever, and like every lever it multiplies whatever you push into it. Push cheap iterations and a real signal through it and it is genuinely powerful. Push expensive iterations and a fake signal through it and you have automated the production of confident, costly, unverified work, which is the one thing nobody needed more of.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.