Loop Engineering Explained: Build the Loop, Not the Prompt

“I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” That line comes from Boris Cherny, the person behind Claude Code at Anthropic — and at first it sounds backwards. You’re not supposed to talk to the AI anymore, but to build a machine that talks to it for you?

That, in a sentence, is loop engineering. It’s the term making the rounds ever since developers like Peter Steinberger started saying: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” This article explains, calmly and without the hype, what that actually means, how an agent loop works under the hood, what a good loop is made of — and where the whole thing can go wrong.

What is loop engineering?

Loop engineering is the practice of designing, operating, and improving the feedback loops that let an AI agent plan a task, change code, observe the result, and revise its approach until the work is done. Put simply: you stop driving the agent yourself and instead build the system that drives it.

For about two years, working with a coding agent looked like this: you wrote a good prompt, supplied enough context, read the reply, typed the next instruction. The agent was a tool and you held it the whole time, one turn after another. Loop engineering moves that leverage point. Instead of triggering every step yourself, you build a small system that finds the work, hands it out, checks the result, writes down what’s done, and decides the next step. You design that loop once — and let it poke the agent instead of you.

It helps to separate loop engineering from two related terms you may already know:

Prompt engineering shapes the input to the model — asking one question as well as possible.
Context engineering shapes what the agent sees — which files, tools, and information land in its context window.
Loop engineering shapes the entire process around the model — which tools it may use, which checks it trusts, when it stops, and where a human steps in.

The distinction is more than semantics: a strong first answer is not the same as a correct final change. In real code, the important signal often appears after the first action — a failing test, a type error, a reviewer spotting an edge case. Loop engineering makes those signals part of the system instead of treating them as after-the-fact cleanup.

Loop engineering encompasses prompt and context engineering — it shapes the entire process around the model.

Why a single prompt isn’t enough

Coding is iterative by nature: even experienced engineers rarely write perfect code on the first try. They run it, see the error, fix it, run it again. An agent that generates code only once can’t close that loop — and stays fundamentally limited.

Most modern agent loops trace back to the ReAct pattern (Reason + Act), introduced in research from Princeton and Google. The idea: interleave reasoning steps with action steps. The model thinks, takes an action, sees what happened, thinks again, acts again. In code that looks like: understand the goal → write some code → run it and observe the output (or error) → reason about what went wrong → revise → repeat until the tests pass.

The key difference is between a loop and a chain. A chain runs linearly: step A leads to B leads to C. A loop is dynamic: the agent can go from A to B, discover B didn’t work, retry with a different approach — and only then move on. That ability to learn from the result is exactly what separates an agent from a plain text generator.

What’s striking is how simple the core is technically. Many of the most successful agents — Claude Code among them — share the same plain architecture: a while loop that calls tools.

while (not done) {
  response = call_the_model()
  if response.tool_calls:
    run_tools_and_append_results()
  else:
    done
}

That’s essentially it. Each round passes the current state to the model, gets back a decision (usually a tool call or a text response), and moves forward. The agent is just a system prompt and a handful of well-built tools. The magic isn’t in the model alone — it’s in how cleanly that loop is built.

How the agent loop actually works

Every agent session follows the same cycle: receive the prompt, evaluate and respond, execute tools, repeat — until the model returns an answer with no further tool calls.

Claude Code makes this easy to follow. Picture the task: “Fix the failing tests in auth.ts.”

Receive: The agent gets your prompt, plus the system prompt, the tool definitions, and the history so far.
Evaluate & respond: The model sizes up the situation and decides how to proceed — Turn 1: it calls the Bash tool to run npm test (three failures).
Execute tools: The result flows back into the model — Turn 2: it reads auth.ts and the test file.
Repeat: Turn 3: it edits the code and re-runs the tests. All green.
Return: Final turn: a plain text response with no tool call — “Fixed the bug, all three tests pass.” The loop ends.

A session runs the same cycle — evaluate, execute tools, repeat — until the model answers with no further tool call.

A turn is one round inside the loop. A quick question (“what files are here?”) takes one or two turns. A complex task (“refactor the auth module and update the tests”) can chain dozens of tool calls across many turns.

Two things are worth keeping an eye on:

The context window grows. It does not reset between turns — system prompt, tool definitions, history, tool inputs, and especially tool outputs all accumulate. In fact, tool outputs make up the bulk of the tokens in a typical agent session, not the prompt. That’s why keeping context clean isn’t a side issue but central to both quality and cost.
The loop needs a brake. Without a limit it runs until the model finishes on its own — on open-ended tasks (“improve this codebase”) that can run long and get expensive. Tools provide caps for this, such as a maximum number of turns or a cost budget at which they stop.

