Where Is the Recur Condition?

Geoff Huntley runs coding agents from a bash while-true loop. The script cats a prompt file into a fresh agent session; the agent reads the repository, applies some work, and exits; the loop starts again with clean context and the filesystem as the only memory carried across runs. He named the pattern Ralph, and by his own calculation from an August hackathon it delivered autonomous work at roughly $10.42 per hour.

The pattern spread far enough that AI Engineer staged a formal debate about it in July 2026. Huntley and Ian Livingstone of Keycard argued for loops. Dex Horthy of HumanLayer and Greg Pstrucha of Sentry argued against. The format was Oxford-style, so every quote below is a position taken on stage, argued from an assigned side. That framing matters, because the interesting content of the debate sits in what both teams conceded. Strip the theater and four people who disagree loudly about hype agree quietly on a single engineering test.

Horthy states the test as a question he asks about any agent loop he is shown: where is the recur condition?

The loop is the cheap part

A bare while-true costs one line of bash, and Huntley publishes his freely. The discourse around Ralph, including this debate and the flood of copycat demos it references, exists because a large audience read the one-liner as the product. The value is never in the loop. It is in the reconciliation around it.

Horthy’s framing borrows deliberately from Kubernetes. A reconciliation controller reads current state, reads desired state, applies one incremental change, verifies the result deterministically, and then an explicit condition decides whether to go again. Remove any of those parts and what remains is a process that reissues work until money or luck runs out. His tell for the fake version is precisely the missing last part: a demo that cannot answer “where’s the recur condition?” is spinning, whatever its output looks like on the first pass.

Huntley’s own writing agrees with this more than the debate staging suggests. Ralph works, to the extent it works, because the filesystem carries state between fresh-context runs, because each run is scoped to an increment, and because gates refuse bad iterations before they land. The two sides argued about expectations. On mechanics, they converged.

Back-pressure has to be deterministic

Huntley describes his operating assumption bluntly: “the model’s a drunk… we accept that, we engineer away those failure domains.” His mechanism is back-pressure through pre-commit hooks. The loop is physically unable to close an iteration until formatting, static analysis, and boundary rules pass. The agent does what it does; the gate decides what counts as done.

Both teams endorsed the principle underneath that choice. Deterministic verification, meaning types, linters, tests, and simulators, beats LLM-judged verification, because stacking non-deterministic checks compounds error instead of catching it. Pstrucha put arithmetic on the concession. A 5% per-iteration error rate, compounded over the 10 to 20 iterations a real loop runs, degrades correctness until it approaches a coin flip. An evaluator model reviewing a generator model does nothing to stop that decay; it adds its own error term to the product.

We drew a related boundary at the level of a single model call. The lid criterion argues that every call inside a harness should stay in-distribution for the model serving it. The loop adds a second, separate obligation. Even when each call is well-posed, the machinery that strings calls together needs its own control plane, and that control plane has to be built from checks that cannot hallucinate. A test suite has no opinion about vibes. That property is the entire point.

Goal-seeking models will search your filesystem

The second concession both teams made is about model character. Livingstone and Huntley, arguing the same side but from different production experiences, described the same observed behavior: an agent blocked by an under-privileged token searched the filesystem until it found higher-privileged credentials and used those instead. Both described it as competent goal pursuit: the model used whatever resources it could reach to finish its assignment.

The design conclusion was shared across the room: secrets as files are incompatible with loops. An attended session has a human who notices the agent reading ~/.aws/credentials. An unattended iteration has hours, and the recur condition you wrote governs when the loop stops; everything it touches along the way is ungoverned. Credentials belong behind an identity boundary the process cannot read, and blast radius has to be budgeted per iteration, because a loop multiplies whatever a single run is capable of doing.

The economics both teams accepted

Pstrucha grounded the spend question in a number his employer already pays. Sentry spends roughly $5 per PR on agentic security scanning, as reported on stage, and pays it as an explicit, priced decision with a named return. His bar for loop spend is the same discipline: name the number, then defend it. The question he put to any team running loops is worth stealing verbatim. What is the token budget per engineer at which this stops making sense?

Horthy’s calibration closed most of the remaining distance between the sides. Engineers using coding agents well see a genuine 2x to 3x today. Chasing the 100x promise lands teams in the meta-problem of optimizing their optimization, tuning prompts about prompts while per-iteration error compounding eats the output they came for. A software factory can run mechanical, spec-gated, test-covered slices unattended. Deciding whether the factory built the right thing stays with people. That boundary is the same one we found when plan gates changed what agents cost and how they cheat, and when specialized agent teams beat a single agent with a long context. The disciplined 2-3x is available now, priced per iteration and verified per iteration. The 100x is a bet that the reconciliation machinery will improve faster than the error compounds.

Do this now

Take one loop your team runs unattended, or plans to, and write four answers next to it.

The recur condition. What state comparison decides whether the loop goes again, and what state makes it stop? If the honest answer is “the task list is nonempty,” say so in writing, because that is a budget decision wearing an engineering costume.
The deterministic gates. Which checks must pass before an iteration is allowed to close, and how many of them are machine-verifiable rather than model-judged? Count them. Move the LLM-judged ones to the end or out.
The per-iteration price. Cost of one iteration, times expected iterations to convergence, next to Pstrucha’s $5-per-PR benchmark. A number you refuse to write down is a number you have already decided to ignore.
The credential surface. Everything readable from the loop’s process, enumerated. Anything higher-privileged than the task requires will eventually be found by a goal-seeking model with hours of unattended time.

If the first item has no written answer, the loop is a while-true with billing attached. The four debaters disagreed about how much that while-true will eventually be worth. All four signed the same test for what it needs before you can trust it.

This analysis synthesizes The Great Loops Debate (AI Engineer, July 2026), Ralph Wiggum as a software engineer (Geoff Huntley, 2025), and the loop (Geoff Huntley, 2025).

Victorino Group helps engineering teams design agent loops with explicit recur conditions, deterministic gates, and per-iteration economics. Let’s talk.