Loop engineering

For roughly two years, getting work out of a coding agent meant typing. You wrote a prompt, read what came back, and typed the next one. The agent was a tool and you held it continuously, one turn at a time.

Loop engineering is the proposal that this part is over. Instead of prompting the agent, you build a system that prompts it: something that finds the work, starts a run, checks the result, records what happened, and decides what to do next, on a schedule or in response to an event, without you in the seat for each turn.

The term appeared in June 2026 and spread quickly. Addy Osmani, who did most to popularise it, attributes the framing to two practitioners. Peter Steinberger: “You should not be prompting coding agents anymore. You should be designing loops that prompt your agents.” And Boris Cherny, who leads Claude Code at Anthropic: “I do not prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

This page describes what a loop contains, and then reports what happened when someone measured whether any of it is actually being done. Those two halves do not agree with each other, and the disagreement is the most useful thing here.

Where it sits relative to the harness

The two terms arrived within months of each other and are easy to conflate. Osmani draws the line cleanly: harness engineering builds the environment a single agent runs inside, and “loop engineering sits one floor above the harness.”

The distinction is worth keeping because the layers answer different questions.

An agent harness has an internal loop already: call the model, run the tool, feed the result back. That is plumbing inside one execution. Loop engineering is the outer layer that decides a run should happen at all, at three in the morning, because a test started failing, and that it should keep happening until some condition is met.

What a well-engineered loop is said to contain

Reviewing the practitioner literature, the arXiv study found the discourse largely agrees on five components:

• Triggered agent runs bounded by machine-checkable stop conditions. A schedule or a repository event starts the run, and something a machine can evaluate ends it.
• Persistent state files. A record outside any single conversation of what is done and what is next, so a run can pick up from where the last one stopped.
• Verifier sub-agents. A separate agent checking the work, not the one that produced it.
• Token budgets. An explicit ceiling, because nobody is watching.
• Defined points of escalation to humans. A named condition on which the loop stops and asks.

Tool-level accounts list more concrete primitives. Osmani names automations, worktrees so parallel agents do not collide, skills to record project knowledge the agent would otherwise guess, plugins and connectors, and sub-agents so that “one of them has the idea and a different one checks it” - plus, separately, memory: a file or a board holding what is done and what is next. IBM’s account adds hooks and context engineering.

The two framings are describing the same thing at different altitudes. The research list is the set of properties a loop needs; the tool list is the set of features vendors now ship. Notice which items appear only in the research list: token budgets and human escalation. They are the two that constrain what happens when the loop is wrong, and they are not features you get by adopting a product.

Underneath, every account describes the same cycle: a goal evaluated on each iteration, an action, an observation of the result, an adjustment, and a check of whether the stopping criterion is met.

What the first measurement found

Here the story turns, and this section is the reason to be careful.

A 2026 mining study examined 36,710 open-source repositories for evidence of the practice. Its detection was deterministic, driven by a published rule catalogue and no model at all, with every result file recording the catalogue’s hash. Of 256 repositories that matched its heuristics and were manually inspected, 217 were confirmed to be running autonomous agent loops, which is 0.59% of the scanned corpus. So the practice is real, and it is running.

What those repositories contain is the finding:

Across all 36,645 repositories, the scan found only two state files meeting the state rule’s content criterion, one skill marked as part of a loop, no stop condition, no budget file, no verifier subagent referenced by a loop artifact, and no cost log with measured values.

Both of the two state files were then rejected on inspection as unrelated uses of the word “loop”. The single skill detection was genuine, but no loop in that repository runs it.

Put beside the five prescribed components, the tally is stark. Of the five, four are essentially absent from the public record: persistent state, stop conditions, budgets, and verifier sub-agents. What repositories do commit is the trigger configuration, almost always a GitHub Actions workflow. The authors summarise it as the repositories committing the configuration around these loops while the runtime state stays outside version control.

What that does and does not prove

The honest reading requires the study’s own limitations, which it states plainly.

Worktrees and runtime state are invisible to this method by construction. A loop can maintain excellent state in a file that is deliberately not committed, and repository mining will never see it. Some of the absence is a measurement boundary, not a gap in practice.

The corpus predates the term. The dataset is a March 2026 snapshot and the discourse began in June 2026. The authors mitigated this by scanning each repository at its current head and dating each artefact by its introducing commit, but the sample was not assembled to find this phenomenon.

It is open source only. Commercial and internal usage is invisible.

It is exploratory, and says so. The controlled study of agent autonomy and its effect on effort and outcomes is described as planned, not performed. There is no false-positive rate, because establishing one would have required a set of repositories known not to run loops, and no such set exists, so every match was inspected by hand instead.

What survives all of that is still substantial. Whatever teams are doing privately, the practice as publicly documented is trigger configuration. The parts that bound cost and risk are not visible anywhere in the corpus.

The evidence for the value claims does not exist yet

This is the finding to carry away, and the paper states it directly:

Systematic evidence on the value claims is missing. The discourse offers a stable design vocabulary and diverging assessments of value, but systematic evidence for either side is missing.

Both directions. There is no good published evidence that loop engineering delivers what is claimed, and none that it fails to. What exists is a shared vocabulary and strongly held opinions.

Osmani, who named the practice, is explicit about his own position: “I believe this may be the future of how we work with coding agents. However, it is still early; I am skeptical, and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor).”

That is the person most associated with the term, hedging in the same paragraph that introduces it. Anyone selling you certainty about this is ahead of both the evidence and the advocates.

If you build one anyway

Building on a vocabulary rather than on evidence is a legitimate engineering decision, provided it is made knowingly. Two things follow from the material above.

Implement the components that are missing from real repositories first, precisely because they are the ones being skipped. A stop condition, a budget and an escalation point are what stand between an unattended loop and an unattended bill. The trigger is the easy part and is the part everybody already has.

Make the verifier something other than the generator. The harness page sets out the evidence in detail: models are poor at locating errors in their own output, and a loop whose check is the generating model marks its own work on every iteration. Since the loop runs unattended, that failure compounds silently.

Then measure it, which is the thing nobody has published. A loop is an evaluation problem before it is an architecture one: without a baseline you cannot distinguish a loop that is working from one that is generating activity.

What this page does not claim

It does not tell you that loop engineering works, because that is not currently known. It does not tell you it does not work either.

It also does not recommend a tool. The vendor primitives are converging fast enough that specific comparisons date within months, and the study of eleven harnesses found the field running on hand-rolled loops instead of shared frameworks, which suggests the abstraction has not settled.

What can be said with confidence: the vocabulary is stable and useful, the practice is real but rare in public code, the components that bound risk are the ones most often missing, and the outcome evidence is not in yet.