Skip to content

Loop engineering

Updated 17 July 2026 Reviewed by Teemu Malinen

What is Loop engineering?

Loop engineering is the practice of designing the outer feedback loop an AI agent runs in. You set a goal, define how success is verified and where the loop must stop, and the agent then iterates on its own (acting, checking its work, correcting) without a human prompting each turn. The engineer's job moves from wording a single prompt to designing the system that prompts the agent. This outer orchestration is distinct from the inner reasoning cycle a single agent turn runs; loop engineering wraps around that cycle. As Google engineer Addy Osmani put it in 2026, it means "replacing yourself as the person who prompts the agent" and building the system that does it instead.

Why it matters

For two years the advice was to write a better prompt. That advice is running out of road. Once an AI agent can use tools, read the result of what it just did and decide what to do next, the thing that decides whether it succeeds is no longer the wording of one instruction. It is the shape of the loop the agent runs in, and whether that loop knows when it has finished. Loop engineering is the name that settled on that work in 2026. As Swyx argued in his “Loopcraft” talk at the AI Engineer World’s Fair that June, AI engineering has moved from chat to tools to goals, and the leverage is now in designing the system that prompts the agent rather than writing the prompt yourself.

This matters for anyone deploying agents rather than chatting with a model. A single well-worded prompt gives you one good answer. A well-designed loop gives you an agent that keeps working while you sleep, fixes a failing test, opens a pull request or triages an incident, and then stops before it burns money or ships something broken. The gap between those two outcomes is loop engineering, and it is mostly design work, not model choice.

What is loop engineering?

Loop engineering is designing the outer loop an AI agent runs in, instead of prompting the agent by hand each turn. You are not writing the agent’s next instruction. You are setting the goal it works toward, defining the check that decides when it is done, and fixing the limits that stop it. Everything between the start and the stop, the agent runs on its own. Addy Osmani, an engineer at Google, gave the definition most people quote: it means “replacing yourself as the person who prompts the agent,” and designing the system that does it instead.

The word “outer” is doing real work here. A single agent turn already runs a loop of its own, deciding what to do and reacting to the result. Loop engineering sits outside that inner cycle. It is the orchestration wrapped around it: the system that keeps sending the agent back to work, run after run, toward a goal, without a person in the conversation. The underlying idea is older than the name. Anthropic described an agent back in December 2024 as “just LLMs using tools based on environmental feedback in a loop.” What changed in 2026 is that this outer loop became something you design deliberately, with its own techniques and failure modes. The term was named and popularised in mid-2026 by several practitioners at once, including Osmani and engineers behind Anthropic’s Claude Code and OpenAI’s Codex.

How does an agent loop actually work?

There are two loops, and loop engineering is about the outer one. The inner loop is a single agent turn: it acts, observes, evaluates and corrects. The agent takes an action, usually a tool call such as running a test or editing a file. It observes the result, which Anthropic calls gaining “ground truth” from the environment. It evaluates that against the goal, then corrects by choosing the next action. This is the cycle the 2022 ReAct paper (Yao et al.) formalised as Thought, Action, Observation: the model reasons about the state, acts on the environment, and the tool’s return value becomes the observation that feeds the next step.

Loop engineering wraps a second, outer loop around that whole cycle and repeats it across many runs toward a goal, until a stopping condition is met. Geoffrey Huntley’s “Ralph” technique from July 2025 is the plainest example of the outer loop laid bare. It is a Bash loop, in his exact words while :; do cat PROMPT.md | claude-code ; done, that feeds the same prompt file to a coding agent over and over. Each pass does one task, starts with a fresh context window, and leaves its progress on disk, in the code, a to-do file and git history, rather than in the conversation. The inner cycle is the agent’s own reasoning; the outer loop is what the engineer designs around it. Confusing the two is the fastest way to misunderstand the term.

How is it different from prompt, context and harness engineering?

They are four layers of the same stack, and loop engineering sits on top. Osmani lays them out in order. Prompt engineering is the wording of a single instruction. Context engineering is what information enters the model’s window on a given turn and what is left out. Harness engineering is the tools the agent can reach and the criteria that tell it when it has succeeded. Loop engineering is the autonomous repetition wrapped around all of that: how the agent iterates without a human in the seat, and how that repetition is bounded and checked. Each layer assumes the ones below it work. You cannot engineer a reliable loop on top of a context window that is already overflowing, which is why teams tend to hit context problems before loop problems.

What techniques make loops reliable?

