Stop conditions, budgets and human in the loop

Why it matters

The loop ends when something stops it, and nothing stops it by default. An agent that cannot finish a task does not fail; it keeps going, calling the same tool with slightly different arguments, until a bill or a timeout intervenes. The second half of the definition of an agent, the stop condition, is where most production incidents live, and the human gate is where most of the trust does. Interviewers ask about stopping because it separates candidates who have run agents from those who have only read about them.

The idea

The six ways to end

Every loop needs more than one exit, because each catches a different failure. Task done: the model returns a final answer instead of a tool call, or a check in code confirms a condition (the tests pass, the record exists). Prefer the check wherever you can write one; a model declaring victory is a claim, not evidence. Step limit: a cap on laps, set from the task's expected length with headroom, perhaps three times the median. Token or cost budget: a ceiling on tokens spent across the whole run, which catches the case where few laps each carry a huge context. Wall-clock timeout: a deadline, because a tool that hangs spends time without spending tokens. Error limit: a cap on consecutive tool failures, which stops the model retrying a broken tool forever. A human stops it: a cancel button or a reviewer's rejection, which must work at any lap.

Progress checks

Limits catch runaway runs late; progress checks catch them early. Two are cheap and effective. If the model calls the same tool with the same arguments twice, it learned nothing from the first result, and the runtime should intervene: return an error saying so, or stop. If a lap adds no new information, because the result was empty or duplicates something already in context, count it; three in a row is wandering. These checks turn a 40-lap failure into a 6-lap one.

Human-in-the-loop gates

Some actions must not be taken on the model's say-so. The gate is a check in the runtime, between the tool request and its execution, that pauses and asks. Three placements cover most systems. Confirm before irreversible actions: sending, paying, deleting, deploying; the user sees exactly what will happen and approves it. Approve a plan before execution: for plan-and-execute agents, the plan is the artefact a human reviews, which is cheaper than reviewing every step. Escalate on low confidence: when the model says it is unsure, when a check fails twice, or when the budget is nearly spent, hand the run to a person with its context attached. The gate's rule is decided in code, by tool name and by argument, never by asking the model whether it feels sure.

Designing the pause

A gate that blocks a thread for an hour while a reviewer has lunch is not a gate; it is a leak. The pause has to be a saved state: the conversation so far, the pending tool call, the budget spent, and an identifier, written to durable storage so the run can resume on another process, another day, after approval. The Memory and state lessons cover the storage; stopping and pausing are the same operation with a different flag, and both must leave the run resumable or explicable.

What to log when it stops

Every exit writes the same record: which condition fired, the lap count, tokens and cost, elapsed time, the last tool call and its result, and the final state. The ratio of clean exits to budget exits is the health metric of the agent, and the distribution of lap counts tells you whether the step limit is set right. Without this log, an agent that quietly hits its budget on a fifth of runs looks like one that works.

	Step limit	Cost budget	Progress check	Human gate
What it catches	Runs that go on too long	Runs whose laps are few but huge	Wandering, early	Wrong irreversible actions
Cost	Nothing; a counter	Nothing; a token sum	A comparison per lap	A person's time and a queue
User experience	A late, blunt failure	A late, blunt failure	An early, explicable stop	A pause, then certainty