Field Guide · Agentic Engineering

Designing Loops, Not PromptsA Field Guide to Agentic Loops — and Who Holds the State Machine

Everyone is sorting agentic loops by what triggers them. That is the easy axis. The one that actually predicts whether a loop is worth running is who holds its state machine — and the loops that compound keep their state outside any single agent.

By Scott Farrell · LeverageAI · For builders of compounding-AI-research systems

On June 7, 2026, Peter Steinberger — the creator of OpenClaw — posted two sentences that the entire AI-coding timeline then spent a week arguing about:

“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
— Peter Steinberger (@steipete), June 2026¹

It landed at around six and a half million views with no diagram and no repo link, which is exactly why it ricocheted: it named a shift everyone could feel but nobody had crisply stated. The head of Claude Code at Anthropic, Boris Cherny, made the same point at Acquired Unplugged in June 2026 — he no longer prompts the model directly; his job is to write the loops that prompt it.² Google’s Addy Osmani gave the wave a name: loop engineering.³

For two years the posture was simple. You wrote a good prompt, fed enough context, read what came back, and typed the next thing. The agent was a tool and you held it the entire time, one turn after the other. The prompt was the instruction; you were the loop. What Steinberger is naming is the moment that posture ends — the loop becomes a small system that finds the work, hands it out, checks it, records what was done, and decides the next thing, while you watch instead of type.

That much is now consensus. The interesting question starts one level down. Once you accept that you are designing loops, what kinds of loops are there, and which one should you build? The standard answer is a taxonomy by trigger. It is correct, and it is not enough. This piece gives you that taxonomy, then a second axis underneath it that actually predicts whether a loop will hold up — and a test you can run on a loop you operate today.

One scoping note, because it changes every recommendation that follows. This is written for the builder standing up loops for AI research, trial projects, building things that build things — compounding the knowledge in a self-maintaining wiki, not shipping regulated production code. The reliability engineering you would do for a bank is a different essay. Here, the loop’s product is rarely merged code. It is knowledge that makes the next loop better.

The four loop types, by trigger

The cleanest field demonstration of the taxonomy in the wild comes from Theo Browne (t3.gg), who has been running these loops hard and filming the results. Sorted by what starts each loop, there are four.

1. The self-paced linear loop (the Ralph loop, /goal)

One thread, one task, a stopping condition, and an “are we done? no? keep going” check at the end of every turn. This is the Ralph loop, coined by Geoffrey Huntley in July 2025 and almost insultingly simple in its purest form:⁴

while :; do cat PROMPT.md | claude-code ; done

Huntley calls it “a bash loop that feeds an AI’s output (errors and all) back into itself until it dreams up the correct answer… brute force meets persistence,”⁴ and, more memorably, “deterministically bad in an undeterministic world.” The non-obvious detail is that fresh context every iteration is the point, not a side effect: models degrade as their context fills, and a bash loop sidesteps the drift by starting clean each pass. His instruction to operators — “sit on the loop, not in it” — is the whole posture in five words. Anthropic later shipped supported equivalents: /loop, /goal, the ralph-wiggum plugin.

The structure is fixed; only the content changes each iteration. Cheap to reason about, easy to steer. But it cannot restructure itself — it grinds toward a goal along a predefined path. The failure mode is exactly what you would predict: on a long run, the error rate climbs, because nothing external is checking the work mid-flight.

2. The scheduled / cron loop

Same machinery, but the trigger is a clock. The interesting property is not the timing — it is that the loop is decoupled from your attention. You wake up to a PR. Steinberger’s own “simple loop” is the canonical shape: “Tell codex to maintain your repos, wake up every 5 minutes and direct work to threads,”¹ routed through an orchestrator skill so some work lands autonomously.

The instructive degenerate case is a keep-alive cron whose entire job is to ping a rate limit so a precondition stays warm for other loops. That is worth internalizing: scheduled loops are frequently infrastructure for other loops, not value producers themselves. Do not mistake the heartbeat for the work.

