What Is Loop Engineering? How Designing Agent Loops Replaces Prompting

If you have ever re-typed the same instructions into an AI coding agent for the fifth time in a morning, you already know the problem loop engineering is trying to fix. You are the bottleneck, not the model.

Loop engineering is the practice of designing a system that prompts your agent for you, instead of you doing it turn by turn. The term is new, but the pain that produced it is not: agents got good enough to do the work, and the manual back-and-forth became the slow part.

TL;DR: Loop engineering means designing the system that prompts your AI agent instead of prompting it yourself each time. Addy Osmani named it in June 2026: you define a goal, and a loop of automations, tools, and checks runs until the work is done and verified.

What loop engineering actually means

Loop engineering is the design of the system that prompts an AI agent, rather than the act of prompting it yourself. Developer Addy Osmani gave the practice its name in a June 2026 essay, later republished by O’Reilly Radar.

His own words: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

He adds a second line that is easy to miss but does most of the defining work: “A loop here can be thought of as a recursive goal where you define a purpose and the AI iterates until complete.” That second sentence is the part that separates a real loop from a long agent session.

Read plainly, both lines together mean you stop writing individual prompts and start writing the rules for what happens next. You set a goal once. The system figures out the steps, does them, checks its own output, and decides whether to continue or stop.

That last part, checking its own output, is what separates a loop from an agent that just runs longer. A loop without a check is not one worth running. It is a program that keeps going regardless of whether it is right.

Where the term came from

Correct attribution matters here because the term is genuinely new and gets misquoted often. Addy Osmani published the original essay on his own blog on June 7, 2026. O’Reilly Radar republished it on June 22, with O’Reilly’s own page confirming it as a syndication of the original, posted with his permission.

Developer Peter Steinberger compressed it into one line around the same time: you shouldn’t be prompting coding agents anymore, you should be designing loops that prompt your agents. That sentence is a fair summary, not a separate definition. The original essay is still the source to cite.

Osmani’s essay also names several related ideas without treating them as synonyms for loop engineering itself: agent harness engineering, intent debt, comprehension debt, and what he calls cognitive surrender, the risk of losing track of what your own loop is doing. Each of those is a distinct concern worth its own explanation, not a rebrand of the same term.

If you want the harness side of that picture specifically, a bloated coding-agent harness has its own costs, separate from how well the loop around it is designed, and it is worth keeping the two apart.

How a loop is different from one prompt

A single prompt is a request and a response. You type an instruction, the model answers, and the interaction ends. If the answer is wrong, you notice, and you type again.

A loop replaces that manual re-typing with a standing system. You state the goal once. The system then works through four repeating jobs: it finds the next piece of work, does it, checks whether the result is actually right, and decides what happens next, all without you typing a follow-up.

The practical difference shows up the moment something goes wrong. With a single prompt, a bad answer means you notice and correct it by hand. With a well-built loop, a bad result should trigger the loop’s own check, which either fixes it, retries it, or stops and flags it for you.

That is also why loop engineering is not the same claim as “just let the agent run longer.” A longer run with no check is still a single, unverified attempt. It is only a loop once discovery, action, and verification are all built in and repeat on their own.

Picture a queue of failing tests. With a single prompt, you paste in one failure, get a fix, run the suite, see the next failure, and paste that one in too. You repeat this by hand until the queue is empty.

A loop handles the same queue differently. It pulls the next failing test on its own, writes a fix, reruns the suite to check the fix actually worked, and moves to the next failure, only stopping when the queue is empty or it hits a case it cannot resolve.

The table above is the shortest way to see the shift: the work you used to do by hand (deciding the next step, catching mistakes) moves into the system you built once.

The parts that make a loop actually work

Osmani’s essay breaks a working loop into five pieces, plus one thing that ties them together across runs. None of the five is exotic. What matters is that they work together, not alone.

