What ends a ReAct loop, and which stop conditions can the model itself decide?

## Two families of stop condition Every ReAct loop needs an answer to "when does this stop?", and there are exactly two places the answer can come from. **In-band, decided by the model.** A pass produces a final answer rather than an action. This is the pattern's designed exit and the only one that reflects task understanding: the agent believes it has enough. Some loops make this explicit rather than implicit, giving the agent a dedicated finishing action it must call, which has the useful property that finishing becomes an observable event with arguments rather than the absence of a tool call. **Out-of-band, decided by the harness.** The loop is bounded from outside by things the model has no say over: a maximum pass count, a wall-clock deadline, a spend limit, a goal predicate the harness itself evaluates against the environment (did the order actually get placed? does the test suite pass?), or an operator cancelling the run. A correct answer to this question names both families and says why neither alone is sufficient. ## Why the model's own signal is not enough The in-band signal fails in both directions. **Never stopping.** The model keeps emitting actions because each pass looks locally reasonable. Nothing in the loop has an opinion about total progress, so a run can spend fifty passes circling. Without an external cap, that is unbounded cost. **Stopping too early.** The more insidious failure. A ReAct agent asked for a live figure returns a fully formed answer on pass one having called nothing, because the question resembled things it could answer from its training data. The transcript looks clean — a thought and an answer — and the answer is fluent and specific. It is also unevidenced, and the agent will report success. This is why success rate cannot be measured by "did the loop exit normally": premature exits exit normally. ## Termination is not the same as correctness The distinction interviewers listen for: **the loop terminating is a control-flow fact; the answer being right is a separate claim requiring separate evidence.** These come apart constantly. A run that hits its pass cap has failed to terminate in-band but may still have gathered enough to return something useful as a partial result. A run that exits cleanly on the model's own say-so may be entirely fabricated. Treat the model's answer as a proposal that gets checked — against a schema, a test, a verifier, a second reading of the environment, or a human — rather than as proof of completion. ## What to do when a cap fires Hitting an external limit is not automatically an error to throw away. The reasonable options, in rough order of preference: - **Return a partial result** with an explicit "incomplete" flag and the trace, so the caller can decide. - **Escalate to a human**, handing over the transcript so far, which is the right default when the remaining step is irreversible. - **Hard fail**, appropriate when a partial result would be misleading or acted on automatically. The pattern to avoid is silently returning the best-so-far as though it were a completed answer, which converts an honest timeout into a confident wrong result. ## Choosing the caps Caps are set from observed traces, not intuition. Look at the pass-count distribution for successful runs on your task suite: if the median success takes four passes and the tail takes nine, a cap of ten bounds cost while barely touching legitimate work, and a cap of thirty mostly funds runaway runs. Setting the cap too tight is not free either — it cuts off the genuinely hard cases, which are frequently the ones that mattered. On irreversible actions, the interesting limit is often not the pass count at all but whether the agent should be allowed to finish unsupervised. A run that will place an order or dispatch a crew is one where the last step deserves confirmation regardless of how many passes it took. ## Answering well Name the in-band exit first, since it is the pattern's own mechanism. Then name the external bounds and explain that they exist because the model's judgement about being finished is exactly the thing under test. Close with the premature-answer case: it is the failure most candidates forget, and mentioning it signals you have watched real runs rather than only read about the pattern.