3. The event-triggered loop

Now the trigger is external state changing in the world: a review comment lands, a CI check goes red, a new PR head appears. Theo’s sharpest pattern here is two agents unaware of each other on one PR — one produces, one reviews, and the PR itself is the shared blackboard between them. Neither holds the other’s state. This is more robust than the linear loop precisely because the coordination medium is durable and external. If either agent dies, the state survives on the PR. Hold onto that sentence; the next section is built on it.

4. The agentically-initiated dynamic loop

This is the frontier, and it deserves its own section, because it is not “type 1 but fancier.” It is a different kind of object. We will come back to it after we install the axis that explains why.

The axis that actually matters: who holds the state machine

The trigger taxonomy tells you when a loop fires. Starting is the cheap part. The axis that determines whether a loop is worth running at all is who holds its state machine — where the “where are we, what’s done, what’s next” lives between turns. There are three answers, and they are a ladder of durability.

This is not a new claim for us; it is the spine of the long-running-agents work. The counter-intuitive truth there was that agents which run for ten hours don’t stuff everything into context — they implement stateless workers plus stateful orchestration. The agent is stateless; the orchestration is stateful; state persists externally.⁵ State inside the agent evaporates when the context resets. State outside it compounds. The whole “1-hour ceiling” is an architecture choice, not a model limitation.⁵

So restate the event-triggered loop’s robustness in these terms, because it is the proof of the axis. The two-agents-on-a-PR pattern is robust because the state machine is held by the PR, not by either agent. The producer doesn’t hold the reviewer’s state and the reviewer doesn’t hold the producer’s; both read and write a durable, external blackboard. Durability beats coordination. You do not make a multi-agent loop reliable by making the agents coordinate better. You make it reliable by putting the state somewhere that survives any one of them.

The trigger tells you when a loop fires. Who holds the state machine tells you whether it survives. Optimise the second one.

The same four types, now as one dial: Karpathy’s autonomy slider

Once you sort loops by how much of the state machine you’ve handed over, the flat list of four becomes a spectrum — and Andrej Karpathy already named the spectrum. In his June 2025 talk “Software Is Changing (Again),” he described an autonomy slider, drawn from his years on Tesla Autopilot:

“Depending on the complexity of the task at hand, you can tune the amount of autonomy that you’re willing to give up for that task.”
— Andrej Karpathy, “Software Is Changing (Again),” June 2025⁶

His image for it is the Iron Man suit: “it’s both an augmentation and Tony Stark can drive it. And it’s also an agent… this is the autonomy slider. We can build augmentations or we can build agents.”⁶ The prescription he closes on is not “max autonomy” — it is the opposite: “this is one way of keeping the AI on leash… and the AI is not getting lost in the woods.”⁶ He warns builders are getting “way too excited” about fully autonomous agents. “It’s less Iron Man robots and more Iron Man suits that you want to build.”⁶

Map the four loop types onto that dial and the taxonomy lifts from a list into a setting you choose:

This is the synthesis the three authorities give you together, and it is worth keeping their contributions distinct: Steinberger supplies the reframe (design loops, not prompts); Theo supplies the demonstrated taxonomy and the type-4 loop in the wild; Karpathy supplies the slider that turns the four types into a spectrum of handed-over control. Software 3.0, in his framing, is the world where “you program them in English”⁷ — and the loop is how you program in English at scale, without holding the tool every turn. The slider is the reminder that “at scale” is not the same as “all the way to the right.”

The actual phase transition: loops that write loops

Now we can say precisely what makes type 4 different. The first three loops are loops you designed. The structure is fixed; only the content changes each turn. The fourth is a loop that designs its own sub-loops at runtime. That is not a quantitative jump up the slider. It is a change of category — the point on the dial where the agent stops running your state machine and starts writing one.

