The Agent Loop

Sometime in mid-2026, in the middle of a routine “which coding agent should we standardize on” discussion, someone pulls up a single line of bash: `while :; do cat PROMPT.md | claude-code; done`. That, they say, is the whole trick — every polished “harness” writeup coming out of the labs this year is decoration on top of a loop one engineer wrote and gave away for free the previous summer. The room goes quiet. Ten minutes earlier, everyone had been comparing permission tiers, sandbox architectures, and verification gates as though they were evaluating distinct engineering disciplines. Now it sounds like they might be arguing about flavors of the same five-line script.

The comparison is not exaggerated for effect. In July 2025, engineer Geoffrey Huntley published a technique — quickly nicknamed “Ralph,” or the Ralph Wiggum loop, after the Simpsons character who tries the same thing over and over regardless of the result — that was, mechanically, exactly that one-liner: pipe a prompt file into a coding agent, indefinitely. Huntley used it to build a production-grade programming-language compiler and reported, in the same post, delivering a contracted rewrite for roughly $297 in API costs against an original $50,000 quote — a self-reported figure worth reading as a vivid anecdote rather than an audited benchmark, since nobody outside the engagement verified it. Nothing about the mechanism itself is exotic. State lives in three places on disk: a `specs/` directory the agent reads at the start of every pass, a `fix_plan.md` it updates as tasks complete, and an `AGENT.md` where it records build commands and mistakes it does not want to relearn. Each iteration picks one task, implements it, runs the tests, commits on a pass, updates status, and hands the next iteration a fresh context window and an updated file system — nothing carries over except what got written down.

Why the model resets and the disk does not

The interesting design choice in Ralph is not the loop itself — while-loops are the oldest idiom in programming — it is what the loop deliberately discards. Every iteration starts the model over: no memory of the previous cycle’s reasoning, no accumulated conversation to manage, none of the drift this library elsewhere calls context rot once a session runs long enough. The insurance policy against that self-inflicted amnesia is entirely external, and it has to be, because there is nowhere else for it to live. That is the same conclusion Volume II’s chapter on file-based memory reaches independently, from a different starting point: a standing file the agent both reads and writes, cheap enough to load unconditionally, durable enough to survive a reset. Ralph did not invent file-based state. It is simply the starkest possible demonstration of why a loop that forgets everything in-model needs it — there is no fallback memory to lean on when the process restarts every few minutes.

A loop that forgets everything is not a design flaw. Forgetting is the design — memory just moved to disk.

On why Ralph’s amnesia is structural, not accidental

The pattern shows up wherever the loop runs long

By late 2025 the shape had stopped looking like a hobbyist trick and started looking like infrastructure. Anthropic’s own guidance for long-running agents describes close to the identical cycle in production terms: an initializer session lays down a feature list and an `init.sh`, then repeated coding sessions each gather context from a progress file and git log, implement one feature, verify it against tests, and commit before the session ends — deliberately choosing a structured JSON task file over prose specifically because a model is less likely to inappropriately rewrite state it has to parse than state it can freely narrate. Independent practitioner accounts of “self-improving” agent loops describe the same four ingredients under different names, built for different reasons, with no apparent coordination between the authors. None of them necessarily set out to reproduce Huntley’s script. The convergence is the finding: teams optimizing for different goals kept landing on gather context, act, verify, repeat, with the file system as the only thing that survives.

The loop, named

It is worth naming the pattern plainly, because doing so demystifies something that otherwise sounds more sophisticated than it is. Strip away the specific tool, the specific model, and the marketing language built around “agentic harnesses,” and every one of these systems is running the same four-move cycle: gather context, by reading whatever state survived the last reset; act, by making one bounded change; verify, by checking that change against tests or an explicit success criterion rather than the model’s own say-so; and repeat, by committing, updating status, and discarding the in-model context before the cycle starts again. None of that description requires the sophistication a vendor blog post implies. It requires discipline about what gets written to disk, when, and in what format — which is exactly the discipline the rest of this library spends chapters unpacking rather than assuming.

The table below is not a new framework so much as a way of making the argument in the next section checkable. Every harness this volume examines executes some version of these four moves; the question worth asking of any specific tool is not whether it loops — it does — but what happens inside each move, because that is where a careful implementation and a reckless one diverge even when the outer shape is identical.

The claim that it is loops all the way down

By mid-2026 that convergence had hardened into a sharper argument, aimed less at demystifying the loop and more at deflating the industry built on top of it. One widely shared essay put the case plainly: read the serious 2026 harness writeups coming out of the major labs and platform companies, and each one describes essentially the same loop Huntley sketched in July 2025, with a layer or two added on top — better tool design here, a permission gate there, a verification step somewhere else. It is worth treating this claim on its merits rather than dismissing it for arriving through a blog post and a Simpsons reference instead of a peer-reviewed paper; the technical description underneath it, as the sections above show, holds up. Huntley himself had made a related, more philosophical version of the same point five months earlier, arguing that the shift underway in this kind of software engineering is from building line by line to running and supervising loops — that the loop is not one technique among several but close to the operating unit of how the whole class of system works.

What the claim gets right

Taken as a description of shape, the claim holds up against everything in this chapter so far. The four-move cycle really does appear, in some paraphrase, in every serious account of a long-running coding agent examined here. File-based state persisted across a memory-less model call really is close to structurally necessary once a team accepts that context resets and disk does not — which is why file-based memory reads less like a design choice this library recommends and more like a description of what any loop-shaped harness eventually has to do to survive its own amnesia. And naming the loop is useful on its own terms, not just deflating: an engineer who understands “agent” as gather, act, verify, repeat over persistent files has a real mental model to reason with, one that demystifies vendor language rather than being intimidated by it.

What the claim misses

Where the claim overreaches is in an implication it rarely states outright but that does most of the work in how it lands: that if the loop is universal, the engineering wrapped around it must be interchangeable, or trivial. It is neither, and the previous chapter’s benchmark evidence is the reason why — identical models, run through different harnesses on the same task, produce measurably different outcomes and costs, sometimes by a wide margin. A bash while-loop with no guardrails is not a production harness; it is the loop’s skeleton with every organ removed. Everything the remaining chapters in this volume cover — which tool designs actually reduce error rates, which permission architectures resist prompt injection instead of merely feeling cautious, how a sandbox contains a mistake instead of just slowing it down, what a checkpoint can actually roll back — is engineering that happens inside the four moves in the table above. None of it is visible from a description of the loop’s shape, and all of it is decisive for whether the loop is worth trusting with a production branch.

Even Huntley’s own account concedes as much. His write-up flags that the technique works best on greenfield projects and depends on a senior engineer watching the loop, noticing where it fails, and rewriting the prompt so the same failure does not recur. That caveat is the whole discipline this volume calls harness engineering, compressed into one sentence by the person with the least incentive to undersell his own trick.

What to check in a loop-shaped harness