Worth checking: The exact option names (for turn or budget limits) and slash commands change between versions. For the current state, see the official Claude Code documentation.

The five building blocks of a loop

A complete loop needs five building blocks plus a place to remember things: automations, worktrees, skills, plugins/connectors, and sub-agents — and a memory that lives outside the single conversation.

The interesting part: these pieces are no longer a hand-rolled pile of bash you maintain forever. They ship inside the products — in Claude Code just as in the Codex app. Once you recognize the shape, you stop arguing about which tool and just design a loop that works either way.

Automations — the heartbeat. They turn a one-off run into an actual loop. A schedule (cron), a recurring command, or a trigger via GitHub Actions fires the agent without you sitting next to it. An automation can read yesterday’s CI failures every morning, triage open issues, and write the findings into a file.
Worktrees — so parallel doesn’t become chaos. The moment two agents work at once, their file edits collide. A git worktree is a separate working directory on its own branch — so one agent’s edits literally can’t touch the other’s checkout.
Skills — so you don’t re-explain your project every time. A skill (a folder with a SKILL.md) captures the project knowledge the agent would otherwise guess: conventions, build steps, “we don’t do it like this because of that one incident.” Without skills, the loop re-derives your whole project from zero every cycle.
Plugins and connectors — the loop touches your real tools. Connectors (built on MCP) let the agent read your issue tracker, query a database, drop a message in Slack. That’s the difference between “here’s the fix” and a loop that opens the pull request and links the ticket itself once CI is green.
Sub-agents — keep the maker away from the checker. By far the most useful structural move in a loop: split the one who writes the code from the one who checks it. The model grading its own homework is far too kind. A second agent with different instructions — often a different model — catches what the first one talked itself into.

And then the sixth thing, the memory: a markdown file or a ticket board that lives outside the single conversation and holds what’s done and what’s next. It sounds too dull to matter — but it’s the trick every long-running agent depends on. The model forgets everything between runs; the repo doesn’t. That’s why the memory has to live on disk, not in the context.

Five building blocks plus a memory outside the conversation: the model forgets between runs — the repo doesn’t.

Stacking loops: from agent to self-improvement

The simple agent loop is only the first level. You can stack loops — swyx calls it “loopcraft” — to make agents steadily more reliable. Four levels have become a useful model.

Level 1 — The agent loop. The model calls tools in a loop until the task is done. This level automates work.
Level 2 — The verification loop. The agent loop gets work done, but not always correctly. Here you wrap it in a verification loop: a grader — a deterministic test or a second model as judge (LLM-as-a-judge) — scores the output against a rubric and sends it back with feedback if it fails. This level ensures quality. It costs a little more time and money, but it’s worth it whenever correctness matters — which is most production cases.
Level 3 — The event-driven loop. Here you connect the agent to your ecosystem: a new document lands, a schedule triggers, a webhook arrives — and the agent runs. It’s no longer something you invoke manually but a component running continuously inside a larger system. This level brings automated work at scale.
Level 4 — The hill-climbing loop. The first three levels automate work; the fourth automates improvement. Every run leaves a trace: what the model did, which tools it called, what grader feedback came back. An analysis agent reads those traces and rewrites the “harness” — prompts, tools, graders — itself. The feedback arrow doesn’t just loop back to the top; it reaches into the inner loops and makes them better with each pass.

Loops stack: each outer loop makes the inner ones more reliable — the fourth even improves the harness itself.

This stacking is the real point of loop engineering. AI researchers and practitioners like Peter Steinberger, Boris Cherny, and Andrej Karpathy have independently reached the same conclusion: the potential isn’t in the single model call but in the loops you build around it. When several agents cooperate in coordinated loops — a planner, several executors, a reviewer — you’re looking at multi-agent loop engineering, where nested loops handle far more complexity than a single agent could.

What makes a good loop

A good loop is not “just let the agent keep trying.” It’s built around five things: a clear goal, the right context, small reversible steps, reliable observation, and explicit stopping rules.

Clear goal. The loop needs a concrete definition of “done.” “Improve the dashboard” is worthless. “Reduce initial load time by deferring non-critical charts without breaking the filters” gives the agent something observable to optimize.
Relevant context. Too little context leads to wrong assumptions, too much drowns the model in noise. The loop should gather context before editing and refresh it after important observations.
Small, reversible steps. A small diff is easier to verify and easier to repair. Large speculative rewrites obscure which assumption failed. Have the agent make the smallest coherent change and expand only when the result supports it.
Reliable observation. A loop is only as good as its observations. If the agent can’t run the tests, see the compiler output, or screenshot the UI, it’s operating partly blind. Good observability turns vague confidence into evidence.
Stopping rules. The agent has to know when to stop — when the desired behavior is implemented and validation passes, when a blocker needs missing credentials or a product decision, or before a destructive command runs without explicit approval.

