For a few years, “prompt engineering” was the buzzword — the craft of phrasing a request to get a better answer. In 2026 the conversation shifted to something new: loop engineering. If you’ve heard the phrase and wondered whether it’s substance or hype, here’s the honest breakdown. It builds directly on our guide to what AI agents are.
The one-sentence definition
Loop engineering is designing the system that prompts your AI agent — instead of typing each prompt by hand. The question changes from “what should I ask the model?” to “what system should I build so the agent finds the work, does it, verifies it, and remembers what it did — without me in the loop every turn?”
The term was popularized in mid-2026 by Addy Osmani (an engineering lead at Google Chrome), synthesizing ideas from Boris Cherny at Anthropic and others, and quickly made the rounds in the AI press.
Why it emerged now
The skill shifted because the tools got better. As coding agents became reliable enough for long-horizon work, the bottleneck moved. When an agent can run for an hour on its own, the scarce skill is no longer writing a clever prompt — it’s designing the system that keeps the agent productive, safe, and on-track across all those steps.
Think of it as the third rung of a ladder:
- Prompt engineering — craft one good instruction.
- Context engineering — assemble the right information for each call.
- Loop engineering — design the autonomous cycle that does both, repeatedly, until the job is done.
The anatomy of the loop
Stripped to its essence, an agent is “an LLM in a while-loop with tools.” The loop is:
assemble context → model reasons → act (call a tool) → observe the result → check if done → repeat.
That’s genuinely simple — you could write the core in a few lines. Which is exactly the point: the loop itself is easy; the engineering is everything around it.
What the engineering actually is
Loop engineering is the discipline of making that loop reliable. The real work sits around the while-loop:
- Context management. What goes into each model call, how history is summarized or trimmed, and what’s retrieved on demand — so the agent stays grounded without blowing the context window.
- Tools and permissions. Which actions the agent can take, with least-privilege access and sandboxing for anything risky (see LLM security & red teaming).
- Verification and stop conditions. How the loop decides a step succeeded, when to retry, and — critically — when to stop. This is the heart of it: an agent that can’t tell good work from bad will loop forever or ship garbage.
- Memory and storage. What the agent records so it (and the next run) can build on past work instead of starting cold.
- Delegation. When to spin up subagents for sub-tasks versus keeping one focused loop.
A concrete example: shipping a web-app feature
Say you want an AI agent to add “password reset” to your web app. Prompt engineering is you typing “write a password-reset endpoint” and reviewing each reply by hand. Loop engineering is building the harness that does the whole job and only comes back to you at the end:
while not done:
task = pick_next_task(backlog) # "Add password reset"
context = gather(repo, task, conventions) # auth module, user model, house style
plan = model.reason(context, task) # decide the steps
for step in plan:
result = run_tool(step) # edit files, run tests, run the build
context += observe(result) # feed the outcome back in
done = tests_pass() and build_ok() and typecheck_clean() # the stop condition
if not done:
model.reflect(failures) # fix, then loop again
open_pull_request() # deliver for human review — not merge
The loop is a dozen lines. The engineering is the parts that make it trustworthy on a real codebase:
- Context management: the agent can’t read your whole repo, so you retrieve just the auth module, the user model, and the project’s conventions — and summarize what earlier attempts already tried.
- Tools & permissions: it may edit files, run the test suite, and run the build — but it cannot deploy or merge to
main. A human approves the pull request. - Verification & stop condition: “done” means the new reset-flow tests pass, the app builds, typecheck is clean, and no existing tests broke. Without that check, the agent will happily “finish” with a broken endpoint.
- Memory: it records that approach X failed the email-token test, so it doesn’t loop back into the same dead end.
- Delegation: a subagent writes the tests while the main loop writes the feature.
You defined the loop and the checks once; the agent then adds the feature, self-corrects against real test failures, and hands you a reviewable PR — with no per-step prompting. That is loop engineering in practice.
The honest limits — and “loopmaxxing”
The trend comes with a healthy warning term: loopmaxxing — running agents in loops for their own sake, assuming more iterations always means better results. They don’t. Two realities keep loop engineering grounded:
- Reliability compounds badly. If each step is 90% reliable, a 10-step loop succeeds only about a third of the time. Long unsupervised loops accumulate errors, so verification isn’t optional — it’s the whole game. This is why evaluation matters more, not less, as loops get longer.
- A loop is only as good as its stop condition. Without a solid definition of “done” and a way to check it, an autonomous loop will happily burn tokens producing confident nonsense.
So loop engineering doesn’t remove human judgment — it moves it upstream, from supervising each step to designing the system and the checks that let the agent run safely on its own.
How to start
You don’t need a framework. Start with the smallest real loop: a clear goal, one or two good tools, and — before anything else — an automated check for “is this actually done and correct?” Get that verification right, add memory and permissions, and only then let the loop run longer. Build the check first; extend the leash second.
The honest bottom line
Loop engineering is a real shift, not just a rebrand: as agents grew capable of long-horizon work, the leverage moved from the quality of a single prompt to the design of the system that generates and verifies them. It’s powerful — and it’s easy to overdo. The engineers winning with it are the ones obsessed with verification and stop conditions, not the ones chasing the longest autonomous run. For the interview-ready view of the agents underneath, see our AI agents interview questions, and start from prompt engineering basics if you’re building up the ladder.