What Is an Agent Loop, Actually?

Iteration is not the failure mode. It is the mechanism.

An agent loop, sometimes called an agentic loop, is the iterative cycle an AI agent uses to work toward a goal: observe the current state, decide what to do, act, and verify what happened, until it reaches a clear, verifiable condition of success. In multi-agent systems, that same loop coordinates several specialized agents around a shared outcome. The part that matters is not the repetition. It is that every pass through the loop produces new information that brings the system closer to the expected result.

How does an agent loop work?

At its simplest, the loop is four steps:

• Observe: take in the current state and the result of the last action.
• Reason: decide what to do next.
• Act: use a tool, change something, or produce an output.
• Verify: check what happened and decide whether to stop or go around again.

This is closely related to the ReAct pattern: reason about the current state, take an action, observe the result, and feed that observation into the next decision. Anthropic's own engineering guide describes agents in similar terms, as models using tools based on environmental feedback in a loop.

Agent loop vs. workflow

Agent loop vs. workflow, by dimension. Path: a workflow is fixed in advance and runs the same every time, while an agent loop depends on what the last action produced. Next step: in a workflow it's wired, in a loop it's decided from the current result. Stops when: a workflow stops when the last step runs, a loop stops when a verifiable condition is met.

A loop does not end because an agent says "I'm done" or because it reached the fifth iteration. It ends because something observable changed.

In production software delivery, that same mechanism can extend across several specialized agents rather than one agent doing everything. That extension is where the interesting problems live, so it's where I'll spend the rest of this piece.

Most explanations of agent loops stop around there. In conversations with engineering leaders, and increasingly with the developers on their teams, the question I get is different and more practical:

"Why does the agent go around in circles instead of just getting it right the first time?"

It's a fair question. It also assumes something about how software gets built that was never true, even before AI. So let me start with what a loop looks like in real delivery, then get to the two things a loop has to know how to do for that question to have a good answer, and one architectural question that follows.

What does an agent loop look like in software delivery?

Take a simple flow, and map each step to a human role you already know. One agent takes a requirement and turns it into a spec with acceptance criteria, which is what a product manager or a tech lead does when refining a story. A builder implements that spec: that's the developer writing code. A QA agent tests the result against the criteria, the way a QA engineer would. If it finds gaps, a different agent fixes them, and an independent QA pass verifies again. A code reviewer or a security specialist can join if the change calls for it, the same way you'd pull another engineer into a review.

None of those agents is an isolated task. Together they form a machine that keeps moving and correcting itself until the exit condition is met.

Exit condition: every acceptance criterion passed an independent check and no blockers remain open.

The delivery loop described above. Each agent maps to a familiar human role. The loop exits on a verified condition, or escalates to a human owner when it stops converging.

The mapping to human roles is useful, with one important difference. A person on a team usually carries several of those responsibilities at once, and good people expand their scope over time. An agent works better the other way around. Think of it as a colleague with a deliberately narrow job description and no ambition to grow it. The tech lead who also reviews code, unblocks the client, and mentors juniors is a great hire. An agent that tries to do all of that is a worse agent.

This is how we've been building delivery at Rootstrap through our proprietary multi-agent system for software delivery. For us, it's where these ideas stopped being theory. We had to decide which agents participate, what each one owns, how work moves between them, what "done" actually means, and when the system has to hand something back to a person.

One thing became obvious quickly: narrow roles make specialists cheap to add. On a human team, adding a security or performance specialist means hiring them and getting time on their calendar. At Rootstrap, a security agent or a performance agent is a role we define once and plug into the loop whenever a change calls for it. The loop doesn't get heavier for everything else.

1. A good agent loop knows how to keep going

When you run an agent once, you tend to judge that execution as if it had to produce the right answer on the first try. A loop is designed differently from the start. It's built to converge over several iterations.

One of the biggest sources of resistance I see when developers start working with agents is judging the early iterations too harshly. "It got this wrong." "I would have done it faster." But software development was already incremental when humans did it, which is a big part of why software still takes time even in the age of AI. We design, implement, test, find problems, and correct. The first version is rarely the final one. Agents don't remove that iterative nature. What they do is automate a much larger share of the feedback and correction cycle.

On a project in the culinary space that we kicked off in August 2026, on an aggressive timeline, a four-developer core team shipped 43 user stories to production in a matter of weeks. Our System instruments every run: passes, corrections, blockers, and which agent touched what. Here is what the iteration itself looked like.

What iteration looked like in a real production project

