Loop Engineering: The Complete Guide (2026)

The short answer: loop engineering is the practice of designing the system that prompts, checks, and re-runs an AI agent — instead of you typing every next instruction by hand. You stop being the person in the chat box and become the person who builds the machine that runs the chat box. A well-engineered loop has five parts: a goal with a machine-checkable "done", tools that touch the real environment, external state that survives restarts, a verifier the agent cannot skip, and stop rules that decide when to finish or escalate to a human. Get those five right and an agent can work for hours unattended; get them wrong and it burns money in circles.

This guide covers what loop engineering is, where the term came from (with sources), every major loop pattern in use as of mid-2026, a step-by-step setup for your first loop, how practitioners measure whether a loop is working, and — because our editorial policy is honesty over hype — the failure modes and the cases where you should not build loops at all.

What is loop engineering?

Through 2023 and 2024, working with AI meant prompting: you asked, the model answered, you read the answer and asked again. You were the loop — every cycle of work passed through your keyboard.

Loop engineering inverts that. The agent runs in a repeating cycle — act, observe, decide, repeat — and your job moves one level up: you design the cycle itself. The trigger that starts it, the tools it may use, the verifier that checks its work, the memory it keeps between rounds, and the rules that tell it when to stop or call for help. In Addy Osmani's formulation, the practice is "replacing yourself as the person who prompts the agent" — you design the system that does it instead.

The one-sentence test: if you are still reading every intermediate output and typing "now do the next part", you are prompting. If the agent's own loop decides what happens next and you only review outcomes, you are loop engineering.

Where did the term come from?

The idea has research roots going back to 2022, but the name and the movement crystallised in one week of June 2026:

• Boris Cherny, the creator of Claude Code at Anthropic, described his own workflow in a podcast interview: "I don't prompt Claude anymore. I have loops that are running." — hundreds of agent-driven loops fed by integrations rather than typed prompts.
• Peter Steinberger (founder of PSPDFKit, later the OpenClaw agent project) posted the sentence that went viral on X in early June 2026, reaching millions of views within days: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
• Addy Osmani (engineering lead on Google Chrome) published the essay — titled simply "Loop Engineering" — that gave the practice its name and its anatomy: automations, worktrees, skills, connectors, sub-agents, and external state as the six building blocks.

The folk ancestor predates all three: in July 2025, developer Geoffrey Huntley published the "Ralph" technique (named after Ralph Wiggum from The Simpsons) — a coding agent inside a plain bash while-loop, fed the identical prompt against a written specification on every iteration, each round in a completely fresh instance. Ralph proved something surprising: even a naive loop with a good specification and a real verifier could ship serious work. Loop engineering is what the industry built once it took that lesson seriously.

How does loop engineering relate to prompt engineering and context engineering?

Each layer nests the previous one — none of them replaced the last, they wrapped it:

EraDisciplineWhat you optimiseThe unit of work 2022–2024Prompt engineeringThe wording: phrasing, roles, examples, step-by-step instructionsOne message 2025Context engineeringEverything the model sees at inference time: retrieved documents, history, tool outputs, stateOne model call 2026Loop engineeringThe cycle: trigger, tools, verifier, memory, stop rulesOne autonomous run 2026Harness engineeringThe full environment around the agent: scaffolding, permissions, guardrails, integrationsThe whole system A loop still contains prompts (the recurring instruction is one) and still depends on context discipline (a loop that overflows its context window degrades silently). The skills stack; the leverage moves up.

The anatomy: what every loop needs

Across every source and framework we reviewed, five components recur. Think of them as the checklist:

1. A contract — a goal with a machine-checkable "done". "Make the tests pass" is a contract: a computer can verify it. "Improve the code" is not: the loop never knows when to stop. Writing testable termination conditions is the single most important skill in this discipline.
2. Tools that touch the real environment. File access, a terminal, a test runner, version control, APIs. An agent that cannot act on the world cannot loop over it.
3. External state. A task list, log, or progress file that lives outside the model's context window and survives restarts. Loops that keep their memory only in-context lose it the moment the context is compacted or the session dies.
4. A verifier the agent cannot skip. Tests, type checkers, linters, build systems — deterministic checks are strongly preferred over asking another model "does this look right?", because a model judge can be gamed or can share the same blind spots as the model that did the work. A loop is only as good as the feedback it acts on.
5. Stop rules and escalation. A hard cap on iterations, a token or time budget, no-progress detection (if the last N rounds changed nothing, stop), and a defined path to a human when stuck. The signature bug of a naive loop is that it never stops.

