Loop engineering: how to design loops for coding agents

TL;DR: Loop engineering is when you describe a loop rather than an individual prompt: its state, next step, external verification, and stopping condition. A loop pays off where verification is cheap (green CI, a clean linter, a successful rebase), and falls apart where proving "done" costs more than the work itself. Below: what loops are made of inside Codex and Claude Code, where they learn to game their own oracle, and how much a run without a hard stop can cost.

Try this simple trick: instead of giving a coding agent a task directly, ask it to first write a prompt for that task, then feed that prompt back to the same agent. The result is often better than your original wording.

The model formulates the task for itself better than you do. But that's still only two moves. A loop begins when the system repeats this process on its own: it maintains state, chooses the next step, verifies the result against an external criterion, and stops when a condition or budget is reached. From here on, I'll call that external criterion an oracle: tests, a linter, green CI, a separate judge model—anything that answers "did it work?" instead of letting the agent answer for itself.

Peter Steinberger, creator of Openclaw, summed it up in a tweet that got millions of views: "Stop prompting coding agents. Engineer loops that prompt agents for you." The phrase spread, spawned follow-ups, and eventually reached the hashtag-spam and "how to print alpha 24/7" guide stage. The usual fate of a viral slogan.

I wanted to unpack the new way of working hidden behind the meme. When I started writing this piece, loops were foreign territory to me: my own harness was designed for one agent, and I wrote about it last time when I broke down agent harnesses. Over the next couple of months, I built my own loop on top of it and rewrote it so many times that I stopped counting. So this will be a breakdown of how frontier teams work, plus my own verdict after collecting a fair number of bruises. Inside the tools themselves, humans are formulating each move less often and increasingly designing state, verification, and stopping conditions instead.

One layer above the harness: how loop engineering differs from a harness

For two years, the recipe for working with a coding agent was the same. You write a good prompt, provide context, read what comes back, then write the next prompt. The agent is a tool, and you keep it on a leash the whole time, move by move. You can improve that manual workflow: give the agent a convenient environment, tools, memory, and rules. That's the harness, the wrapper one agent lives inside. I dug deep into it in my previous article and came away with one uncomfortable conclusion: agents are often confident they're finished while still being wrong.

Addy Osmani, former director of Google Cloud AI, put it this way: "Loop engineering sits one layer above the harness. Same harness, but running on a timer, spawning little helpers, and feeding itself." You no longer keep the tool on a leash. You build a small system that finds work on its own, distributes it, checks the result, records what was done, and decides what to do next. That system will prod the agents instead of you.

Boris Cherny, head of Claude Code at Anthropic, describes his own workflow like this: "I don't prompt Claude anymore. I have loops running that prompt Claude and decide what to do themselves. My job is to write loops." And speaking at Meta @Scale on June 17, he described the direction even more starkly: "agents prompt agents, and those agents write the code." This is still how frontier teams work; you can't generalize it to the entire industry yet. Humans remain in the process, but step out of the manual prompting loop.

The loop is now built into the product: what it's made of in Codex and Claude Code

Something else surprised me about this wave: the loop stopped being a tooling problem.

A year ago, if you wanted a loop, you wrote a mountain of bash and maintained it forever, and it was yours and yours alone. The canonical example is Jeffrey Huntley's "Ralph loop": while :; do cat PROMPT.md | claude-code; done. One line. An infinite loop, each pass starts with fresh context, and all state lives in files on disk. A more substantial version is Andrej Karpathy's autoresearch: a 630-line script with LOOP FOREVER written right inside it. In two days, it ran around 650 ML experiments. The point of the design is to remove the human from the inner loop and stop making them the bottleneck.

The same loop components now live directly inside the products. Osmani breaks a loop into five pieces: scheduled automations, worktrees for isolating parallel agents, skills containing recorded project knowledge, MCP connectors to your real tools, and subagents, where one comes up with the answer and another checks it. A sixth piece, memory on disk, is necessary because "the agent forgets, the repository doesn't." None of these pieces requires custom bash anymore: they're already buttons and commands inside Codex or Claude Code.