Theo’s concrete instance is the one to hold in your head. In a PR-audit workflow, the agent did not call a workflow feature. It wrote roughly 240 lines of throwaway JavaScript that defined its own phases, schemas, prompts-as-functions, and a pipeline — and then that code orchestrated the sub-agents through it. His line is the one to internalize:

“You can never be more dynamic than code… when the agent can write code, it is effectively building its own custom feature every time.”
— Theo Browne (t3.gg)⁸

Read that twice, because it inverts how most people think about code in agent systems. Code is usually the agent’s output — the thing it produces and you ship. Here, code is the step between model runs. A hard-coded workflow primitive forces the agent into your pre-built shape: here are the phases you may use, here is how to structure a prompt. Letting it write the orchestration code means the shape of the loop matches the shape of the problem — including problems you never anticipated when you built the harness. A fixed feature can only ever be as dynamic as the cases its author imagined. Code the agent writes on the spot has no such ceiling.

We have argued the same move before, from the other direction: the most profound capability is not that agents write code, it is that they “write code that writes code, build tools that build better tools.”⁹ Type 4 is that idea pointed at the loop itself — the agent building its own orchestration the way an engineer would reach for the right control structure, except it reaches at runtime, per problem.

The cost is real and worth stating plainly. It is non-deterministic — the model sometimes writes invalid code while pushing limits. It is more expensive. And you lose the legibility a fixed primitive gives you: you can read your own pipeline, but you cannot fully predict the one the agent will write tonight. For regulated production, that trade is usually wrong. For research and exploration — surfacing structure you didn’t know to look for — it is exactly right, because you are not optimising for repeatability. You are optimising for the agent discovering a shape you couldn’t have specified.

Durability beats coordination — and a loop needs something that can say no

The single best external line in the whole loop-engineering discourse was a reply under Steinberger’s tweet, from @mosyaseen:

“Designing the loop is half of it. The other half is putting something in the loop that can say no: a test, a type check, a real error. A loop with nothing to push back is the agent agreeing with itself on repeat.”
— @mosyaseen¹⁰

This is the leash, stated operationally. The Ralph loop’s error rate climbs on long runs for exactly this reason: nothing external pushes back mid-flight. Anthropic’s supported /goal ships a closer as a feature — after each turn, a separate fast evaluator model judges whether the success condition holds; the model doing the work is not the model grading it. That separation is the whole point. A loop grading its own work is the agent agreeing with itself.

Notice that the closer and the durable medium are usually the same object. The PR is both the shared blackboard and the place a red CI check can say no. The wiki is both the external state and the place a consolidation can be reverted if it merged two ideas it shouldn’t have. This is why durability beats coordination is not a slogan: the durable external medium is simultaneously what survives an agent dying and what gives a second, adversarial process something to push back against. State held inside one agent can do neither.

The minimum viable version of this — the leash you can rig tomorrow with no new tools — is four things: external state persistence (get progress out of the context window into a file), explicit completion criteria (verifiable conditions, not “feels done”), checkpoint discipline (compress and persist after each step), and context hygiene (evict cold data aggressively).⁵ Those four turn a Ralph loop from a thing that drifts into a thing that holds. They are also, not coincidentally, the four moves that put the state machine somewhere durable.

The compounding test: accumulate, or become the substrate

Everything so far applies to any loop. Here is the part written specifically for the reader building things that build things, where the loop’s product is not merged code but knowledge. For that reader there is one test that sorts the loops worth building from the ones that only look busy.

Most people building a knowledge loop build the accumulate version, because it is the obvious half. Loops write entries; you read them. It grows. It also gets slower to think with as it grows, because an append-only pile is just the swamp with extra steps. The compounding version requires two things the accumulate version skips.

