Loop Engineering: Design the Loop, and AI Finishes the Work

You ask an AI to match last month’s payments against your invoices and flag anything that doesn’t add up. What comes back is genuinely useful — and not quite done: two mismatches it didn’t notice, a line marked resolved that isn’t. So you point those out. It fixes them and turns up a third. A few rounds in, the division of labor is clear. The AI does the work inside each turn; you do everything between turns — check the result, judge it, decide what happens next, start it again. However good the model gets, the work still routes through you.

“Loop engineering” is the current name for the move that takes you out of that seat: instead of handing the AI one instruction at a time, you give it a job, a rhythm, and a definition of done, and let the going-around-again happen without your finger on the button. This piece is that idea made usable: six questions that design a loop and make it safe to leave running, and real loops held against them. The tools will keep changing names; the questions won’t.

The phrase came together on the coding-agent frontier over about a week this past June. On June 2, Boris Cherny — who built Claude Code, Anthropic’s coding agent — told an audience he doesn’t prompt Claude anymore: “My job is to write loops.” Five days later, Peter Steinberger — who had closed 2025 declaring he could “ship code now at a speed that seems unreal” — put it bluntly: stop prompting your coding agents, start designing loops that prompt them. The next day, Addy Osmani worked the practice out in detail in an essay titled “Loop Engineering,” and Anthropic later published its own guide to designing loops.

The idea underneath the buzzword is much older. I studied control engineering decades ago, and the words were already old then — open loop, closed loop, feedback, overshoot. A thermostat runs a loop: read the temperature, compare it to the target, act, wait, read again. The invoice reminder that goes out every few days until the payment lands is a loop too. What changed is the thing inside the loop. A thermostat knows one number; an AI in the same seat can read a hundred messy messages, weigh which ones matter, act, and notice when one is delicate enough to hand back to you.

That’s also why the discipline travels beyond the code it was named in. Coding agents got there first because code hands back unusually honest feedback — a test passes or it fails, a build breaks or it doesn’t — but the same shape holds for any work that leaves something checkable behind: the books tie out or they don’t, every claim in a brief has a source or it doesn’t. Loop engineering is loop discipline arriving in AI work — a session that used to end wherever the model stopped, with you as the only check, can now run closed.

Three questions design a loop

In my Ralph Wiggum loop piece I read every loop through two dimensions: who curates the context the agent sees, and who decides when an iteration ends. Loop engineering is what happens when the loop starts waking up without you — which puts a third question in front of those two. Together they are the design half of the framework this piece runs on.

Start — what starts it? Three kinds of things do: a person, a clock, or a system — a new support ticket, an email landing in a monitored inbox, one service pinging another (a webhook). Look underneath any product’s trigger menu and it resolves to one of those; a clock tick is just an event that arrives on schedule, and even your own prompt is an event.

See — what does it see? An agent acts on exactly what enters its context: the files, the records, the report you point it at — and each pass around the loop, someone decides what carries forward. That someone is either you, curating fresh input every round, or the agent, dragging its accumulated history along. This is the context-control dimension from the Ralph piece, and it matters more once nobody is watching: a loop that sees the wrong slice of the world will confidently work on the wrong problem.

Stop — what stops it? The worker model itself, a separate evaluator, a script, or you. “Stop” is really four moves — keep going, stop, retry, or hand it back to a human — and every one of them is a response to a measurement: did the lines reconcile, or not? Did the page get indexed, or not? That measurement is the feedback — in AI terms, your eval — and I’ll call it the done-check. A loop with a weak, delayed, or missing done-check is a machine repeating an action with no reliable sense of whether it’s helping. Most of what goes wrong in a loop goes wrong here.

Those three questions are also where the products plug in — Claude Code and Codex, the agent tools from Anthropic and OpenAI, both ship named features answering Start and Stop, and they differ on exactly the detail you’d want to check before trusting either. That mapping gets its own section near the end, so the questions can finish first; the tools will still be there.

Three more make it safe to leave running

Start, See, Stop tell you whether you have a loop. Whether you can walk away from it is three more questions — the leash.

Scope — what’s in scope? What the loop may touch, and what it must never do on its own. A reconciliation loop may match lines and write an exceptions list; it may not move money. A support loop may draft replies; it may not send them. Scope is where the fear under all of this — an AI acting unattended — gets answered concretely, boundary by boundary, instead of with reassurance.

Show — what does it show? This is See’s mirror: See is what the loop takes in, Show is the evidence that comes back out to you. A loop you’re not watching has to show its work, in both tenses: while it runs — progress you can glance at, evidence surfaced as it goes — and after it stops, in the record it saves: what it did, what it fixed, what it couldn’t and why. And word of it has to land where you already look — pushed into your inbox or your chat, not parked somewhere you’d have to remember to check. This is the question that catches the failure I’d worry about most — quieter than any runaway robot: the loop that decides it’s done, exits clean, and hands back something confidently wrong. The books “reconcile” because it forced a line; the brief is “sourced” because it made a citation up. A loop like that was never really a loop — it’s a prompt wearing an autonomy costume, and the tell is that nothing inside it ever had to show real evidence to anyone.

