Loop engineering: stop prompting your AI, start designing the loop

For a few years the skill everyone chased was writing the perfect prompt. Then, in mid-2026, a single idea reorganised how a lot of people work with AI: stop prompting your agent by hand, and design the loop that prompts it for you. This is the full tutorial — what a loop is made of, which loop pattern to pick, the stop conditions you must define before you start, why loops quietly become expensive, and how to build one that converges instead of spinning.

1. The moment the job changed

In June 2026 an engineer working on AI coding tools described how their own workflow had changed, and the sentence spread everywhere:

Within weeks the practice had a name. Essays by Addy Osmani, a viral one-liner from Peter Steinberger, and a wave of developers putting their coding agents on repeat turned loop engineering into the phrase of the season — the same treadmill that ran from prompt engineering (2023) to context engineering (2025) and on to graph engineering a month later.

Underneath the branding is a genuine change in what the work is. The question stops being "what should I type?" and becomes:

2. Prompt, context, loop, harness — how the layers fit

These four terms get argued about as if they compete. They don't. They are nested layers, and knowing which one you are actually working on saves a lot of wasted effort.

3. The five parts of every loop

A loop is not "call the model again". Strip any working agent down and you find the same five components. Leave one out and it fails in a way you can predict from which one is missing.

1. Trigger — what starts it A schedule, an event, a webhook, a human instruction, or another agent finishing. If a person has to start it every time, you have automation with extra steps, not a loop.
2. Goal — a state you can check Not "improve the code" but "the test suite passes and no new lint errors". If you cannot write the success condition in one sentence, the task is not scoped yet — rescope it before writing any code.
3. Actions — what it may do The tools available on each turn: read a file, run a command, call an API, spawn a sub-agent. A wider action space is not better; it is more ways to go wrong.
4. Verification — how you know Genuine evidence from outside the agent: an exit code, a test result, a schema validation, a diff review, a supervisor. This is the component people skip, and skipping it is why their loop never terminates correctly.
5. Memory — what carries across turns What the next iteration knows about the last one. Too little and it repeats failed attempts; too much and it drowns in its own history. Both failure modes are common and they look nothing alike.

4. ReAct, and the four loop patterns worth knowing

The intellectual ancestor is ReAct (Reason + Act), from research at Princeton and Google, which interleaved reasoning steps with action steps. It showed something that now feels obvious: a model that observes the result of each action before taking the next one behaves completely differently from one that answers in a single shot.

ReAct is not the only shape, though, and picking the wrong one is expensive. Here are the four you will actually meet:

Reported comparisons: Plan-and-Execute has been measured around 92% task completion against ReAct's 85% on the same suite, while ReAct runs roughly 3–5 model calls and 2,000–3,000 tokens per task. Reflexion's headline result was a jump from 67% to 91% pass@1 on a coding benchmark across three attempts — the gain coming entirely from the self-reflection step.

5. The three exits you must define before you write the loop

This is the highest-value section of this tutorial. Nearly every agent horror story is a loop with one exit where it needed three.

# the loop everyone writes first — one exit, three ways to hurt you
while True:
    result = agent.run(task)
    if looks_done(result):        # the agent's own opinion. not evidence.
        break

# the loop that survives contact with production
for turn in range(MAX_TURNS):          # exit 3a: hard turn cap
    if spent >= TOKEN_BUDGET:           # exit 3b: checked BEFORE the call
        return halt("budget", turn)

    action = agent.decide(goal, context)
    result = run(action)
    spent += result.tokens

    if verify(goal, result):            # exit 1: external evidence
        return done(result)
    if result.fatal or retries(action) > 3:
        return escalate("unrecoverable")  # exit 2a
    if no_progress(context, result, window=3):
        return escalate("stuck")          # exit 2b: the one people forget

    context = compact(context, result)   # see §7 — or this gets expensive
else:
    escalate("no progress within budget")

Typical starting values people converge on: a turn cap somewhere around 15–25 for a focused task, a per-action retry limit of 2–3, and a no-progress window of 3 turns. Tune from there — but set all three on day one, not after the first incident.

6. Verification: the part that decides everything

Useful verification comes in three tiers, and mature loops run all three:

• Action level — did this one operation succeed? Exit code 0, file written, HTTP 200, JSON parsed against a schema.
• Iteration level — is the run as a whole getting better? A cheap check after each cycle: fewer failing tests than last turn, the diff is smaller, the error changed.
• Terminal level — is the actual goal met? The full success condition, run once before you accept completion.

The critical property is that all three come from outside the model. "The agent reports what the script says, not what it thinks." For code work this is why test-driven loops dominate: the test suite is an oracle the agent cannot argue with, and writing the test first has been reported to roughly halve wasted retry cycles.

7. Why loops get expensive (the maths nobody shows you)

Here is the thing that surprises teams. A loop does not cost N × one call. Most naive loops feed the entire growing conversation back to the model every turn, so every failed attempt is re-read on every subsequent turn. Cost grows with the square of the turn count, not linearly.

The reported scale of this is genuinely large:

