Loop Engineering: The Playbook for Systems That Prompt Your Agents

1.What loop engineering actually is

The prompt-engineering courses are still selling, the ink on context engineering is not yet dry, and harness engineering has only just been written. The temptation to roll one’s eyes at another “X engineering” term is understandable. This one is different.

It is not about doing the work better. It is about pulling the practitioner out of the position of doing the work at all. The earlier terms all assumed a human seated at the keyboard, directing the agent line by line. Loop engineering deletes that assumption. As Osmani defines it: loop engineering is replacing oneself as the person who prompts the agent, and designing the system that does it instead. The practitioner is no longer inside the loop - they are outside it, building the loop.

2.The four-layer stack

The “X engineering” terms are not replacements for one another; they stack, each minding something larger. Prompt engineering minds one sentence. Context engineering minds the window. Harness engineering arms a single run - its tools, actions, recovery, and definition of “done.” Loop engineering sits one floor above the harness and makes it run itself, over and over.

Three verbs separate a harness from a loop. It runs on a timer (it wakes on schedule with no button-press). It spawns helpers (a turn can split off sub-agents). And it feeds itself - what the loop produces becomes its own input next round. That memory across runs is why a loop is a loop rather than a one-off task run many times.

The single most important intuition follows from this: the cost of a mistake scales with the number of turns it survives before someone catches it. A loop is, by construction, a machine for maximizing the number of turns. Everything in the sections below - the evaluator, the human checkpoint, the budget caps - exists to shorten the distance between a mistake and its discovery.

3.The five moves of one turn

The word “loop” is easy to misread as idle spinning. Each turn does something concrete: it finds work worth doing, hands it to an agent, verifies whether the result is right, saves state, then decides the next step. Drop any one of the five moves - discovery, handoff, verification, persistence, scheduling - and the loop will not turn, or will turn in place.

The fine-grained split matters because each move fails differently, and the check that can say “no” must be installed in a different place than the work itself.

4.Six parts a loop is built from

If moves describe what happens in a turn, parts describe what must be in hand for it to turn at all. Automations get the loop moving on their own, hung off a schedule or trigger. Worktrees are a built-in git mechanism for multiple independent working directories in one repo - they turn parallelism from “runs but messy” into “runs and clean.” Skills (a SKILL.md file) make project knowledge permanent so the agent need not re-derive context every turn - Osmani names the cost they pay off as intent debt. Connectors (built on MCP) hook the loop to the outside world. Sub-agents split the one that writes from the one that judges. And memory - persistent state on disk - lets the loop pick up tomorrow where it left off, because the agent forgets but the repo does not.

5.The evaluator that says “no”

The hardest part of a loop is not getting the agent to run - it is putting something inside that can say “no,” and the agent writing the code is the one least likely to say it. Ask an agent to grade what it just produced and it tends to praise it confidently, even when the quality is plainly mediocre. This is not a smarts problem; it is grading one’s own homework. The context in which the code was written is already stuffed with the reasons it was written that way, so when the agent looks at its output it does not see the result - it sees the chain of self-persuasion that led there.

Anthropic engineer Prithvi Rajasekaran found that making a standalone generator self-critical works poorly, while swapping in a separate, skeptical evaluator is far more tractable. The idea is borrowed from generative adversarial networks: one network builds, one picks faults - ported to a generator that writes and an evaluator that reviews. Crucially, the evaluator should not merely read the code; it should act on it - open the page with a Playwright MCP, click buttons, take screenshots, run the tests. That shifts judgment from “does this look right” to “does it run right.” A common calibration: tell the evaluator to assume the code is broken until proven otherwise - the default stance is doubt, not trust.

Claude Code turns this into a primitive with /goal: give an agent a condition and let it run until the condition is met, with a fresh small model checking after each turn whether it holds. Completion is decided by a different model than the one doing the work - the maker–checker principle, decades old in banking, applied to the stop condition. A loop’s floor is its evaluator: the generator’s level decides what a loop can produce; the evaluator’s level decides what it will not.

6.Five ways a loop goes wrong

The failures are more instructive than the successes and far more common. Each anti-pattern is one of the five moves skipped or done badly.

The nodding loop (verification skipped) is the most common: the agent writes code and the same agent declares it good, accumulating plausible-looking mistakes at machine speed. Its tell is a loop that has never said “no” to itself across hundreds of turns. The amnesiac loop (persistence skipped) forgets what it did because results lived only in a flushed context window; each morning it starts from the same place. The manual loop (scheduling skipped) is a script a human runs by hand and then forgets to run again. The blind loop (discovery skipped) is still hand-fed its work each morning, saving less than it appears to. The tangled loop (handoff skipped) lets parallel agents edit the same directory until the merge is a mess no one can untangle - fixed with one isolated worktree per task.

7.Loops that run while you sleep: real ones

