.png)
.webp)
.webp)
Introduction
For about two years, working with an AI coding agent meant one thing: you wrote a prompt, the agent did something, and you looked at the result and decided what to type next. That back-and-forth was the whole relationship. You were the loop. In mid-2026, a new phrase started showing up everywhere in AI engineering circles: loop engineering. The idea, in one line, is this: instead of being the person who repeatedly prompts an agent, you design a system that does the prompting for you, one that finds work, hands it to an agent, checks the result, and decides what happens next,
on its own. It's a genuinely useful shift to understand, but it's also a term that exploded in popularity fast enough that it means slightly different things depending on who you ask. This guide untangles what loop engineering actually is, where it came from, the two main frameworks people use to build one, and where it's genuinely useful versus where it's just added complexity dressed up as progress.
What Is Loop Engineering?
Loop engineering is the practice of designing an automated system that repeatedly prompts, checks, and redirects an AI agent, so that a human no longer has to manually drive each step. Rather than defining a single instruction and reacting to the output, you define a goal and a system that keeps working toward it, iterating on its own until the task is genuinely done. The shift is best understood as a change in role. With prompting, you are the operator: you type, you read, you type again. With loop engineering, you become the architect: you design the mechanism that does the operating, and you step back to supervise it at a higher level. This doesn't mean removing humans from the picture entirely. It means moving human judgment to the points where it actually matters, like reviewing a plan before it executes, approving a sensitive action, or deciding whether a system's overall behaviour needs to change, rather than approving every single step along the way.
Where the Term Came From
The phrase surfaced from a cluster of independent voices making the same observation around the same time in June 2026. Developer Peter Steinberger argued publicly that engineers should stop prompting coding agents by hand and instead design the loops that prompt those agents for them. Around the same week, Boris Cherny, who leads Claude Code at Anthropic, made a similar point: his own role had shifted from prompting the model directly to writing the loops that handle that prompting and decision-making on his behalf. Developer and writer Addy Osmani published an essay naming and structuring the idea shortly after, framing it as a recursive system: you define a purpose, and the AI iterates against that purpose until the work is complete. Around the same time, independent writer swyx described the same pattern as "loopcraft," and LangChain published its own take, framing reliable agents as a stack of layered loops rather than a singleone. By early July 2026, the concept had become a dominant topic at that year's AI Engineer World's Fair, complete with a live debate over whether the term describes something genuinely new or is simply repackaging practices experienced teams were already doing.
Prompting vs. Loop Engineering
The Five Building Blocks of a Loop
- Automations. A scheduling or triggering mechanism, so the loop runs on its own instead of waiting for a person to kick it off. This is what turns a single agent run into an ongoing process.
- Worktrees (isolation). When more than one agent instance works in the same codebase or system at once, they need separated working copies so their changes don't collide, the same problem two engineers editing the same file at once would create. A git worktree, a separate working directory sharing the same repo history, solves this by giving each agent its own isolated checkout.
- Skills. Reusable, codified project knowledge (often stored as structured instruction files) that gets handed to the agent so it doesn't have to rediscover the same context, conventions, or constraints every single run.
- Plugins and connectors. Integrations, commonly built on protocols like MCP (Model Context Protocol), that give the agent access to real tools: repositories, ticketing systems, databases, and other systems it needs to actually get work done.
- Subagents. A separate agent instance dedicated to checking the first agent's work, so the system verifying the output isn't the same system that produced it. This separation is what keeps "done" from just being the agent's own opinion of itself.
Some versions of this framework add a sixth element: memory, a way for the loop to retain what happened in previous cycles so it can improve rather than repeating the same mistakes indefinitely.
The Four-Loop Stack: How Loops Build on Each Other
A complementary way to think about loop engineering, popularized by the LangChain team, treats it as four loops stacked on top of each other, each one wrapping and strengthening the loop beneath it.
The most important detail in this model is where loop 4 points: its findings don't just restart the process from the top, they feed directly back into how the agent loop itself is configured. Each full cycle through all four loops is meant to leave the system a little more capable than it was before.
Loop Engineering vs. Prompt Engineering vs. Context Engineering
These three terms are often confused because they all involve getting better output from an AI model, but they operate at different levels:
- Prompt engineering is about wording a single instruction well, so one response comes back closer to what you wanted.
- Context engineering is about supplying the right surrounding information (codebase structure, past decisions, relevant documents) so the model has what it needs to reason accuratelyabout a given task.
- Loop engineering sits above both. It's about designing the system that decides when to prompt, what context to gather, how to check the result, and what to do next, repeatedly, without a person manually performing each of those steps.
You still need good prompts and good context inside a loop. Loop engineering doesn't replace those skills, it wraps a repeatable, self correcting system around them.
Real-World Examples
What a Loop-Engineered System Looks Like
Loop 1: The Agent Loop
Loop 2: Adding Verification
Loop 3: Making It Event-Driven
Loop 4: Hill Climbing, the Self-Improvement Layer
The Full Stack Together
Common Mistakes and Real Risks
- Treating "done" as proven, not claimed. An agent or a grader reporting success is a claim, not a guarantee. Loops still need real verification, tests passing, links resolving, output matching intent, or the system will confidently ship broken work at scale.
- Skipping the separate verifier. If the same agent that produced the work is also the one judging it, the check is far weaker. A genuinely useful verification loop uses an independent grader or subagent.
- Underestimating token and compute costs. Because a loop can run many cycles without a person pausing it, costs can varyfar more than they would with manual, one-off prompting. This needs monitoring, not assumptions.
- Removing humans from the wrong checkpoints. Full autonomy at every layer isn't the goal. Sensitive actions, financial transactions, database changes, anything hard to reverse, still benefit from a human checkpoint before execution.
- Confusing hype with maturity. The term itself is new, and much of the tooling supporting it is still evolving quickly. Teams should validate a loop's behaviour thoroughly in a low-risk setting before trusting it with high-stakes work.
- Letting understanding atrophy. If a system runs unattended long enough, it becomes tempting to stop reading its output closely. That's exactly when a quiet failure is most likely to go unnoticed.
Best Practices for Getting Started
- Start with loop 1 and loop 2 only. Get a basic agent loop working reliably, then add a genuine verification step, before reaching for event-driven or self-improving layers.
- Pick tasks with a clear definition of "done." Loops work best on categories of work where success is checkable, tests passing, a value matching a source of truth, rather than tasks that need pure subjective judgment.
- Keep the verifier separate from the generator. Whether that's a different model, a deterministic script, or a human, the check should never be performed by the same system that did the work.
- Log everything. The hill-climbing loop, and any future debugging, depends entirely on having a full record of what the agent did and why.
- Decide your human checkpoints up front, before building the loop, not after something goes wrong. Sensitive actions should require approval by design, not as an afterthought.
- Expect to revise the loop, not just the prompts. When something goes wrong repeatedly, the fix is often in the harness (the tools, structure, or grading criteria) rather than in wording a better instruction.
Is This Just a New Buzzword?
It's a fair question, and one the AI engineering community itself has openly debated. Much of what loop engineering describes, retry logic, scheduled jobs, automated testing, isn't new. What is genuinely new is the shift in mindset it names: treating the design of the surrounding system, not the wording of any single prompt, as the primary engineering task when working with capable AI agents. Whether "loop engineering" remains the accepted term a year from now or gets replaced by something else, the underlying practice it points to, building repeatable, checkable, self-correcting systems around AI agents instead of manually driving them one exchange at a time, is a real and useful shift for any team relying on agents for meaningful volumes of work.
Final Thoughts
Loop engineering names something real: as AI agents get more capable, the actual engineering work shifts from crafting the perfect prompt to designing the system around the agent, one that knows when to act, how to check itself, and how to get better over time. The specific term may or may not stick, but the shift it describes is worth understanding now, especially for any team weighing how much of a repeatable process to hand over to an agent, and exactly where a human still needs to stay in the loop.