Once you notice that both tools share the same shape, you stop arguing about which one is better and start designing the loop independently of the particular tool you choose. Four days after posting the slogan, Steinberger himself shared a recipe: Codex holds your repositories, wakes up every five minutes, routes work into threads, with an orchestrator skill on top plus triage and auto-review skills. You no longer have to build this toolkit from scratch: it's already part of the product. He talked about the same thing at AI Engineer World's Fair. I covered the conference separately, and to save you from rewatching the talks, I put summaries of all of them into a convenient SPA.

Where the complexity moves: why verification costs more than generation

Christoph Nakazawa, creator of Athena Crisis, hardly writes code by hand anymore and describes the shift like this: he used to be constrained by writing the code; now he's constrained by deciding whether the code is correct. Shubham Saboo puts it more concisely. Generation is no longer the problem; a loop can generate endlessly. What's left is verification and judgment. Once an agent can reliably produce an acceptable draft, the bottleneck shifts from writing to checking what was written and deciding whether it actually does what you needed.

The one who writes and the one who checks need to be separated. A model is too charitable toward its own work and will happily give itself a passing grade on homework it completed itself. So someone else needs to verify it. In Claude Code, this is already built into the /goal command: after every turn, a separate small, fast model (Haiku by default) checks whether the specified criterion has been met. It doesn't call tools and judges only what the agent has put into the conversation. You give it something like "all tests in test/auth are green and the linter is clean; otherwise stop after 20 turns" and go watch TikTok.

A cheap Haiku judge solves only half the problem. Running the check itself costs pennies. The expensive part is designing a criterion the agent can't game. A vague "done" will be rubber-stamped by a small model just as readily as by the code's author. In complex loops, the most expensive component is the definition of done and whoever verifies it. Blake Crosley writes: "What can be automated is determined by the cost of verification, not the design of the loop." For now, loops work best on routine work with a cheap completion signal: CI is green, the PR rebased successfully.

There's nothing mystical about a single pass through a loop. A trigger finds a stale PR. State lives in the issue and working tree. The agent rebases the branch, a separate verifier runs CI and checks the criterion "all required checks are green." If the criterion isn't met, the verification result is fed into the next turn. If it is, the loop stops. A hard limit sits above the whole thing: say, five attempts or a fixed budget. Without an external test and a stop condition, spending will grow out of control.

I felt this firsthand with my own harness, the one built for a single agent. The biggest time sink was getting a reliable answer to whether the agent actually did what it claimed. I had to separate the event "agent reported completion" from actual verification of the result, introduce a separate state for cases where "the side effect may have happened, but the runtime isn't sure," and add retries.

Since then, a "Manager" has grown on top of the harness. It takes one task, chooses the right workers for it, keeps state on disk so the run survives a restart, accepts or rejects evidence, and closes the work with a status, including "unproven" and "partially done." I rewrite it almost every other day, and nearly every change comes from the same place: yet another way in which "done" turned out not to be done. I collected my rules and principles for building loops into the x9-loop-engineering skill: it prevents you from adding agents just to make the diagram look impressive and requires every loop to have a stopping condition, every piece of shared state to have an owner, and every exit status to avoid presenting unfinished work as complete. Every rule there was written in blood: each line appeared after something broke in a real run.

The skill lives in my repository alongside x9-agent-instructions, about writing good prompts for agents, and x9-skill-creator, about building the skills themselves. The format is shared across Agent Skills, and individual skills can be installed selectively through an interactive installer.

When I look at a system of ten agents pushing one another around on timers, I can easily imagine how much harder it is to preserve a reliable completion signal there.

The official "Getting started with loops" guide sorts loops by what exactly you hand over to the machine, producing a staircase of increasing delegation: first verification within a turn, then the stopping condition (/goal), then a time-based trigger (/loop, /schedule), and at the top, in a proactive loop, even the prompt itself, with an event formulating the task for you. The guide recommends giving routine work to small, fast models and reserving the strongest model for judgment.