One design makes the pair of Stop and Show concrete. The job: turn a stack of sources and a question into a decision brief. You can’t loop until “the brief is good” — quality is a judgment no script can certify — but you can loop until every claim in the brief resolves to a real line in a cited source, because a script can check that. So the loop keeps a ledger tying every claim to its source, and a validator script — not the model’s opinion — has to pass before “done” can be recorded. The finished run hands back a receipt reading Status: PASS — and a second check that deliberately falsifies the status confirms the loop can’t lie its way to done. That’s the maker/checker split Osmani draws, pushed onto the stop condition itself — whatever decides the loop is done is never the thing that did the work — and even then, “done” is a claim, not proof.

Spend — what can it spend? Loops burn tokens — the units AI usage is metered in — until they stop, and a thin done-check burns the most, because nothing tells the loop its effort isn’t landing. Give a loop a budget the way you’d give a new hire one: a cap on rounds, a cheap model for the mechanical passes and a stronger one only for the judgment calls, and a frequency no higher than the work actually changes.

Filling in the card: the indexing loop

Here’s a job every site owner will recognize. Google Search Console periodically emails you that some pages on your site have indexing problems — crawled but not indexed, or something stopping them from showing up in search. Every site accumulates a few of these; the email is part of running one. And the routine is the same every time: open the report, find the affected pages, work out the cause, fix it, ask Google to re-check, wait for the next email. You do the judging; the steps in between barely need you. That’s the shape this whole piece is about — a job where you’re the loop. So here it is, held against all six questions:

Filling in that card is the design work — a card you can’t complete is the earliest sign you’re about to schedule a hopeful prompt. Notice what the card quietly decides: the loop’s Stop includes a hand-back path (some indexing problems are content decisions no loop should make), and its Scope keeps it off every page Google didn’t flag.

A loop that runs while you sleep

The indexing loop wakes on an event. The other big class wakes on a clock — and the job from the top of this piece, month-end reconciliation, is built for it, because its “done” is a number you can count. Put it on a monthly schedule — every agent product has a way to do that, mapped near the end of this piece — and the entire job description fits in one paragraph. It’s the same six answers a card would hold, written out as instructions — the basic version:

Match last month's incoming payments against the invoices I issued. For every
line that doesn't reconcile, find out why — a payment with no matching invoice,
an invoice marked paid with no payment, an amount that's off, a duplicate. Fix
the ones that are unambiguous (a known fee, a rounding difference, a duplicate)
and record what you did — a fix here means matching and noting; never move money,
never change an amount. For anything you can't resolve with confidence, leave it
on an exceptions list with the evidence. Keep going until every line is either
reconciled or on the exceptions list, and stop after three full passes even if
some lines are still open. Then email me the report: what you fixed, what's on
the exceptions list and why, and the final counts.

Read it against the framework and every question has an answer in plain sight: the clock is its Start, last month’s payments and invoices its See; it runs until every line is reconciled or excepted, and quits after three passes (Stop, and there’s Spend); a fix may match and note but never move money (Scope); and the report it emails you is the deliverable itself (Show). Compare that with a scheduled report that emails you a tidy summary with nothing checking whether anything got resolved: same trigger, none of the discipline. A scheduled prompt is not a loop; it just shows up on time.

A production version of this loop grows along two lines, and neither is a longer prompt. It gets connected: instead of working from an export, it reads the ledger through your accounting system’s own interface — QuickBooks, Xero, whatever runs your back office — writes back the matches and notes its scope allows, and sends the exceptions list to whoever acts on it, your accountant more often than you. And it gets enforced: the three-pass cap counted by the software running the loop instead of the model’s honor, a validator that isn’t the model’s opinion checking the counts, a receipt saved per run. If a job can’t answer the six questions in a paragraph, elaboration won’t save it; if it can, everything you add — connection or enforcement — is rope, paid out as the loop earns it.

A habit that saves grief: before you put any loop on a schedule, run it by hand at least once, on real data. The first manual run is where the weak spots surface — an ambiguous success condition, a check the agent can game, a missing input, a decision that keeps coming back to you. A clock only makes the current behavior recur more reliably, so fix the loop first and schedule it second.

Where you stand: in the loop, or on it

None of this removes you from the work; it moves you. In the Ralph piece I drew the line between the human in the loop — approving every single iteration — and the human on the loop — setting it up, curating what it sees, watching what it shows, stepping in on the cycles that matter. Loop engineering is mostly the move from in to on.