Three public cases differ in scale but share one skeleton: a trigger presses start, a set of constraints keeps it on the rails, and a human checkpoint sits at the end. One engineer’s morning: Osmani’s triage loop runs automatically each morning - a skill reads yesterday’s failing CI, open issues, and recent commits, drafts fixes in isolated worktrees, has a second agent review them, opens PRs through a connector, and writes a state file so tomorrow picks up where today left off.

Stripe’s Minions, described by engineer Steve Kaliski, merge more than 1,300 machine-written pull requests a week. What makes it reliable is the stretch before the model wakes up: a deterministic orchestrator first assembles context - scanning links, pulling Jira, using Sourcegraph plus MCP to locate relevant code - because letting the LLM find its own context is the least controllable part. Anything whose rules can be hard-coded is taken out of the model’s hands. Reliability comes from the quality of the constraints, not the size of the model. Notably, those 1,300 PRs are still reviewed by humans - the human did not leave; they moved from writing to reviewing.

The third case is the boring but decisive one - where the loop runs. Local scheduling buys frequency and access to local files at the cost of keeping the machine on; cloud scheduling buys true autonomy at the cost of a coarser interval and a clean clone. Conflating “a few extra rounds while I’m here” with “runs even when I’m not” is how people end up disappointed when they close the lid and the loop they thought was autonomous quietly stops.

A caution on widely circulated numbers: claims such as “around 90% of Claude Code is written by itself” are mostly second-hand summaries and should be treated as rough reference. The three cases here trace to first-hand sources, which hold up better than one impressive-sounding figure.

8.The four silent costs

A loop that runs itself is, at the same time, a loop that makes mistakes by itself - the more cheerfully it runs, the more quietly it errs. Four costs accrue, none of which sounds an alarm while the loop is running.

Verification debt is unverified output piling up in the gap between “runs” and “right,” until some shipping morning it blows up at once. Comprehension rot is the growing gap between what exists and what you actually understand, because reading code is more boring than writing it and the loop has taken the writing. Cognitive surrender is the attitude version of the first two - not “no time” but “no longer want to bother” forming an opinion. Token blowout is the only cost that hits the bill directly: an idle bug can spin all night and run round after round. The guard for the last is hard caps set before shipping - a per-run budget, a daily budget, a max-retry count - circuit breakers that convert an open-ended risk into a bounded one.

9.The economics of judgment

When a resource becomes abundant, its price falls and the work reorganizes around what stays scarce. Loops make code, plans, fixes, and pull requests nearly free. What stays scarce is judgment: knowing which plan is right, which line should be stopped, which output only looks fine. A loop can generate a hundred candidate implementations; it cannot tell you which one is right. As generation approaches free, the entire value of the engineer concentrates into that gap.

This cuts both ways. Because the loop is an amplifier of judgment, a lapse in judgment is also amplified - a bad decision is now executed faithfully, in bulk, a hundred times, by a machine that will not pause to ask whether it is right. As Osmani puts it, the same loop built by two people can end in opposite places: one uses it to move faster on things already mastered; the other uses it so they never have to understand again. Six months later, one has grown stronger and the other has become the gatekeeper of a machine they cannot read. The loop is a faithful multiplication sign - it multiplies the person.

10.Build your first loop today

Stripe’s pipeline is the endpoint, not the starting point. A first loop should be so small it barely looks like a system - a little thing that checks something on a timer. The safe order of growth is to add the checks first and parallelism last.

In Claude Code the primitives are /loop (rerun a task on an interval), /goal (run until a condition is met, judged by a fresh model), --worktree (an isolated directory per background agent), a SKILL.md for discovery, and a committed state file for memory. The same capabilities exist under different names in other toolchains - the lesson is that loop engineering is a set of capabilities, not a product.

Beginners most often ship with only the first two elements built - scheduling and a single run - and the result is a loop nobody watches and nobody can stop, nodding at itself. A first loop is better small, but only with the “no”-saying check and the human review point fully installed.

11.Where PromptFloe fits

PromptFloe is a loop, by this definition, pointed at one job: turning a description into a working full-stack application. Generation is the cheap part; the value is in the moves around it. Every build runs through automated gates - it must compile, boot, migrate, and pass tests - and what fails is repaired inside a bounded cycle, then signed with a verification certificate. That gate is the evaluator that says “no,” sitting between “runs” and “right.” The repair budget is the token cap that keeps an idle bug from spinning all night. And project memory persists across iterations, so the loop picks up context instead of re-deriving it.

The reason we put verification at the center is exactly the one this playbook lands on: a generator that grades its own homework praises it. The loop, not the model, is what makes AI-built software trustworthy - and the engineer who stays able to say “no” is the one it keeps working for.

12.Glossary

This article is an independent synthesis of the open guide “Loop Engineering: Stop Asking Me What It Is” (HuaShu, Orange Books, June 2026). The framework and formulations are due to Addy Osmani; the generator/evaluator findings to Prithvi Rajasekaran (Anthropic); and the enterprise case to Steve Kaliski (Stripe). Product details may change; refer to each tool’s official documentation.