Source: instrumented Rootstrap Delivery System production runs, August 2026. Client and project details withheld. What iteration looked like in that production project: 4 core developers, 43 user stories shipped, 92 product pull requests traceable to those stories, about 60% of application commits with explicit agent provenance, 285 instrumented runs analyzed, about 40% of runs needing at least one additional pass, and about 20% needing a second correction.

Two things in that table matter more than the raw volume. First, those four people kept final responsibility for delivery, but roughly 60% of application commits carried explicit agent provenance. The rest came from developers working with AI, outside an autonomous loop. Humans still own accountability. They are no longer the only actors producing, reviewing, and verifying the work, which changes what a code review is for: checking that the verification was sound, not re-reading every line.

Second, iteration was routine, not exceptional: about 40% of measured runs needed at least one correction, and around half of those went through a second. The pattern held in the weeks with full instrumentation, so it isn't an artifact of partial logging early on.

I don't read those numbers as a productivity metric, and that's not why I'm sharing them. I read them as evidence that iteration is a normal part of the convergence mechanism. The question is not "did the agent make a mistake?" but "did the system detect it, react correctly, and converge on the expected result?" If you evaluate an intermediate iteration on its own, you're doing the equivalent of looking at a pull request halfway through development and concluding the team can't build software.

2. A good agent loop knows when it stopped making progress

Retry, on its own, is not a strategy. A first correction can bring new information. So can a second. But when the same problem keeps coming back, continuing to try stops being a sign of autonomy and becomes a sign that you're attacking the wrong layer of the problem.

We had an illustrative case on that same project. Over seven days there were ten runs around a single story. One of them reached eight bounces (a bounce,in our agentic system, is a pass that sends work back to the previous agent), and in one session there were nine review passes with four blockers. The system got something right: it correctly identified that the problem was in the spec, not in the code, and it never handed the story to a builder agent to start writing code. What it got wrong was continuing to iterate on the spec when the real blocker was a product question nobody had asked the client yet. No additional pass over that document could invent that information.

The lesson was concrete. Detecting the right layer of the problem isn't enough. The system also has to detect when no further iteration on that layer can produce new information.

There are more operational versions of the same failure. An agent can still be active but stuck too long on the same step. Two runs can be trying to modify the same target. A loop can be paused waiting for a human action nobody saw. So it's not enough to check whether the system is "still alive." We need to distinguish activity from progress.

In some loops we use a concrete bounce limit before escalating to the human owner. The exact number matters less than two things: that the limit exists, and that the exit is something other than "try again." Once you've stopped generating new information, the next step might be revising the spec, getting a decision, changing the approach, or abandoning that run and reframing it.

When should you not run an agent loop?

An explicit rule in our system is to use the least machinery that solves the problem well. A perfectly valid criticism of some agentic workflows is that they're a huge weapon for a small problem, or that the loop ends up taking longer than doing the task the conventional way. Sometimes that criticism is exactly right: someone chose a loop for a task that didn't need one. Over-investing in trivial work is a design defect, the same way running short on controls in a complex problem is.

There's a second case I find just as interesting. Sometimes the loop looks slow because the human steps in too early, interrupts each iteration, and ends up doing by hand the tasks that should have been part of the larger agentic flow. Then you pay the cost of the loop and the cost of the human work at the same time. That's also a reasonable moment to ask what the loop is for.

The choice has to start from the problem, not from how agentic you want to look. This is also how Anthropic frames it in the Claude Certified Architect Foundations certification: start with the simplest architecture that solves the problem well, and add workflows, agents, or multi-agent coordination only when they earn their place. If you're building with agents seriously, I'd recommend it: a proctored, scenario-based exam about architecture tradeoffs, and several engineers on our team have taken it.

Even with that routing codified in the system, human judgment still pays off. Someone who understands the problem can tell the system up front that a task doesn't need the full loop, or that it needs more controls than usual. We learned the same thing driving AI IDE adoption across our teams: the tool doesn't decide where it applies, people do. The system gets better at that call with every run. A person who knows the domain gets it there faster.

The specific design patterns behind those choices, and what we tried and walked back, are the subject of a later piece in this series.

What the loop is actually for

Model capability matters, but much of the differentiation does not come from exclusive access to a model. It comes from the system built around it.

• A loop ends on a verifiable condition, not on the agent's say-so or an iteration count.
• Iteration is normal. Judge whether the system detected and corrected, not whether pass one was right.
• Activity is not progress. When passes stop producing new information, the exit is escalation, not another retry.
• Use the least machinery that solves the problem. A loop has to earn its place.

An agent loop isn't a way to keep agents from making mistakes. It's a way to make sure the system notices when they do. And that’s what we built at Rootstrap.

There's one more thing a good loop has to know how to do: what to do when it hits a decision nobody made. That one deserves its own piece.