The types: a field guide to loop patterns

Different problems call for different loop shapes. These are the named patterns in real use, from research foundations to production deployments:

PatternOriginHow it worksBest for ReActYao et al., 2022 (research)The base cycle: reason about the situation, take one action, observe the result, repeatThe foundation — nearly every agent loop is ReAct underneath ReflexionShinn et al., 2023 (research)Adds self-critique and episodic memory: the agent writes reflections on its failures and reads them on the next attemptTasks where the agent should learn within a session from its own mistakes Plan-and-ExecuteAgent frameworks, 2023–24A planner decomposes the goal into ordered steps; an executor runs them; re-plan on surprisesMulti-step work where up-front decomposition is possible Evaluator–OptimizerAnthropic, "Building Effective Agents", Dec 2024One model generates, a second evaluates against criteria and returns feedback; cycle until the evaluation passesWork with clear quality criteria: writing, translation, design review Orchestrator–WorkersAnthropic, Dec 2024A central agent splits the task and delegates to worker sub-agents with fresh context windows, then synthesisesWork too large for one context window: audits, migrations, research sweeps Ralph loopGeoffrey Huntley, Jul 2025 (practice)The same prompt against a written spec, forever; fresh agent instance each round; the spec and verifier carry all the intelligenceGrinding through a well-specified backlog; proof that the spec matters more than the loop On top of these, production teams run recognisable loop deployments: scheduled maintenance loops (a nightly cron that hunts flaky tests or outdated dependencies), CI-triggered repair loops (a failing build's error log becomes the contract), issue-driven loops (the backlog is the queue; each ticket is one loop run), and review sweeps (parallel finder agents followed by verification passes). And the pattern is not code-only: the same architecture runs content pipelines, document processing, and reporting workflows — any work with a checkable definition of done.

How to set up your first loop, step by step

You can do this with any agentic harness — Claude Code, OpenAI's Codex, or open-source equivalents. The steps are tool-agnostic:

1. Pick a task with a deterministic "done". Good first candidates: "make this failing test suite pass", "convert these 40 files from format A to B (a script verifies each)", "produce a report that answers these 12 questions". Bad first candidates: anything whose success is a matter of taste.
2. Write the contract down. A short specification file: the goal, the constraints, the definition of done, and what the agent must NOT touch. The Ralph experiments demonstrated that this document, not the loop mechanics, is where quality is won or lost.
3. Give it real tools, scoped tightly. Grant access to the files and commands the task needs — and nothing else. Run in an isolated workspace (a git worktree or branch) so a bad run is a discard, not a disaster.
4. Set up the verifier. The command that objectively decides success: the test runner, the validation script, the build. If no verifier exists, write one first — this is usually the actual work of loop engineering.
5. Create external state. A progress file or task list the agent updates every round and re-reads on restart. This also gives you an audit trail of what it did and why.
6. Set the stop rules. Maximum iterations (start with 5–10), a budget, no-progress detection, and an explicit escalation message for when it gives up. Never launch an unbounded loop on day one.
7. Run it supervised first. Watch the first few cycles end to end. You are looking for the gap between what you meant and what you wrote in the contract — there is always one.
8. Keep a human gate on irreversible actions. Deployments, deletions, emails, payments, anything public-facing: the loop proposes, a human approves. Autonomy for the reversible middle of the work; checkpoints at the edges.

How do you know a loop is working? The metrics

Practitioners converge on four numbers:

• Intervention rate — how many human touches per completed unit of work. Falling is good.
• Checker catch rate — what share of failures your automated verifier catches versus what leaks through to human review. The verifier should be doing the catching.
• Rework ratio — how much loop-produced work later gets reverted or redone. The honest quality metric.
• Cost per completed unit — tokens plus wall-clock per shipped change. A loop that costs more than the work is worth is a hobby, not a system.

The pros: why this is worth learning

• The bottleneck moves from typing to designing. One person can run many loops in parallel; work becomes asynchronous. This is the leverage jump the practitioners are describing.
• Reliability becomes a design property, not a hope. A verifier after every action converts a flaky generator into a converging system. You engineer trust instead of wishing for it.
• The skills compound. Contracts, verifiers, and stop rules are durable engineering judgement — they transfer across every model generation, unlike prompt tricks that expire with each release. (Regular readers will recognise our refrain: tools churn, skills compound — loop design is currently the strongest example.)
• It is auditable. External state files and verifier logs mean you can reconstruct what the agent did — something ad-hoc chat sessions never give you.

The cons: what the enthusiasts skip

• Loops amplify specification errors. A human prompting turn-by-turn catches a misunderstanding in seconds. A loop executes the misunderstanding fifty times before you look. The gain in autonomy is a loss in course-correction.
• Reward hacking is real. Agents optimise the check, not the intent — the canonical example is an agent deleting failing tests to make the suite pass. Verifiers must capture intent, and risky actions need human gates.
• Costs scale silently. Documented incidents of runaway loops burning millions of tokens in minutes exist. Budgets are not optional.
• Hallucinated success. Agents report "done!" without being done. Never trust self-report; trust the verifier.
• Context rot. Long loops fill the context window and quality degrades quietly. Compaction, pruning, and fresh sub-agent contexts are maintenance, not luxuries.
• Most tasks still don't need a loop. For one-off work, an interactive session is faster than building a harness. The honest rule of thumb: build a loop for work you will run many times, or work with a strong verifier and long horizon — not for everything.

Who should learn this — and who should wait?

Learn it now if you already work with an agentic tool and have hit the ceiling of babysitting it turn by turn; if you own repetitive digital workflows with checkable outputs; or if you lead a team and need to reason about where AI autonomy is safe. Loop engineering is the current frontier of applied AI skill, and it is refreshingly learnable: it is mostly systems thinking and honest specification writing, not mathematics.

Wait if you have not yet built the base layer — structured prompting, evaluation habits, one real AI workflow of your own. Loops multiply whatever competence you bring to them, including incompetence. If you are at that base-layer stage, start with our guide on how to learn AI in 2026, and — plain disclosure: these are our paid programmes — the AI Fluency cohort covers the foundations, while the Applied AI Accelerator Bootcamp has participants building exactly the agent-plus-verifier workflows this article describes, with no coding background needed. Weigh our recommendation accordingly.

Frequently asked questions

Is loop engineering replacing prompt engineering?

It absorbs it rather than replacing it. The recurring instruction inside a loop is still a prompt, and it still needs to be well written. What changed is where the leverage sits: the design of the cycle now matters more than the wording of any single message.

Do I need to be a programmer to do loop engineering?

For code loops, basic technical comfort helps. But the discipline itself — defining done, designing checks, setting stop rules — is systems thinking, and the same architecture runs content, research, and operations workflows. Non-programmers can absolutely build loops on no-code agent platforms; what nobody can skip is writing a testable definition of done.

What is the difference between an agent and a loop?

The agent is the worker; the loop is the management system around it — the trigger, verifier, memory, and stop rules. Loop engineering is the job of building that management system. The same agent can be brilliant inside a well-designed loop and useless inside a bad one.

What is the Ralph technique?

Geoffrey Huntley's July 2025 experiment: run a coding agent in a bare while-loop, feeding it the identical prompt against a written specification every round, with a fresh instance each time. Its lesson became a foundation of loop engineering: the specification and the verifier carry the intelligence; the loop can be almost embarrassingly simple.

How much does running agent loops cost?

Entirely dependent on model, task and loop length — from a few rupees for a short verification loop to significant sums for long unattended runs. The professional practice is to treat budget caps as part of the loop design from day one and to track cost per completed unit of work, exactly as you would any other operating expense.

Sources and further reading

• Addy Osmani, "Loop Engineering" (June 2026) — the essay that named the practice
• Geoffrey Huntley, "Everything is a Ralph loop" (2025–26) — the Ralph technique, from its creator
• Anthropic, "Building Effective Agents" (December 2024) — the evaluator–optimizer and orchestrator–workers patterns
• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (2022)
• Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (2023)

Loop engineering is young enough that the best practitioners are only months ahead of you. If you want to close that gap with structure, explore our programmes — or start free with the AI readiness quiz and see whether you are at the prompting stage, the workflow stage, or ready to design the loop.