From this, a few recurring loop patterns emerge, depending on the task:

Retry loop: try, check, retry on failure. Good for short tasks with clear pass/fail — but only with a change of strategy, or it just spins.
Plan-execute-verify loop: generate a plan first, then execute step by step, verifying each step. Good for multi-step tasks where early mistakes compound.
Explore-narrow loop: explore several solution paths, then narrow to the most promising. Good for debugging and unfamiliar APIs — watch for context explosion.
Human-in-the-loop: the agent runs until it needs a decision or approval, pauses for your input, then continues. Good for risky or under-specified tasks.

Where loops go wrong

Badly built loops cause real problems — and the most common failures are predictable. Each one points back to a missing part of the loop.

Thrashing. The agent keeps changing code without converging. Usually that means an unclear goal, a noisy validation signal, or a diff that’s too large. Fix: narrow the objective, shrink the diff, use a more reliable observation.
Overfitting to tests. The agent makes the tests pass but misses the actual requirement — especially when tests are too narrow. Fix: combine automated tests with requirement review and, where needed, manual checks.
Context drift. The agent keeps working from stale assumptions, missing a change or a new failure. Fix: refresh context after meaningful observations and don’t treat the initial plan as sacred.
Unsafe autonomy. More autonomy isn’t automatically better. An agent that can run destructive commands or push unreviewed changes causes damage. Fix: permissions, scoped tools, human approval for risky actions.
No exit. Without an explicit stop condition, the loop runs forever or stops arbitrarily. A rule like “after 10 iterations with no progress, escalate to a human” is not a nicety but a required part.

The most common failure modes are predictable — each points back to a missing part of the loop.

You stay the engineer

The loop changes the work; it doesn’t delete you from it. Three problems actually get sharper as the loop gets better — not easier.

First: verification is still on you. A loop running unattended is also a loop making mistakes unattended. That’s exactly why you split the verifier sub-agent from the maker — to make the loop’s “it’s done” mean something. And even then, “done” is a claim, not a proof. Your job is to ship code you’ve confirmed works.

Second: your understanding rots if you let it. The faster the loop ships code you didn’t write, the wider the gap between what exists and what you actually understand. A smooth loop grows that gap faster — unless you read what it built.

Third: the comfortable posture is the dangerous one. When the loop runs itself, it’s tempting to stop having an opinion and just take whatever comes back. Designing the loop is the cure when you do it with judgment — and the accelerant when you do it to avoid thinking. Same action, opposite result.

That’s what makes loop design harder than prompt engineering, not easier. Two people build the same loop and get opposite results: one uses it to move faster on work they understand deeply, the other to avoid understanding the work at all. The loop doesn’t know the difference. You do.

FAQ: Common questions about loop engineering

What is loop engineering in simple terms?

Loop engineering is the practice of building AI systems that don’t just answer once but work in loops: take an action, observe the result, reason about it, and repeat until a goal is met. Instead of prompting the AI agent at every step yourself, you design the system that prompts it — with tools, checks, stopping rules, and clear points for human intervention.

What’s the difference between loop engineering and prompt engineering?

Prompt engineering shapes the input to the model — asking one question as well as possible. Loop engineering shapes the entire iterative process around the model: which tools it may use, what context it sees, which validation it trusts, when it stops, and where a human steps in. Prompt engineering aims at a better first answer; loop engineering aims at a better final outcome.

What’s the difference between a loop and a chain in AI agents?

A chain runs in a fixed order: A → B → C. A loop is dynamic — the agent can repeat steps, adjust based on feedback, or retry with a different approach. Chains are predictable and easy to trace. Loops are more flexible and better suited to tasks where the right path isn’t known upfront, like debugging.

Is loop engineering only for developers?

The term comes from the coding world and is most mature there, because code is verifiable by nature (tests, compilers). But the principle — act, observe, adjust, repeat — applies anywhere a task needs multiple steps and real feedback. Knowing the core ideas, especially clear stop conditions and error handling, helps you build better agents even without programming skills.

What makes a loop “good”?

A good loop has five things: a concrete goal with a testable stop condition, a useful set of tools, clean context management against token overflow, explicit failure exits against infinite loops, and error handling that produces genuine adaptation rather than retrying the same failed approach.

Conclusion

Loop engineering isn’t a new secret trick but a shift in leverage: away from the perfect single prompt, toward designing reliable systems of context, action, observation, and correction. The core is surprisingly simple — a loop that calls tools until a task is done. The art is at the edges: well-built tools, clean context, a checker separated from the maker, and stopping rules that mean something.

Build the loop — but build it like someone who intends to stay the engineer, not just the person who presses go.