What Is Loop Engineering? A Complete Guide for the AI Agent Era
Loop Engineering, coined by Addy Osmani in June 2026, replaces the person prompting an AI agent with a system that finds work, assigns it, verifies results, logs progress and decides what runs next.
From Prompt Engineering to Loop Engineering: The Third Shift in Where the Work Sits
From 2021 to 2023 the industry was fixated on Prompt Engineering: how to word a single instruction well enough that the model returned something usable on the first try. In February 2025 Andrej Karpathy coined vibe coding, and engineers grew comfortable letting AI write the first draft while they handled the cleanup. That phase looked a lot like babysitting: the AI did the work, a human hovered the entire time, ready to step in and tidy up. In June 2026 Addy Osmani published his essay "Loop Engineering," and Andrew Ng soon called it the buzzphrase of the moment. As agentic coding tools such as Claude Code and Codex became part of the daily routine, Loop Engineering spread quickly through developer communities. One caveat worth stating up front: these three are ways of working that stack on top of each other, not eras that replace one another by year.
The logic behind the shift is direct. The cost of generating one round of code keeps falling, but running an agent around a loop repeatedly multiplies token spend, tool calls and human review all at once. The scarce resource has therefore moved from being able to produce code to designing loops that stay reliable inside a finite budget. Hold the model constant and the tooling, context management, verification method and stopping conditions still visibly move the outcome; model capability and loop design are two variables of equal weight.
What Is Loop Engineering?
Addy Osmani, who coined the term, gave a definition that is hard to improve on: loop engineering means taking the person who keeps prompting the agent out of the seat, and designing a system to do that job instead. That system finds the work waiting to be done, hands it to the agent, checks the result, records progress, and then decides what comes next. In practice it has to make six things explicit: what triggers a run, what the goal is, which tools are permitted, how results get verified, when to stop, and where state is kept.
It replaces the expectation that AI must get it right in one shot with an engineering structure in which AI converges on correct inside a loop you designed.
Put in everyday terms: Loop Engineering moves you out of the babysitter's chair and into the coach's. A coach does not run the laps for the athlete. A coach writes the training plan, sets the standard for passing, and lets the athlete get stronger through rounds of practice and feedback. You stop watching every step the AI takes and start watching whether the drills are designed correctly.
A single prompt is a coin flip: you throw the requirement at the model and hope the output is usable. A loop is a system with a feedback controller attached: every round of output gets tested (run the tests, compile it, check it against the spec) and the result of that test feeds back into the agent as the next round's input. The model will make mistakes, and that is fine. What matters is whether the loop catches those mistakes and corrects them.
Andrew Ng's Three Nested Loops
Andrew Ng has described the three key loops he relies on when taking a product from zero to one. They connect to one another and run at different speeds, and they are easiest to picture as three layers working from the inside out:
- Agentic Coding Loop (a turn every few minutes): run by the AI agent itself: write code, run tests, read the results, correct, repeat until it meets the spec. When the spec, the tests and the permission boundaries are all clear enough, this layer can sharply reduce step-by-step human intervention; high risk operations should still keep an approval gate or a stopping condition.
- Developer Feedback Loop (tens of minutes to hours): run by the engineer: review what the agent produced, correct the direction, update the spec. The engineer's role shifts from the person writing the code to the person driving the loop.
- External Feedback Loop (hours to days or weeks): run by the real world: test users, A/B experiments and production data after launch, all feeding back into product direction.
The three layers work the way a restaurant does. The line cook working the kitchen to a set procedure and checking their own plates is the inner layer. The head chef walking the pass, tasting, adjusting the recipe is the middle layer. Word of mouth and the reservation book deciding where the menu goes next is the outer layer. The difference in speed between the layers is exactly what tells you where work belongs: anything that can be verified automatically goes to the fastest inner loop, anything that needs human judgment sits in the middle, anything that only the market can answer belongs on the outside. The loop engineer's job is to decide which layer each piece of work goes into, and how the verifier for each layer is designed.
Four Common Loop Patterns
In practice, loop design has settled into a handful of reusable shapes. The four below follow MindStudio's write-up, and each suits a different kind of task. Worth saying plainly: the naming is not consistent across frameworks, and this is not a formal standard.
- Retry: the simplest form. On failure, go again carrying the error message. It suits tasks with an unambiguous success test, such as compiling code or validating a format. Always set a retry ceiling and a "stop if there is no progress" condition, because retrying an unchanged attempt forever only burns budget.
- Plan-Execute-Verify: have the agent produce a plan, execute it step by step, and verify each step. It suits complex multi-step work, such as building a data pipeline.
- Explore-Narrow: try several directions in parallel, then let a judging mechanism converge on the best one. It suits problems with a wide solution space, such as architecture design or copywriting.
- Human-in-the-Loop: place human review gates at the decisive points. Agents walk into dead ends, misread constraints, or hit questions that need domain judgment; a well designed loop lets a person pause the run, correct course and add context without starting the whole thing over. That requires the system itself to persist execution state, and not every tool ships with that capability.
A concrete example: suppose you want an agent to produce a monthly social listening report. Retry rewrites the report automatically when a required section is missing. Plan-Execute-Verify lays out four steps first (pull the data, compute share of voice, write the summary, generate the charts) and checks after each one that the artifact exists and is correctly formatted. Explore-Narrow can have three agents each write a version of the summary, then let a judge model pick the strongest. Human-in-the-Loop puts an analyst review gate in front of anything that goes to the client. One workflow can use several of these at once: plan first, allow a bounded number of retries per step, and require human sign-off before anything leaves the building. Note that this kind of combination is a different thing from Andrew Ng's three loops above: these are design techniques inside a single workflow, while his are three rhythms of feedback across product development.
Why Enterprises Should Understand Loop Engineering Now
This is more than a new piece of developer slang. It carries three direct implications for any enterprise adopting AI:
1. When evaluating AI tools, look at the loop, not the model
Two products running the same model can deliver wildly different experiences, and the difference is the loop. Is there automatic verification? How do errors feed back? Is the interface for human intervention any good? Loop design belongs on the evaluation checklist during vendor selection, not just benchmark scores.
2. For internal automation, start with the verifiable tasks
A loop needs a verifier before it can run at all. Is the report format correct, do the numbers add up, does the document contain every required field: tasks with an unambiguous test are the right first candidates for an agentic loop. Tasks whose criteria are fuzzy, strategic judgment being the obvious case, should keep a human in the loop.
3. Knowledge has to flow back, so the next loop does not start from zero
Every error, correction and decision context a loop produces is valuable organizational knowledge. If that context is scattered across chat transcripts, every run begins from nothing. If it is distilled into a curated, version controlled knowledge base, later loops can reuse the context that already exists. To be precise about what this buys you: it improves the context the AI can reach, not the intelligence of the model itself, and storing errors and stale decisions without curation will actively pollute later judgment. This is the new role enterprise knowledge systems play in the agentic era (platforms such as RAGi, an enterprise RAG platform): not only answering employee questions, but serving as the place an AI loop reaches for long term context. Capturing meeting and decision context (with tools such as AIMochi) does the same for the human layer of the loop, so the judgment calls people make are recorded and passed on.
It is worth noting that more automation is not automatically better. In regulated settings such as financial services and the public sector, whether every individual case must be approved by a human depends on the specific use case, the risk level and the regulations that apply. Even where case-by-case review is not required, you generally still need a clear division of responsibility and an auditable record: who approved what, and on the basis of which information. That is why loop infrastructure inside an enterprise has to solve automation and traceability at the same time: every round's inputs, outputs and human decisions should be replayable the way version controlled code is. Without that layer, the larger agentic automation grows, the larger the governance risk grows with it.
Where to Start, by Role
- Engineers: practice splitting your work into two piles, what can be verified automatically and what needs human judgment. Design the first pile into loops and hand them to agents; put your own attention into reviewing the second. Your value is moving from writing code to designing and driving loops.
- Engineering leaders: revisit your team's Definition of Done. If you want a loop to finish unattended, write the success conditions in a machine verifiable form wherever you can; where subjective judgment or high risk decisions are involved, a Definition of Done can perfectly well include a human approval step.
- Business decision makers: the center of gravity for AI investment is shifting from buying the strongest model to building loop infrastructure that can verify, feed back and accumulate knowledge. Start by taking inventory of which processes already have unambiguous criteria, and begin there.
Closing Thoughts
Prompt Engineering taught us how to talk to AI. Loop Engineering teaches us how to work alongside it. As model capability keeps improving and token costs keep falling, the real differentiator between companies, and between engineers, will sit in the design of the loop: how rigorous the verifier is, whether humans step in at the right moments, whether knowledge settles back into the system. For enterprises, what it takes to "be good with AI" is widening as well: beyond writing prompts, you need to design verification, set stopping conditions, manage permissions, and make knowledge flow back into the next loop.
References: Addy Osmani: Loop Engineering, Andrew Ng on his three key loops, MindStudio: What Is Loop Engineering?, The Agentic Loop: A Practical Field Guide, Loop Engineering Guide (2026)