Figures collated from published 2025–2026 measurements including Stanford Digital Economy Lab work on agentic coding and Gartner's pilot-to-production token gap. Orders of magnitude are the useful signal here, not the exact multipliers.

8. The failure gallery

Failed agents fail in a small number of recognisable ways. Learning to name them is most of learning to fix them.

Notice how many of these are observability problems rather than intelligence problems. You cannot fix a loop you cannot see. Which leads directly to the next section.

9. The production-safe loop: spec, breaker, ledger, gate

A pattern has settled for loops that are allowed to run unattended. Four components, none of them clever, all of them boring in the way production things should be:

1. The spec — commitment before execution Three questions, answered and frozen before the loop runs: what does this do? What does it explicitly not do? What does done look like, in one sentence? Inject all three into every turn's system prompt so the goal cannot drift.
2. The circuit breaker — hard ceilings, checked pre-flight A turn limit and a token limit, evaluated before each model call. No soft warnings, no grace periods. Breach raises immediately and hands off to a human.
3. The ledger — an append-only audit trail One row per turn: turn number, tokens used, duration, pass or fail, and the breach reason if it stopped. No updates, no deletes. When something goes wrong at 3am, this file is the only reason you will be able to explain it.
4. The review gate — the loop runs to you Nothing flows downstream until a human has seen the original promise, the acceptance criteria, what actually changed, the evidence, and the unresolved assumptions. Put the gate exactly where a mistake is expensive to reverse.

10. Seven levers for cheaper loops

In rough order of how much they typically save:

1. Reduce turns Turn count is the dominant cost term because of compounding. A better first prompt that saves three turns beats almost any other optimisation.
2. Compact between turns Carry forward the lesson ("approach X fails because Y") instead of the full transcript of the failure. This attacks the squared term directly.
3. Tier your models Reserve the strongest model for the decide step; run routine observation and summarisation on a cheaper one. Reported savings for the routine portion run roughly 60–80%.
4. Isolate sub-agents Give a sub-agent a narrow task and a fresh context, and return only its conclusion. The parent never pays for the child's transcript.
5. Verify cheaply before verifying expensively Run the fast check every turn and the full suite only when the fast check passes. Most turns fail for cheap reasons.
6. Scope the tools Every tool definition is tokens on every turn. Fifteen tools the agent never uses is a tax paid on each iteration.
7. Fix stale context at the source Out-of-date documents look identical to current ones in a retrieval result. The agent reads them, acts, fails, and retries — burning the budget on every cycle. Teams that fixed this reported loop lengths dropping by more than half.

11. Your first loop, this weekend

Build something small and real. A good starter project is a loop that keeps your own repository tidy:

1. Pick a goal with a machine-checkable answer. "All tests pass and lint is clean" is perfect. "Make the code nicer" is not a goal, it is a mood.
2. Write the success condition as one shell command that exits 0 or non-zero. That command is now your oracle. Do not let the agent grade itself.
3. Write the three exits before the loop body. Turn cap 15. Token budget you are comfortable losing. No-progress window of 3.
4. Log every turn to a file — turn number, action taken, tokens, pass or fail. You will learn more from this file than from the agent's output.
5. Run it and watch where it goes wrong. It will. Note which of the six failure modes you hit; that tells you which component is missing.
6. Add compaction only after you have felt the cost. Compare tokens on turn 1 against turn 10. The compounding becomes very concrete when it is your own bill.

Every principle in this article shows up at that scale, cheaply. You will discover by turn four that "looks done" is not a stop condition, and by turn nine why compaction exists.

12. Glossary

Loop

The cycle an agent runs: decide, act, observe, verify, repeat — until an exit trips.

Turn / iteration

One pass through the loop, usually one model call plus its tool calls.

Harness

The whole system around the model that runs the loop: tools, sandbox, retries, logging, limits.

ReAct

Reason + Act. Interleaves a thinking step with an action step so each move is informed by the last result.

Reflexion

Writing a natural-language post-mortem after a failure and carrying it into the next attempt.

Stop condition

Any rule that ends the loop. You need three families: success, failure and budget.

Circuit breaker

A hard pre-flight limit on turns or tokens that refuses the next call rather than reporting the overspend afterwards.

Compaction

Summarising prior turns so the context carries the lesson without the full transcript.

Doom loop

An agent repeating a failing action indefinitely because nothing measures progress.

Progress signal

Any measurable improvement between turns — fewer failures, smaller diff, a changed error.

Verifier / oracle

Something outside the agent that says pass or fail. Usually a test suite, schema or exit code.

Ledger

An append-only record of every turn, used to explain what a loop did after the fact.

Frequently asked questions

Where this leaves you

This is the quiet shift from using AI to engineering with it. The model is the smallest part of the picture — as we covered in why the model is the smallest part of an AI agent, the harness runs the loop, not the model. Loop engineering is how you make that loop converge instead of wander, and its two hardest requirements are unglamorous: a goal a machine can check, and the discipline to write the exits before the body.

If you are building an agent that has to run against a goal rather than a single prompt — a coding agent, a research agent, an automation that works unattended — loop design is where its reliability comes from. That is exactly the kind of system we build and harden for production.

Talk to us about your AI project