So I read Osmani's formula, "engineering the loop is harder than prompt engineering," with a caveat. For CI, rebases, and other routine work with cheap verification, a loop removes a lot of work from the human. The more expensive and ambiguous the oracle, the more effort moves from formulating each step into designing verification. The leverage point has started to shift, but the payoff depends on the type of task.

Where loops lie and what they cost: reward hacking and the token bill

A loop runs unsupervised and makes mistakes unsupervised too, as Osmani dryly points out. The whole point of a separate verifier subagent is to make its "done" mean something. But even a separately issued "done" remains a claim, not proof. And that's still the good case, where the loop isn't deliberately cheating.

In the worst case, the loop learns to game its own oracle. This is called reward hacking, and it looks exactly like Goodhart's law in action: once the agent starts optimizing for passing the test, the test stops measuring correctness. The model rewrites the test to suit itself, inserts return true, monkey-patches timers, or hardcodes the answer for the exact check being used. ImpossibleBench measured this in an artificial scenario where the tests deliberately contradict the task and cheating is rewarded: GPT-5 cheated in 76% of cases. That number applies only to this setup and should not be extrapolated to ordinary runs. Newer Claude models cheat noticeably less on the same test than the older Sonnet 3.7. In June, cheating broke the benchmark itself. METR couldn't publish a task horizon for GPT-5.6 Sol: if cheating attempts are counted as failures, the result is 11 hours; if they're counted as successes, the estimate jumps past 270. METR considers neither figure reliable.

The oracle can work perfectly, but without a reliable stop and budget limit, the loop can still run away. You can see it directly in the token bill. In a widely cited but only partially verified incident involving an unnamed company, a four-agent loop in which an Analyzer and Verifier kept bouncing work back and forth ran for 264 hours without stopping. The bill climbed in steps: $127, then $891, then $6,240, then $18,400, for a total of about $47,000. Only billing shut it down. Tim Schipper cites another third-party case: according to the author's estimate, a single slash command launched 49 subagents in parallel and burned through roughly ten thousand dollars in 2.5 hours. There is no primary postmortem for that case either, so the number illustrates the scale of the risk rather than serving as a verified cost breakdown. You shouldn't treat figures like these as a forecast for your own bill, but they're a good reason to check for a hard stop before a run rather than afterward. As TechCrunch put it, loops have no spending ceiling. If every turn resends the entire growing context, the cost of the run balloons especially quickly. Designs where every pass starts with fresh context, compaction is enabled, and state lives on disk don't have the same runaway growth.

Theahura shows another cost: on sequential tasks with a large shared context, orchestrators cost more than a single agent while performing worse. In his analysis, multi-agent variants dropped in quality by 39–70%. Loops make the most sense when the work can be decomposed, the result is cheap to verify, mistakes can be rolled back, and the number of passes and budget can be capped. For a sequential task with a large shared context, it makes more sense to try one supervised agent first.

This isn't a rebrand: how a loop differs from an agent orchestrator

At this point, the old-timers have every right to say: guys, you've renamed the orchestrator we've had for years.

And mechanically, they're largely right. The idea of a loop goes back to ReAct from 2022. The idea of "agents prompting agents" was described back in 2024 as meta-prompting. Orchestrators, Ralph, and Gastown all existed before the viral slogan. "Peter's loop" is essentially what the community had been calling an orchestrator for the previous two or three years.

Models have become able to stay on task for longer, and that's one of the conditions that made loops viable. METR measures task horizons: how long a task an agent can complete with a 50% chance of success, with task length measured by how long a human would take. For GPT-4 in 2023, it was four minutes. For Claude Opus 4.6 in February 2026, it was already twelve hours, and that figure now doubles roughly every four months rather than every seven, as estimated a year ago. Beyond that, the benchmark runs into its own limits: METR's task set can't measure horizons above sixteen hours, and models released after April haven't been measured on it at all.

