Flashcard: why must every agent loop declare when to stop?

Attempt it

Your answer

**A stopping condition** is a rule that tells the agent runtime when to exit the loop. Without one, the loop can keep calling the model forever. Every working agent has at least one stopping condition, and most production agents have several layered together. The three canonical kinds are simple. The first is a final-answer signal from the model: the model emits a response with no tool calls in it, and the runtime treats that as the finished answer and exits. The second is a resource budget: the runtime caps the number of steps, the total tokens, the total cost, or the wall-clock time, and stops as soon as any cap is hit. The third is an unrecoverable error: a tool keeps failing, a service is down, an argument keeps failing validation, and the runtime decides further attempts are pointless. The key fact is that the model cannot enforce any of these on itself. Each model call is independent and the model has no view of the budget or the clock. Stopping conditions only work because the runtime owns them. Without stopping conditions you get runaway loops and surprise cost bills. With the wrong ones, agents give up too early and return half-finished answers. Tuning these limits is part of every real deployment.

**A stopping condition** tells the runtime when to exit the agent loop and return a final answer. Three canonical kinds, and a working agent uses all three at once. The first is a final-answer detection. When the model emits a response with no tool-use blocks, the runtime treats that as the finished answer and exits the loop. This is the happy path. Most well-behaved agent runs end this way after a handful of turns. The second is a resource budget. The runtime caps step count, total tokens, total dollar cost, or wall-clock time, and exits as soon as any cap is exceeded. The cap exists because the model cannot police itself: each call is stateless, and the model has no view of how many steps have already happened or how much they cost. Without a runtime-level budget, a confused or adversarial model can spin the loop into a runaway cost incident. The third is an unrecoverable error or stuck state. A tool that repeatedly fails, the same identical call retried four times in a row, or an exception the runtime cannot route back as an observation all signal that further iteration will not help. The runtime terminates and surfaces the failure rather than burning budget on the same failing step. Designing the right mix is a tradeoff. Loose caps let complex tasks finish but raise cost variance. Tight caps control cost but cut off legitimate long reasoning. Most production agents pick conservative caps and instrument both directions to find the right setting empirically.

Quick reference

TL;DR

A stopping condition is the rule that exits the agent loop: final-answer from the model, budget exhaustion (steps, tokens, cost, time), or unrecoverable error. The runtime enforces it; the model cannot police itself.

Memory aid

Easy to grasp

Imagine handing a very eager intern an unlimited stack of work and saying 'just keep going.' Without a clear rule for when to stop, they will work forever, or until they fall over. Agents have the same problem. The LLM can always think of one more tool to call, one more lookup to try, one more refinement. Stopping conditions are the rules the runtime uses to say 'okay, that is enough.' Sometimes the rule is positive (the model produced a finished answer). Sometimes the rule is a budget (we have used twenty steps already). Sometimes the rule is an emergency brake (the same tool keeps failing). Without these rules, the loop can spin until the cost bill arrives. With the wrong rules, the agent gives up too early and hands back a half-done answer.

Key concepts

Stopping Condition Agent Loop Step Budget

Detailed answer & concept explanation

~6 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

5 min: define stopping condition, list the three canonical kinds (final answer, budget, error), explain why the model cannot enforce its own budget, describe stuck-state detection as an extra layer, and note how partial answers should be surfaced.

Real-world examples

Real products, models, and research that use this idea.

LangGraph exposes a recursion_limit on graph execution; hitting it raises a GraphRecursionError that the caller has to handle, which makes runaway loops visible rather than silent.
The OpenAI Agents SDK lets you cap max_turns and timeouts on a run; both fire as explicit run-completion conditions you can inspect.
Anthropic computer-use deployments cap dollar spend per session because individual screen-driven runs can burn tokens fast at full resolution screenshots.
Cursor and Cline coding agents implement repeated identical action detection to break out when the model keeps proposing the same failing edit.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QHow do you decide a step budget for a new agent without overfitting to the demo task?

QWhat is stuck-state detection and why is it different from a step budget?

QWhen the budget fires before completion, what should the runtime return?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Relying on the model to know when to stop. The model has no view of the budget or the wall clock; the runtime is the only component that can enforce a stopping condition.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.