Loop engineering is the practice of designing the system that prompts, checks, remembers, and re-runs an AI agent — instead of you typing every next instruction by hand. The unit of work is no longer a single prompt or a single conversation; it is a loop with a goal, a tool set, a verifier, and a stop condition. In June 2026, Google's Addy Osmani named the discipline in an essay titled "Loop Engineering" and gave it an anatomy: automations, worktrees, skills, connectors, sub-agents, and external state. The thesis is simple and worth memorizing: the scarce skill is no longer phrasing the prompt. It is defining what "good" and "done" mean — and wiring that definition into a loop the agent runs inside of on its own.
If you have only heard the marketing version of loop engineering ("just let Claude run all night"), this guide is the honest version. The model is not the bottleneck. The verifier is. Build a weak verifier and you get a fast, confident, wrong loop. Build a strong one and you get a loop that can run unattended for an hour and ship work you can trust. The rest of this guide is how to build that — the doer-judge architecture, the four loop patterns that have proven out in 2026 production work, and the six building blocks Addy Osmani laid out, in the order you should assemble them.
The shift: why the verifier — not the model — is the bottleneck
Boris Cherny, head of Claude Code at Anthropic, said the quiet part out loud in June 2026: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." He is not exaggerating. At the same Cisco AI Summit (February 2026), Anthropic CPO Mike Krieger reported that "Claude is being written by Claude. Claude products and Claude Code are being entirely written by Claude," with the lab team "regularly producing 2,000 to 3,000 line pull requests" through agent loops. Dario Amodei's spring-2025 forecast of 90% AI-written code had crossed into "effectively 100%" inside Anthropic a year early.
The pattern driving that throughput is older than any of the demos. The root is the ReAct paradigm (Reason + Act) introduced by Shunyu Yao and colleagues at Princeton and Google Brain in the 2022 paper "ReAct: Synergizing Reasoning and Acting in Language Models" (arXiv:2210.03629, published at ICLR 2023). ReAct interleaves a reasoning trace with tool actions inside a loop; each turn produces an observation the model reasons over next. Loop engineering keeps that core cycle but moves the human out of the turning loop. The agent prompts itself; the loop continues until a verifier — not the model, not a human — agrees the goal is met.
That last clause is the part almost every explainer skips, and it is why this guide spends its word budget on verification rather than on prompt templates. Verifiers fall into a documented family — offline evals, online runtime judges, self-consistency checks, reflection-style retries, constitutional/rule-based critics, and inference-time reward models. The Zylos April 2026 LLM-as-judge research review found that more than half of surveyed production agent teams now rely on a judge model at runtime for quality gating, hallucination defense, or tool-call verification. Cherny publicly credited the verification step in his own loops with a "2 to 3×" quality improvement over hand-prompting. That is the lever. The model got good enough to run unsupervised; the loop only ships because the verifier got good enough to catch it when it does not.
The doer-judge architecture
Strip every 2026 production agent loop to its bones and you get the same three-role structure. Everything else — worktrees, skills, memory, connectors — is plumbing for these three:
- The doer (a.k.a. generator, actor). The LLM that takes the current state and produces a candidate action: a code change, a tool call, a draft. It is fast and creative and only as good as its context.
- The judge (a.k.a. verifier, evaluator). A process that takes the doer's candidate and returns a verdict: pass, fail, or "fix this specific thing." Crucially, the judge is not the doer prompting itself. It is either a separate model, a real-world tool (a test runner, a type checker, a linter, a human review step), or an executable condition (file exists, schema validates, build is green). Same-family judging produces a documented 5–7% self-preference inflation — Claude judging Claude, GPT-4 judging GPT-4 — so for anything that ships, the judge is either cross-family, tool-based, or human.
- The loop controller (a.k.a. harness, scheduler). The code that runs the doer, hands the output to the judge, decides whether to iterate, escalate, or stop, and persists state between turns. This is what you actually write. In Claude Code it is the
/goaland/loopruntime; in custom systems it is a few hundred lines of Python that call the model API and the judge in awhilecycle.
state = load_state()
while not stop_condition(state):
proposal = doer(state) # generator LLM
verdict = judge(proposal, state) # model, tool, or human
if verdict.passed:
commit(proposal); break
state = update(state, verdict.feedback)
That six-line skeleton is 90% of loop engineering. The doer proposes. The judge rejects with feedback. The controller loops. The scarce engineering decisions are: what does "done" mean as an executable condition, what kind of judge enforces it, and how does state persist so the loop does not regress across iterations.
The four loop patterns, ranked by autonomy
Not every loop needs to be autonomous. Pick the lightest pattern that adds a real judge. Each of these ships in production in 2026.
1. The Ralph loop (crude but bulletproof)
A bare while true: shell that re-fires the same prompt until you stop it. There is no smart "done" — you are the stop button. Use it for mechanical, repetitive, low-stakes work where the cost of an accidental over-iteration is zero: regenerating thumbnails, re-running a scraping job, retrying a flaky deploy. Anything that touches your database, your users, or your prod credentials gets a judge before it gets a Ralph.
2. Goal-tracked loops (the workhorse)
The doer runs; a small, fast, separate model evaluates a completion condition after every turn and tells the controller whether to keep going. This is what Claude Code's official /goal runtime exposes: you write a goal in plain English, a judge model checks progress against it after each turn, and the controller holds or releases based on that verdict. The verifier here is fuzzy by design — it can describe "done" in natural language — but it is still a separate role from the doer. This is the right starting place for almost every team moving from interactive prompting to loops: pick a fuzzy-but-distinct judge, ship a single closed-loop task, measure what breaks.
3. The maker-checker loop (the production default)
Two specialized sub-agents split the doer and judge roles explicitly. The maker writes code (or whatever artifact). The checker reviews it against an executable spec: do the tests pass? does the build compile? does the diff match the plan? does the API response validate against the schema? This is the pattern Cherny is describing when he credits verification with a 2–3× quality multiplier, and it is the dominant shape in coding-agent production today. Make the judge tool-based wherever you can — pytest, tsc --noEmit, eslint, cargo build — because tools do not hallucinate and do not have aesthetic preferences. Reserve model-based judges for fuzzy domains (prose quality, design taste) and use a different model family from the doer to dodge self-preference inflation.
4. The fusion-boardroom (multi-judge council)
For high-stakes decisions — architecture choices, security-sensitive refactors, research synthesis — run several judges with different perspectives and resolve disagreement by vote or by a meta-judge. The pattern borrows from Sakana AI's "LLM-squared" evolutionary-learning approach, where multiple agents debate and a selection step suppresses weak proposals. Production versions in 2026 usually look like: two differently-prompted maker agents produce candidates, three judge models from different families score them on a rubric, majority vote releases. This is expensive (O(beam_width × depth) judge calls) and slow, so reserve it for the work where a wrong ship is more expensive than the extra tokens.
The six building blocks (Addy Osmani's anatomy, in build order)
From the canonical June 7, 2026 essay at addyosmani.com/blog/loop-engineering/, plus the state/memory piece that pre-dates it — six primitives. Build them in this order; each one earns the next.
- Automations. The trigger layer — what wakes the loop. A cron tick, a webhook, a file watch, a heartbeat. Cheap. Start with a cron and a one-line goal.
- Worktrees (isolation). Every loop run lands in its own working directory or git worktree so concurrent runs do not clobber each other and a failed run leaves no residue. Non-negotiable once you run more than one loop at a time.
- Skills. Codified procedural knowledge the agent can load on demand — your SQL conventions, your deployment runbook, your code-review checklist. Skills replace prompt engineering with file engineering; you version and review them instead of re-typing them.
- Connectors / plugins. The tool set the loop can actually call — API clients, a terminal, a test runner, a browser. A loop is only as honest as its tools; without a real terminal, the doer can only claim it ran the tests.
- Sub-agents. The maker-checker split, expressed as separate agent contexts. Crucially, leaf sub-agents do not call other sub-agents — the tree stays shallow and the feedback loop stays tight. This is where the doer and the judge become two distinct processes instead of one prompt doing both.
- State / memory. Persistent state lives on disk (or a DB, or an object store), never in the model's context window. Context gets compacted; context gets truncated; context resets when the session restarts. State on disk is the only reason a loop that runs for an hour stays oriented. Write the goal, the plan, the checkpoints, and the verdicts to files the controller can read back on every turn.
Build 1 through 4 before you touch 5. Add 6 the moment your loop runs longer than a single chat session — that is the instant "what did the agent decide last turn" stops being answerable from memory.
What loop engineering is not
Most developers do not need agent loops yet. If your task finishes in one prompt, you are done — engineering a full loop to ship a one-shot job is overhead, not leverage. A loop also does not remove the human from responsibility for the output. You own the goal, the definition of "done," and the judgment about whether what the loop shipped is actually correct. The loop removes you from the turn-by-turn prompting. It does not remove you from answerability for the result.
Two failure modes are worth naming because both are common in early 2026 post-mortems.
- Runaway loops. A weak verifier plus no budget cap means the doer iterates forever, each turn "almost there," each turn rejected for the same vague reason. The fix is a hard turn-cap and a stop-condition the judge can actually evaluate (
tests pass, notthe code is good). - Judge collusion. Same-model judging inflates pass rates 5–7% because the judge has absorbed the doer's stylistic preferences and is biased toward work that looks like its own. The fix is cross-family judging or tool-based verification.
The pre-flight checklist (before you let any loop run unattended)
Before you let any loop run while you sleep, every one of these is true:
- The goal has an executable stop condition ("all tests green, linter clean, build succeeds"), not a vibe ("the code is improved").
- A budget cap is set: max turns, max tokens, max wall-clock, max dollars. The controller kills the loop when any cap is hit, regardless of the doer's protests.
- A human gate exists for anything irreversible: merge, deploy, close, delete, charge, publish. The loop can do the work; the human flips the last switch.
- The judge is not the doer — different model family, or a tool, or a human, or some combination.
- State is on disk, not in context. On crash, the controller can read it back and resume.
- Every run lands in its own worktree so a bad run does not poison the next one.
Tick all six and the loop is production-grade. Skip one and you will find out which one, usually at 3 a.m.
How to start this week
Pick one repetitive task you do every day. Before you write a single instruction, write down what "done" means in measurable terms — tests pass, schema validates, count is above threshold, file exists. That sentence is your verifier. Pick a cron trigger, give the doer access to the tool that checks it, and run the loop in a worktree. Let it ship one small thing while you watch. If the output ships, that is your first loop. If it does not, you have a verifier bug — and that, not your prompt, is the thing to fix.
The skill is not in writing better prompts. The skill is in drawing the line the agent stops at. Everything in loop engineering is a way of drawing that line.
Discussion
0 comments