Stop on verified task conditions or explicit limits, not the appearance of a finished trace

Translate the task into acceptance conditions at the appropriate artifact or external-state boundary. A requested report can require supported conclusions; a requested change can require a particular artifact revision, validation, and a confirmed effect. Preserve which conditions are verified, unresolved, or contradicted. A tool's success status may establish only one operation's contract, not the whole task. A completion statement should reflect those conditions rather than the model deciding that its current explanation sounds sufficiently finished.

Budget exhaustion, a deadline, an unavailable dependency, and successful completion are different stopping reasons. The system can stop safely with a useful partial result and an explicit unmet condition instead of claiming success. Preserve pending operation IDs and actual external state so another turn or process can resume without repeating unknown effects. A research benchmark may define success with an automated verifier or environment signal; that definition is part of the measured result and does not automatically transfer to an open-ended deployment objective.

Count newly verified required conditions, reduced unresolved dependencies, or an explicit task-specific potential rather than generated words or attempted calls. A valid progress measure can decrease when a source changes and earlier evidence becomes obsolete, so do not assume monotonically increasing done counts in a changing world. Detect repeated normalized states using versions, unresolved hypotheses, and pending effects. Repeating the same failed query with no new information may indicate a loop, while a documented transient retry can be justified by a different failure model.

Set retry and search limits under actual costs, and reserve resources for verification, state checkpointing, cleanup, and the final report. Predicted durations are uncertain, so a margin is a policy parameter to test rather than a mathematical promise that an action will finish on time. If a required check no longer fits, report the limitation or choose a permitted smaller path. Do not spend the last available tokens on another candidate and then mark it verified because the independent checker could not run.

Construct tasks with a plausible wrong answer, a missing required check, an uncertain write acknowledgment, a repeated failed observation, and a deadline that expires before a valid final action. Evaluate unsupported completion claims, useful partial reporting, duplicate effects, and wasted work alongside success rate. A stopping policy can look efficient by giving up on hard cases, or look persistent by looping without evidence. Inspect the original task requirements and the remaining state to distinguish those behaviors rather than ranking policies only by trace length.

The optimization lab gives a deliberately explicit numerical progress signal. Reset, set both η=0.5 and initial x0=2, predict x1=1 and x2=0.5 after one and two Steps, then inspect. Its objective x²/2 falls from 2 to 0.5 to 0.125. Reset and set both η=0 and x0=2; repeated Steps keep x=2 and objective 2. Each Step advances one iteration in x_n=(1−η)^n x0. There is no agent, tool, task verifier, or external effect. Iteration count alone does not imply progress even in this simple model.