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

Flashcard·Easy·4.0 · 0·~30s·Asked atAi21 Jpmorgan Samsung·Relevant atAnthropic

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.

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

Concept explanation~2 min read

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

Stopping conditions are the boring half of the agent loop, which is why first-time agent builders skip them and end up with runaway cost incidents. The loop is the showy part; the stopping condition is what makes the loop safe.

This deep dive walks through what a stopping condition actually is, the three canonical kinds every working agent uses, why the model cannot enforce its own limits, how stuck-state detection complements resource budgets, and what robust runtimes do when a budget fires before the agent finishes. By the end, you should be able to read any agent codebase and immediately identify where stopping policy lives (or where it is missing).

Why a loop needs an exit

An agent loop is unbounded by default. On each turn the model decides whether to call another tool or emit a final answer. As long as the model keeps asking for tools, the loop keeps going. Nothing in the model's training guarantees it will ever stop on its own. A confused model can ask for the same lookup forever; an adversarial model directed by a prompt injection can deliberately spin.

This is fundamentally different from a normal function call. A normal call returns when its code path ends. An agent loop returns when something outside the model decides it should. That something is the stopping condition, and the runtime is the only place it can live.

Without a stopping condition, three failure modes show up immediately in any non-trivial deployment. Cost runs away: even a low per-call cost compounds across hundreds of turns. Latency explodes: an interactive use case is unusable if the loop runs for ninety seconds. State grows: each turn adds to the context window until the prompt no longer fits, at which point the SDK silently truncates and the agent loses track of what it was doing. Stopping conditions exist to make all three failure modes bounded.

Kind one: the final-answer signal

Kind two: resource budgets

Kind three: errors and stuck states

What to do when a stop fires before completion

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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.

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?

Measure the step distribution across a representative trace dataset and set the budget at a high percentile (p95 or p99) of successful runs. Instrument budget-hit rate so you can tune up or down based on real traffic.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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 bullets to scan on the way to the call.

Name the three canonical stopping condition kinds.
Explain why the model cannot enforce its own budget.

Primary sources. Browse if you want the original framing.