Customer support makes the move concrete, and it wakes on an event — a new ticket. Split the job by what you can check. The triage half is verifiable: every open ticket categorized and routed, nothing waiting past its first-response deadline. A loop can own that. The reply itself is not verifiable — “is this correct and on-brand” is a judgment — and it’s outward-facing: a wrong autonomous send lands in a real customer’s inbox with your name on it. So the design follows the split: the loop triages and drafts, a second agent checks each draft against your policy, the confident low-stakes ones go to a “ready to send” queue, and anything sensitive — a refund, an angry customer, a legal word — is escalated with the draft attached. I’d keep the send gate for a good while; the loop earns rope. None of that is unique to loops — it’s how you’d treat any AI touching customers — but a loop repeats whatever it does, unattended, which is why a soft signal on an outward-facing action is exactly where a human stays on.

Does the work deserve a loop?

One question remains, and it’s the easiest to skip. Not “can I get an AI to do this?” — you almost always can — but whether the work deserves a loop. “A job you do over and over” is only half the answer. Some work recurs — the reconciliation every month, the support queue all day, Google’s emails whenever they arrive — and the loop is the standing operation that keeps handling it. Other work happens once but can’t be nailed in a single pass — driving the books to zero, or the developer’s version, driving a failing test suite back to green — and the loop is the iterate-check-retry it takes to get there. Reconciliation is quietly both: it recurs monthly, and each run converges to zero. So the test I’d apply: does getting it right take more than one pass — because the work comes back, or because reaching “done” takes iteration — and is there a done-check honest enough to answer Stop? Add that it’s valuable enough to be worth the trouble and reviewable enough that you’d trust what it shows, and you’ve got a job that deserves the design.

Plenty of tasks fail that test, and that’s fine — a one-off prompt in a single session is the right tool surprisingly often, and there’s no shame in a quick question that finishes in one pass. And some jobs simply don’t loop: you can’t “loop until we build a full permissioning system,” because there’s no verifiable target and no telling which way the model will run.

Where the products fit today

Back at the design questions, Start and Stop pointed here. Two products anchor the map — Claude Code from Anthropic and Codex from OpenAI, the agent tools whose loop features are documented well enough to check — but read the rows as a template: whatever tool you use, these are the four capabilities to look for. As of this writing, mid-2026, the names line up like this:

They’re roughly at parity, with one difference to check before you lean on either: who answers Stop. When you give Claude Code a /goal, after every turn it hands your condition and the transcript to a separate small fast model (Haiku by default) that rules yes or no. Anthropic’s docs state both halves of that plainly: completion is “decided by a fresh model rather than the one doing the work,” and the evaluator “does not call tools, so it can only judge what Claude has already surfaced in the conversation.” OpenAI’s guide to Codex goals describes the stop differently: “It will stop running when it’s confident it has reached the stopping condition,” and its advice for making that trustworthy is to “Define the commands or artifacts that prove progress.” Put those side by side and you know where the second pair of eyes comes from in each tool. Claude Code builds one in; in a Codex goal, the checks you name are the second pair of eyes — so name checkable ones.

One level deeper, so the tools stop looking magical. Anthropic’s docs describe /goal as “a wrapper around a session-scoped prompt-based Stop hook.” A hook is a small rule that fires by itself at a fixed moment — this one fires at the moment Claude would otherwise stop, and asks that second model whether your condition is met; a “no” sends Claude back to work with the reason attached. So the goal isn’t enforced by the worker’s diligence. It’s enforced by a tripwire at the exit. Codex builds the lifecycle into the goal itself — you can pause it, resume it, or clear it — with the stop decision living inside the working agent, anchored to whatever proof you named. Different architectures, one lesson that outlives both product names: know what’s standing at the exit of your loop, because that’s the thing you’re actually trusting.

The bottom line

The shift underneath the name is real, even where the name oversells it. AI work is moving from prompting one instruction at a time to giving the model a job with a rhythm and a definition of done. What earns the unattended part is the design — an honest answer to six questions: what starts it, what it sees, what stops it, what’s in scope, what it shows, and what it can spend. Three design the loop; three let you walk away from it. Whether the job is reconciling the books, keeping a site indexable, or triaging support, the discipline is the same, and none of it takes a computer-science background. If you can fill in the card, you can design a loop — and, just as useful, tell when a job doesn’t deserve one.

And a loop designed this way pays a dividend beyond any single run. Because it shows its work, every run leaves a record — what it fixed, what it couldn’t, where you stepped in — and read a few of those records together and the next version of the loop practically writes itself: a boundary widened once it’s earned, a check tightened where it got gamed, a budget trimmed to what the work turned out to need. Work that runs without you is the start; work that gets better each round is the point. That’s what the design buys you — a loop built to be trusted is also a loop built to be improved.

That’s the work we do at Agenteer: sitting with you to find the jobs worth handing off, designing the loop around each one so it’s safe to leave running, and keeping a human on the decisions that need one. If there’s a task you’re tired of being the loop for, that’s where to start.