Agent Loops and Stopping Conditions: Teaching an Agent When to Quit

An agent is a loop. It looks at the situation, decides on an action, takes it, and looks again. That loop is what makes it capable of multi-step work, and it is also what makes it dangerous when it goes wrong, because a loop that does not end keeps going.

Most of the attention in agent design goes to what the agent can do. Far less goes to when it should stop. Yet a good stopping rule is often the difference between a system you can leave running and one you have to watch.

Why agents do not stop on their own

A language model decides what to do next from the text in front of it. It has no built-in sense of how long it has been working, how much it has spent, or whether it is making progress. If the last result looks like it needs a follow-up, it will tend to take one.

That produces the familiar failure shapes. The agent repeats the same failing action, convinced that one more attempt will work. It wanders, taking steps that look related but get no closer to the goal. It second-guesses a correct result and keeps refining it. Or it gets stuck in a back-and-forth with a tool that keeps returning the same error.

None of these are crashes. They are expensive, quiet loops, and the longer they run the more context the agent carries and the worse its decisions tend to get.

Hard limits are the foundation

The first layer is a set of limits enforced outside the model, in the code that runs the loop. A maximum number of steps, a maximum spend, and a maximum elapsed time. When any one is reached, the loop ends, whatever the agent was about to do.

These limits are blunt on purpose. They do not depend on the model behaving well, which is exactly why they work. They convert an unbounded risk into a bounded one, and the worst case for any single task becomes a number you chose in advance. This is one of the four constraints in AI agent guardrails, and the spending side is covered in AI agent cost control.

Detect lack of progress

Limits catch the worst cases late. Better to notice sooner that the agent is going nowhere.

Several signals are cheap to track. Repeated identical tool calls with identical arguments. The same error returned several times in a row. A goal state that has not changed across several steps. A growing context with no new information. When these appear, the right response is not to let the loop run out its clock. It is to intervene.

The intervention can be graduated: first nudge the agent with a note that it appears to be repeating itself, then force a change of approach, then stop and escalate. Which you choose depends on the stakes, but the key is that a pattern of non-progress triggers something, rather than being noticed only after the fact.

Define what “done” looks like

Agents often stop badly because the task was never defined well enough to know when it was finished. A request like “research this topic” has no natural end. A request like “find three suppliers meeting these criteria and return their contact details” does.

Where possible, give the agent a concrete completion condition and, better, check it in code. If the task produces a structured result, validate it: are all required fields present and sensible? Passing that check is a much sounder basis for stopping than the model’s own feeling that it is done, and it connects to the schema discipline in generating into a schema.

Know when to give up gracefully

Stopping is not only for runaway loops. Sometimes the correct outcome is that the agent cannot complete the task, and it should say so clearly.

An agent that quits with a clear explanation of what it tried, what blocked it, and what it needs is far more useful than one that either loops indefinitely or reports success it has not achieved. Build this in as a first-class outcome: complete, partially complete, or unable, each with a reason. Honest failure is cheap to handle. Silent failure is not.

Escalate to a person at the right moments

Some stopping conditions should hand control to a human instead of simply ending. Hitting a limit, repeated failure, low confidence, a request outside the agent’s authority, or an action with significant consequences are all natural escalation points.

The escalation should carry context: the goal, what has happened so far, and the specific decision or problem. That makes it a handoff, not a dead end, and it is the same discipline as in human-in-the-loop AI agents. Where the agent can pause and resume rather than start over, the person’s answer lets it continue from where it stopped.

Make stopping visible

Every stop should be recorded with its reason: limit reached, no progress detected, task complete, escalated, or failed. Those reasons are valuable data. A rising share of runs hitting their step limit points to a problem, perhaps a mis-scoped task, a failing tool, or a change in the inputs. Tracing and logging, as described in agent observability, let you see why each run ended, not just that it did.

Tune the limits with evidence

Setting the numbers is a judgement call. Too tight and the agent cuts off legitimate work. Too loose and the protection is meaningless. Look at the distribution of steps and cost for successful runs, and set the limit comfortably above the normal range but well below the runaway range. Revisit it as the agent and its tasks change.

When a simple loop is enough

A short, tightly scoped agent that makes a few predictable calls does not need elaborate progress detection. A simple step cap and a timeout will do. The sophistication should grow with the length and autonomy of the task, but the habit of deciding in advance when the agent must stop should apply to every agent you build.

We build agents that know when to stop. See how we approach agent work, or read about why agents fail in production.