Agent loops: what survived the Ralph loop hype
Wrapping an agent in a while-true loop became a meme and then a movement. Once the hype cooled, what was left is the useful part: loops with a stopping rule, loops with verification, loops with a budget.
In 2025, Geoffrey Huntley named an embarrassingly simple idea the Ralph loop: put a coding agent inside a bash while true and let it run. The name comes from Ralph Wiggum — cheerful, naive persistence. He proved the point by leaving an agent to build a programming language, compiler included, over a long unattended run.
The trick caught on. It became a post, a talk, and eventually a package — Vercel Labs published a ralph-loop-agent for the AI SDK. And like every trick that catches on, it went through the phase where it was the answer to everything: “you do not need orchestration, just loop it.”
My read, a year later: the hype cooled, and that is good news. Because what survived is the useful part — and the useful part was never the while true. It is what you put inside it.
What the Ralph loop actually got right
Three things, and all three still hold.
Fresh context every iteration. Each pass spawns a new process with a clean window. That attacks long-context degradation head on, which is the single most common failure mode of coding agents. It is the same principle we built Relentless on: memory between iterations does not live in an endless conversation, it lives in git.
External memory on disk. State leaves the agent’s head and lands in files, commits, and artifacts — things that outlive the process and that a human can actually read.
Cheap persistence beats expensive brilliance. Twenty mediocre attempts with verification between them usually beat one brilliant attempt with no verification at all. That is statistics, not philosophy.
Where a dumb loop burns money
The loop was never the problem. The problem is a loop that answers none of the three questions that matter: when do I stop, how do I know it improved, and how much can this cost?
With no stopping rule, the agent oscillates. I have watched a loop spend a night swapping one abstraction for another and back again — commit A, commit B, commit A — each pass with a clean context, each pass convinced it was fixing something. Fresh context cuts both ways: the agent does not remember that it already tried this.
With no verification, the loop optimizes for appearance. The agent “finishes,” the loop asks whether it is done, and the agent says yes because the text it just wrote reads like a conclusion. Self-assessment inside a loop is a machine for manufacturing confidence without producing correctness.
With no budget, a judgment error becomes an invoice. Leaving an agent running with no ceiling on tokens, time, or iterations is the 2026 version of forgetting a cluster on over the weekend. At least the cluster does not commit.
Loops with a stopping rule: loop-until-dry
The pattern I reach for most is what I call loop-until-dry. You do not run until it is “done.” You run until the loop goes dry.
A round is dry when it produces no material change: no relevant file touched, no task closed, no new test passing. One dry round decides nothing — it might be bad luck. Two or three consecutive dry rounds, the K in your criterion, mean the work has genuinely run out. That is when you stop.
The detail that makes this work is measuring dryness in the artifact, not in the agent’s narration. An empty diff is dry. “I believe the implementation is now complete” is not.
Loops with verification: generate, refute, keep what survives
A good loop is not generate-and-repeat, it is generate-and-try-to-break. Each iteration becomes a small adversarial process: one step produces the artifact, another step — with its own context and an inverted objective — tries to refute it. Only what survives the refutation attempt lands in the repo.
An iteration only ships what survives the refutation attempt — and the whole loop stops when K consecutive rounds come back dry.
That changes what the loop optimizes for. Without refutation, it converges on what looks finished. With refutation, it converges on what holds up. And the cheapest refuter is almost never an LLM: tests, compilers, type checkers, linters, and schema validation knock down more per dollar than any review prompt.
It is the same adversarial verification I described in agent graphs, applied across time instead of across space.
Loops with a budget: ceilings declared up front
Any loop running unattended needs three ceilings declared before the first pass: maximum iterations, maximum tokens (or cost), and maximum wall-clock time. It also needs an exit behavior for hitting them — write a report of the current state, not vanish mid-flight.
Three ceilings declared before the first pass. On hitting any of them the loop writes down the state and stops — it does not vanish mid-flight.
Budget is an architecture decision, not just accounting. Once you know what a task is allowed to cost, you pick a model per node instead of using the expensive one everywhere. That is what became Relentless’s Smart Auto Mode: choose the model by the real complexity of the task rather than by fear of getting it wrong. The savings do not come from using a worse model — they come from no longer spending a frontier model on renaming a variable.
The loop is the engine, the graph is the map
“Loops or graphs?” is a false debate, and it cost a lot of good teams a year.
The graph is topology: who depends on whom, what can run in parallel, where the barriers and verifiers sit. The loop is dynamics: how many times a node retries before giving up, and what makes the whole thing advance until it runs dry.
They compose at two levels. Inside a node, the loop is local — try, verify, try again, with its own budget and its own stopping rule. Outside, the loop is global: the whole graph runs again while there is work left, and stops when K consecutive passes come back dry. A loop without a graph is expensive brute force. A graph without a loop is a pipeline that stalls at the first stubborn node and waits for a human.
A year after the meme, that is what survived of the Ralph loop, and it is plenty. Not the promise that persistence replaces architecture, but the proof that structured persistence is remarkably strong. The while true was the easy part. Stopping rules, refutation, and budgets are the work.
If you have ever left an agent running overnight and woken up to an invoice and no progress, the loop was not your problem. The missing three questions were. Talk to us or look at our agentic consulting — and if you want to see the engine, Relentless is open source.