Stopping Condition

The model itself has no built-in judgment of "I'm done"; it merely predicts the next token at each step, and without an explicit termination signal the model tends to keep calling tools.

The engineering solution to stopping conditions has two layers: runtime-layer hard constraints (maximum steps, maximum token budget, timeout) and task-layer soft constraints (writing the completion state as a decidable predicate).

When hard constraints trigger, the task is often unfinished, so the termination reason should be recorded in the logs to distinguish "normal completion" from "budget exhausted."

When designing an Agent, the permission boundaries (which tools can be called, which data can be accessed, which operations can be performed) and stop conditions (such as stopping to ask a human when uncertain, during sensitive operations, or when the loop count exceeds a threshold) should be made explicit.

Common engineering means of terminating an agent include maximum step/maximum round limits, timeout budgets, consecutive-failure counters, and failure-signal detection based on rules or model judgment.

The stopping condition is not the model's self-reported completion, but a state at the product/repository level that can be independently verified by a third party, such as a scripted reload showing the field still exists, a test going from red to green, or a trace reproducing the old failure.