First, the entries have to be structured enough to be read back as input — not prose, but claims and edges, so a future agent navigates the relationships instead of re-inferring them. That structure is the difference between a loop that runs and a loop that compounds; we made the full argument for it in The Index Is the Data¹¹, and Karpathy independently named the artefact the “LLM Wiki” — a persistent, interlinked set of markdown files where “the knowledge is compiled once and then kept current, not re-derived on every query.”¹² That wiki-graph is the durable external medium a compounding loop writes to. It is the third rung of the state-machine ladder, made into an asset.

Second — and this is the half almost everyone skips — the loop needs a consolidation step, not just an ingestion step. A loop that only writes is a knowledge graveyard. The fix is a second agent whose job is to subtract: combine redundant claims, fade stale ones, fold flat facts into edges, spin clusters into their own pages. We call it the Janitor, and it is reflection running on your corpus — the same mechanism that kept long-horizon agents coherent in the Generative Agents research, where removing the reflection step degraded them into repetition.¹¹ “The index didn’t just get smaller. It got smarter with every janitorial pass.”¹¹ If you build one loop for your wiki, build the consolidation loop, because the ingestion loop is the half that does not, by itself, compound.

The compounding test, then, comes down to a question about where your loop’s output goes. Does it land in a pile you read, or does it land in a structured, self-compacting map that the next loop consults as priors before it decides what to do? Theo’s better workflows already did the compounding version without naming it — his PR audit loaded priors and clusters from prior runs. The first kind of loop is a scheduled-sweep with a weak closer. The second is the machine you actually want: one that generates its own next questions and scores them against a documented North Star.

The honest caveat: extract the apparatus, not the theater

It would be easy to read Theo’s demos and conclude the lesson is scale — 55-agent tournaments, hundreds of dollars to pick between three PRs, “going hard” on subsidised inference. It is not. That intensity is a function of his temporary economics: he is optimising to burn subsidised tokens before they disappear, explicitly not for value-per-token. The 55-agent tournament to choose among three PRs is theater. For your context — your own hardware, your own budget, a wiki meant to compound over years — copying the intensity is copying the wrong variable.

The thing to extract is the architecture: dynamic, self-structuring, artifact-producing loops with durable external state and an adversarial closer. Theo’s PR audit was good not because it ran a tournament but because it had a verify phase — an adversarial checker per ruling that tried to refute it against the real repo. Strip that phase and the tournament is just expensive agreement. The structure — audit, rule, verify, with priors loaded from memory — works at a tenth the agent count. As we put it in The Cognition Dimension Ladder¹³: whoever spends the most tokens wins — provided they are spending inside an apparatus that knows what to reject. The load-bearing word is discipline, not burn. The token-maxing is the theater. The apparatus is the asset.

Run the field guide on a loop you operate today

This is a test you can apply in five minutes. Take one loop you already run.

1. Name its trigger. Manual, clock, event, or agent-initiated? (The cheap axis — answer it and move on.)
2. Name where its state lives. Your head, fixed code you wrote ahead of time, or a durable external medium? This is the axis that matters.
3. Kill it mid-run, in your imagination. If the agent died right now, does the state survive? If the answer is “no,” the loop is held together by attention, not architecture.
4. Find the thing that can say no. Is there an external check — a test, a separate evaluator, a red CI check, a revertible diff — or is the loop grading its own homework?
5. Apply the compounding test. Does this loop’s output land in a pile you read, or does it become a structured prior the next loop reads from? If it only accumulates, you have built the obvious half.

If you cannot answer 2 through 5, the loop is not yet an asset. It is an activity. The whole shift Steinberger named — from prompting agents to designing the loops that prompt them — only pays off when the loop’s state machine lives somewhere durable, something external can say no, and the output compounds into the substrate the next run reads. Get those right and you can leave the leash long, because the loop is holding itself. Get them wrong and no amount of autonomy, or agents, or tokens, will save you from a loop agreeing with itself on repeat.

Design the loop. But spend most of your design budget on the part the discourse keeps skipping: not what starts it, but who holds its state machine — and whether the spend leaves an asset behind.