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

**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.