Automations turn a one-off run into an actual loop by scheduling when it starts and what it checks for. Worktrees give parallel runs their own isolated copy of the project, so two loops working at once do not step on each other.

Skills are the codified project knowledge, written down once, that keeps every run consistent instead of re-explaining context each time. A short file that states your coding conventions once does more for consistency than repeating the same instructions in every prompt.

Plugins and connectors are how the loop reaches real tools, often through the Model Context Protocol (MCP), rather than staying stuck inside a chat window. Sub-agents separate the work of creating something from the work of checking it, so the same agent is not grading its own homework.

The sixth piece, external state, is what makes the whole thing durable. A markdown file or a project board holds progress between runs, so a loop that stops halfway can pick back up instead of starting over.

What actually checks the loop’s work

The verification step is the part most explanations skip past, and it is the part that decides whether a loop is trustworthy. Something has to score the output and decide whether it is good enough to ship, retry, or hand to a person.

That scoring step does not have to be another slow, manual read-through. An evaluator that judges an output without needing a pre-written correct answer, sometimes called an LLM-as-judge evaluator, is what does the job in practice.

Tools built for this, like Future AGI’s evaluation platform, ship with 50+ ready-made checks. That gives the loop something concrete to test against, instead of just hoping the result looks right.

This is worth naming plainly, as our own position: the verification step is not optional. A loop that runs without one is not a loop worth running. It is an agent that keeps going, unchecked, until something breaks.

A good check looks past whether the output exists and asks whether it is actually right. For the failing-test example, that means confirming the specific test now passes, and the rest of the suite still does too, not just that the agent said “fixed” and moved on.

See how evaluation works in practice if you want the mechanics.

What loop engineering is not

It helps to say plainly what this term does not mean, since it gets stretched to cover almost anything involving an AI agent.

It is not the same as prompt engineering done more often. Prompt engineering is about the wording of one request, a practice covered in depth in Future AGI’s guide to prompt engineering. Loop engineering is about the system that decides when and what to request next, a different layer of the same work.

It is also not full autonomy with no human involved. Osmani’s own essay is explicit that verification, comprehension, and engineering judgment stay essential. A loop changes who does the repetitive work. It does not remove the need for someone to understand what the system is doing.

And it is not a single technique with one correct implementation. The five components above describe what tends to be present in a working loop, not a checklist you must complete exactly.

Whether the term names something genuinely new or repackages older orchestration ideas is itself a live, honest debate in developer forums. The debate is live and unsettled, and this is not the page that settles it.

Should you actually build one

A loop is worth the setup cost when the same kind of task repeats often enough that the manual prompting adds up. If you only need something done once, a loop is more system than the job requires.

The clearest signal is whether you can describe a stop condition in advance. If you can say exactly what “done” looks like, a loop can check for it. If “done” is a judgment call that changes every time, you are better off staying in the loop yourself.

If your task lands on the right side of that table more often than the left, the setup can pay for itself once the task repeats often enough. Building the loop is only half the job, though.

The test and cost gates that keep a loop honest matter as much as the loop itself. Future AGI’s guide to CI/CD for AI agents covers those gates in detail.

The check is the whole thing

Strip loop engineering back to one sentence and it is this: you stop writing the prompts and start writing the rules for what happens next. Osmani’s second line does the real defining work, a recursive goal you state once while the system iterates until it is complete.

The piece to hold onto is the verification step. Automations, worktrees, skills, connectors, and sub-agents are all ways of arranging the work. Take out the check and what you have left is an agent running unchecked, which is the failure mode loop engineering is supposed to design out.

That also gives you the honest test for whether to build one. Not “is this task complex enough” but “can I say in advance what done looks like.” If you can write that check, the loop has something to run against and the setup can pay back across repeats. If you cannot, no amount of scheduling or isolation will fix it, and you are still the right person to be judging each result.

So the term is new and the debate about it is real, but the practice underneath is narrow and testable. Define the goal, give the system a way to know it got there, and decide what happens when it did not.