The single most repeated rule across the sources is that an agent cannot reliably grade its own work. The fix is to separate the maker from the verifier: one agent writes, a second agent with different instructions checks the output against a rubric, and only a passing result moves on. LangChain describes this as a verification loop wrapped around the agent loop. AI Agents Simplified frames the whole system as five moves, discovery, handoff, verification, persistence and scheduling, with verification done by an independent evaluator. A handful of techniques recur:

  • Separate evaluator: a second agent, not the builder, decides whether the work is done. Self-grading is the most common mistake.
  • Explicit stopping conditions: a verifiable goal and a hard cap on iterations, so the loop ends on success or on a limit rather than running forever. Anthropic recommends a maximum number of iterations as a basic guardrail.
  • Fresh context each pass: Huntley starts every iteration with a clean context window, because “the more you use the context window, the worse the outcomes you’ll get.” Long sessions drift; short ones stay sharp.
  • External state: progress is written to files, a to-do list or an issue tracker, not held in the conversation, because the model loses its memory between runs.
  • Isolation: agents work in separate worktrees or sandboxes so parallel runs do not collide, and so a bad run can be thrown away.

Where do loops fail?

Loops fail in ways a single prompt never could, because they run unattended and compound their own mistakes. Anthropic warns plainly about “higher costs, and the potential for compounding errors,” which is why it advises sandboxed testing and guardrails before letting an agent run free. The failure modes cluster into a few kinds. Runaway cost is the loudest. An agent left looping without a hard cap runs up token bills fast. Hallucinated success is the more dangerous one: an agent that grades its own work will confidently declare a broken result finished, then ship it on a schedule. Drift is the quietest failure of all, the agent wandering off the goal a little at a time over many iterations. Huntley is honest that even a working loop means “you’ll wake up to a broken code base that doesn’t compile from time to time.”

Osmani adds two failure modes that have nothing to do with the model. Comprehension debt is code that ships without any engineer understanding it. Cognitive surrender is the habit of accepting whatever the agent produces without judgement. Both grow silently the more you trust the loop.

Loop engineering in practice

In practice a loop is started one of two ways: by an event or on a schedule. An event trigger fires the loop off something happening, a failing CI run, a new support ticket or an error in production, and the agent opens a pull request or triages the issue. A scheduled loop, a cron job, runs on a timer for repeatable work such as a nightly pass over end-to-end tests or a daily round of small fixes. Osmani describes exactly this split between scheduled automations that discover and triage work and event-driven runs. The pattern practitioners recommend is to give the agent a methodology rather than a single task, and let the methodology be the loop. Tooling has caught up fast: through 2026, Claude Code and other harnesses added built-in /loop and /goal commands that turn what used to be a hand-written Bash loop into a single instruction.

Is loop engineering here to stay?

That is an open question, and nobody knows the answer yet. The term is only months old and the practice it describes is moving quickly. One thing in doubt is whether hand-building loops stays a distinct skill at all. Through 2026 harnesses such as Claude Code folded the loop into built-in /loop and /goal commands, so the plumbing may disappear into the tooling and leave only the judgement behind: what to verify, when to stop, what to trust. The origin of the name is contested too. It surfaced near-simultaneously in mid-2026 from several practitioners, and rests on older foundations in ReAct (2022) and Anthropic’s agent-loop framing (2024). Underneath the uncertainty, the shift itself is real: from writing instructions to designing the systems that write them.

Frequently asked questions

Is loop engineering the same as building an AI agent?

Not quite. Building an agent gives a model tools and lets it run one task to completion, which is the inner loop of a single turn. Loop engineering is the outer design around that: how the agent repeats without a human prompting each turn, how its output is verified, when it stops and how cost and risk are bounded. You can build a capable agent and still have an unreliable loop, and the loop is usually where unattended agents break.

How is loop engineering different from context engineering?

Context engineering decides what information the model sees on a given turn. Loop engineering decides how the agent iterates across many turns without you in the seat. They are neighbouring layers of the same stack, and the loop sits above the context: a reliable loop assumes each pass has a clean, well-chosen context to work from. For teams not yet running unattended agents, context engineering is often the more immediately useful skill.

Do I need special tools to do loop engineering?

No. The original version, Geoffrey Huntley’s “Ralph” technique, was a one-line Bash loop feeding a prompt file to a coding agent. Modern harnesses such as Claude Code now ship loop and goal commands that do the job for you, but the tooling was never the hard part. The design is: deciding the goal, the verification step and the stopping condition.

Why can’t an agent just check its own work?

Because it is unreliable at it. Across the sources the most repeated rule is that an agent grading itself tends to declare mediocre or broken output finished, then ship it, especially on an automated schedule. The standard fix is to hand grading to a different agent: a separate evaluator with its own instructions checks the result against a rubric, and only a pass moves forward.

What is the biggest risk of running agents in a loop?

Two risks stand out. Cost, because an unbounded loop can rack up a large token bill, which is why hard iteration caps matter. And hallucinated success, where an agent confidently ships a wrong result unattended. Both are contained by the same handful of techniques: a separate evaluator, explicit stopping conditions, sandboxed isolation and a human checking in at intervals rather than trusting the loop blind.

Sources

Otto Sunnari, Sales and partnerships at Sofokus

Ready to start leveraging AI?

Call, email, or book a time straight from my calendar.

Otto Sunnari

Sales and partnerships