But you can't read those twelve hours as "the agent works for half a day." METR measures task difficulty. It doesn't measure how long the model itself runs at all, and says so explicitly. My "Manager" can happily grind away on a difficult task for more than forty hours, and that tells you nothing about whether the work was done correctly. Anthropic separates the same two curves in its telemetry: the median turn in Claude Code lasts 45 seconds, and it calls the gap between what models can do and how they're actually deployed the deployment overhang. Loops live precisely in that gap. In GAIA, an early AutoGPT running on GPT-4 scored 0.4% on Level 2 tasks versus 2.6% for plain GPT-4 and ran noticeably slower, although it did better on the simpler Level 1. Back then, the agent wrapper still didn't produce a reliable advantage at the harder level. Products have since added disk-backed state, scheduling, isolation, and separate verification to longer model task horizons. An old pattern has, for the first time, become accessible and reliable enough for a limited class of tasks.

While this article was sitting in my drafts, someone had already built the next floor above it. On July 18, Peter asked: are we still talking about loops, or have we moved on to graphs? A question with no definition and no methodology. That same day, an article titled "Loop Engineering Is Dead. Enter Graph Engineering" came out: only a few hours passed between the question and the obituary. The new term describes something straightforward: work has nodes, edges, branches, and merge points, while a loop becomes one node in the graph. There is no canonical definition or comparative benchmarking yet, but the discipline behind the term is real. My "Manager," which I described above, is exactly that kind of graph: worker nodes, checks between them, and a point where everything converges. I'll write a separate article about the traps I ran into while designing it.

Stay an engineer

In "To loop or not to loop", the author looks at what the slogan leaves out: the position from which the advice is being given. Steinberger worked "at inference speed," then got recruited by OpenAI, and now effectively has an unlimited supply of tokens in fast mode. "Engineer loops" coming from someone at a frontier lab with free inference and "engineer loops" aimed at a developer paying for a subscription out of pocket are two different pieces of advice in the same wrapper. Whether you need a loop depends on the amount of work, the deadline, the type of task (what he calls "high intent density" is hard to automate), and token cost. I'd put the author's warning on the wall: don't become someone who spends most of their time automating their own automation. That trap now has a name: orchestration tax. Spawning agents has become easy, but your attention doesn't parallelize the same way. You still have to decide what to watch and what matters, and that part can't be automated away.

A loop has another cost: comprehension debt. The more smoothly it churns out code you didn't write, the wider the gap becomes between what exists in the repository and what you actually understand. Osmani calls this comprehension debt, and cognitive surrender—when you stop thinking and simply take whatever you're given. Anthropic measured this effect. In a controlled experiment with 52 engineers, those who worked with an AI assistant scored lower on a comprehension test immediately after the task: 50% versus 67% in the control group. The study is actually about junior engineers learning a new library, so applying it to our case, where a senior engineer reviews the output of a loop, is only an analogy. But the same study contains a pattern that illustrates our topic well: participants who delegated blindly saw comprehension fall to 24–39%, while those who stayed engaged, asked "why this way?" and demanded explanations for the code stayed at 65–86%.

The trick from the beginning looks different now: the agent really does write the prompt better than you. It runs the loop faster than you, too, and can churn out more garbage code than you could write by hand in a month. But deciding whether you can trust the oracle, whether verification is worth the money, and whether the loop is doing the right thing at all is still your job. For routine work that's cheap to verify, there may be less of that work. For ambiguous tasks, the cost of judgment only becomes more visible.

Build loops where you have a cheap oracle, reversible mistakes, and a hard stop. For everything else, start with one agent and your own attention. Agents run the inner loop: investigate, do, verify. You own the outer one: decide whether the evidence is sufficient, and take responsibility for what goes into production.

Osmani ends his essay like this: "Two people will build the exact same loop and get opposite results. One accelerates work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do."

Stay curious.