You gave the agent a task: fix the failing test. It read the file, thought for a moment, and wrote what looked like a reasonable patch. Then it asked: “Should I run the tests to confirm?” You said yes. It ran them. Still failing. It asked: “Should I try a different approach?” You said yes. It tried another approach. Still failing. Twenty minutes and fifteen manual replies later, the tests were still broken — and you had been doing all the work.
The agent wasn’t malfunctioning. The model was capable. The problem was structural: there was no loop. Every step required your input to continue. You weren’t supervising an autonomous agent. You were the agent.
This is the gap that loop engineering fills.
What is a loop, exactly?
A loop is the recurring cycle an agent runs through on its own: observe → reason → act → check → repeat. The agent doesn’t stop after one action and wait for applause. It keeps going — gathering feedback, deciding what to do next, taking another step — until some condition tells it to stop.
Think about how you actually debug code. You run the tests. You read the error. You form a hypothesis. You change something. You run the tests again. You do that on repeat until either the tests pass or you hit the wall and ask for help. That cycle is a loop. You run it automatically, without stopping to narrate each step or ask permission before the next one.
Loop engineering is the discipline of designing that cycle for an AI agent — specifying what it observes, how it decides, what it acts on, and crucially, when it stops. It is the difference between a model that responds and a model that works.
This is distinct from prompt engineering. Prompt engineering is about what you say to the model — the instructions, the framing, the examples. Loop engineering is about what the model does between your messages. One shapes the input. The other shapes the system.
Why this matters now
AI agents didn’t arrive fully formed. They evolved in layers, and each layer added something the previous one couldn’t provide.
The first layer was prompt engineering: the skill of phrasing your instructions so the model understood what you wanted. Write the right prompt, get the right output. Useful, but one-shot. The model gave you an answer, and the conversation was effectively over.
The second layer was context engineering: the skill of curating everything the model sees — documents, memory, prior turns, retrieved facts. A better context meant a smarter response. Still fundamentally reactive, but richer.
The third layer, arriving now, is loop engineering: the skill of designing the system that wraps the model. What does the agent do after it gets a response? Does it check its work? Does it try again? Does it call a tool, read the result, and decide what to do next? Does it know when it’s done? These questions live outside the model and outside the prompt. They live in the loop.
In June 2026, this shift crystallized publicly when a single post about agent infrastructure reached 6.5 million views in a matter of days. The terminology was new, but the underlying reality wasn’t: autonomous agents require designed iteration cycles to be useful. The field had just found its name.
The anatomy of a working loop
A loop that works reliably has four components. Get any of them wrong and the agent either stalls, spins, or quietly fails.
1. A termination condition. The loop needs to know when it’s done. This sounds obvious until you realize how often it’s skipped. Without a clear exit, the agent keeps going — trying variations, second-guessing its own work, burning tokens — until the context window fills up or the budget runs out. A working loop defines success upfront (the tests pass), defines failure upfront (three consecutive attempts without improvement), and exits cleanly in either case. No open-ended running.
2. Real feedback from the outside world. The agent needs to see actual results, not just its own reasoning. For code: run the tests and read the output — don’t just re-read the file and guess. For writing: count the words, check the structure, validate the format. The model’s internal sense of “I think this is correct” is unreliable. Feedback grounded in real execution is not. Good loops are built around deterministic checks: did the test pass? Did the schema validate? Is the file there? These questions have answers the model can observe, not just infer.
3. Context management. Each iteration adds information to what the agent holds in memory. After several rounds, that memory fills with noise: failed attempts, error messages, intermediate reasoning, outdated context. This is called context rot — the point where earlier information starts crowding out what matters now. A well-designed loop doesn’t just accumulate; it prunes. It summarizes old iterations, drops information that’s no longer relevant, and keeps the agent focused on the current state of the problem.
4. Error handling with intent. Not every failure is the same kind of failure. Some errors are recoverable — a syntax mistake, a wrong import, a bad variable name. The agent should catch these, adjust, and continue. Other errors are fatal — a missing API key, a file that doesn’t exist, a permission denied. Continuing past these doesn’t help; escalating does. A good loop design makes this distinction explicit. It knows when to try again and when to stop and ask.
A concrete example: the debugging loop
Consider what it looks like to give an AI agent a task with a bad loop versus a good one. The task is the same both times: fix a failing test suite in a Python service.
Without a loop, the session looks like this: the agent reads the test file, identifies what looks like the problem, and proposes a fix. It asks you to run the tests. You run them and paste the output back. The agent reads the output, proposes another adjustment. You run the tests again. Paste the output again. Forty minutes pass. Five or six exchanges. You’ve been running the tests, copying terminal output, and feeding it back into the conversation by hand. The agent was capable. You were the loop.
With a loop, the session looks different. You give the agent the task and walk away. The agent runs the tests itself and reads the output directly. It identifies the failing assertion, forms a hypothesis, modifies the code, and runs the tests again. It checks whether the failure count decreased. If it did, it continues in the same direction. If it didn’t, it revises its hypothesis. It tracks how many attempts it’s made. After five attempts with no progress, it stops, writes a summary of what it tried and where it got stuck, and pings you. You come back to a situation report — not a conversation that’s been waiting for you.
The model in both scenarios is identical. The prompt might even be identical. What changed is the loop: the system that decides what happens after each action, how results are read and interpreted, and when the agent stops expecting your help.
This is the core insight. A model’s quality sets the ceiling on what’s possible. The loop determines how close to that ceiling you actually get.
The three things that kill loops
Most agent failures aren’t model failures. They’re loop design failures. Three patterns show up repeatedly.
1. No termination condition. The loop has a start but no agreed-upon finish. The agent keeps refining, revisiting, improving indefinitely — because “done” was never defined. The fix is to decide before the loop starts: what specific, observable state counts as success? What counts as unrecoverable failure? Write those conditions down and build them in. If you can’t answer those questions, the agent can’t either.
2. The agent grading its own work. If you ask a model whether it succeeded, it will usually say yes. Not because it’s dishonest — because it genuinely can’t see what it can’t see. Self-assessment through the model is soft. Verification through the real world is hard. Run the test. Query the database. Check the HTTP response code. External, deterministic checks are the only reliable signal that a loop should exit with success.
3. Compounding errors. In a loop, each iteration builds on the previous one. A small wrong assumption in step two doesn’t stay small — it shapes every decision that follows. By step eight, you’re working from a corrupted foundation and the agent has no way to know it. Good loops include checkpoints: moments where the agent compares the current state against the expected state, catches drift early, and resets to a known-good position rather than continuing to build on a mistake.
Loop engineering isn’t a framework to install or a library to import. It’s a design discipline — the habit of asking what does this agent do between the steps before you write the first line of scaffolding. The prompt tells the agent what to want. The loop determines whether it can get there.
If you’re building anything that runs more than two actions in a row, you’re already in loop engineering territory — whether you’ve named it or not. Start there. Design the termination condition, the feedback mechanism, the error boundaries. Then write the prompt. The order matters more than it looks like it should.
AI Fluently covers practical AI patterns, model literacy, and builder stories for engineers shipping AI in production. Subscribe on Substack →