Completion needs evidence. Continuing needs a reason.
An agent can be wrong by stopping early and wrong by doing one more thing. The first failure leaves the requested work incomplete. The second can replace a working result with another revision, repeat an effect whose outcome is unknown, or spend the remaining budget proving a point nobody asked it to prove. A larger context window does not resolve that tension. The system needs a decision about whether another action can change an unmet acceptance condition.
That decision is not the same as generating a final answer. A model can write a convincing completion summary while the deliverable is missing. It can also keep requesting tools after the deliverable has passed every required check. I would treat stopping as a controller-owned state transition, with evidence attached, rather than a sentence the actor is allowed to declare. The proposed design here is an operating contract, not a system I have deployed or benchmarked.
Start by separating success from exhaustion. LangGraph’s recursion-limit documentation describes reaching a maximum number of steps before a stop condition, noting both accidental cycles and legitimate complex graphs. Raising the limit may be appropriate for the latter. It does not turn the former into progress. An iteration ceiling bounds execution; it cannot certify that the task succeeded.
Completion therefore needs its own predicate. Consider a hypothetical agent asked to repair a command-line parser without changing unrelated behavior. Before editing, define the observable contract: the reported failing input is handled correctly, relevant regression checks pass, the change stays inside the allowed scope, and the reviewed artifact is retained. A controller can then distinguish work still needed from an agent’s preference to improve something nearby. Passing an existing suite alone is not enough if it never exercised the reported failure.
Bind that evidence to the actual candidate. Test output from the previous revision does not accept the latest file. Record the candidate revision or digest, the commands and results, the acceptance-policy version, and the unresolved findings. Protect the authoritative checks from the actor’s unilateral edits. If the agent can redefine success after seeing a failure, the system has delegated the exit condition along with the work. Changes to the task contract need an owner distinct from the agent trying to satisfy it.
Environmental feedback matters more than a confident narrative. Anthropic’s agent-design guidance emphasizes tool or execution results as ground truth for assessing progress and includes stopping conditions as a control mechanism. Applied to the parser, that means reading the saved patch and exercising the relevant behavior, not accepting the assistant’s account of either. The guidance supplies a design principle, not evidence that this proposed parser repair has passed.
A useful controller needs more than done and not done. Done means the required evidence matches the retained candidate and no required condition remains open. Blocked means a specific prerequisite prevents permitted progress, such as an unavailable dependency or an unresolved external outcome. Needs user input means an identified decision belongs to an authorized person and cannot be inferred from the grant. Budget exhausted means the execution allowance ended before acceptance. Those are proposed dispositions with different recovery owners; none should be flattened into a cheerful completion message.
Do not let those states become excuses to quit. A missing optional style tool should not block a repair that can be verified through the approved checks. An untried permitted evidence path is not a missing prerequisite. A question the task already delegates to the agent is not user input. Before escalating, require the unmet condition, the evidence already obtained, and the reason another authorized action cannot resolve it. Stopping well includes continuing when the next step is concrete and still useful.
Repeated-action detection should inspect state, not merely wording. In this design, retain a normalized signature of the tool, resolved target, relevant inputs, candidate revision, and failure class. Running the same failing command against unchanged bytes supplies no new evidence unless the underlying dependency is expected to change. Alternating between two edits that restore each other’s failure is a loop even when no adjacent call is identical. Keep that history outside the actor’s editable summary so a rephrased rationale cannot reset it.
Diminishing returns need a similarly practical test. Before another repair cycle, require a named unresolved condition, a hypothesis tied to observed evidence, and an action that can distinguish that hypothesis from an alternative. A newly inspected error may justify another attempt. Rewriting an already accepted explanation because it could sound better does not. This is a proposed admission rule, not a universal numerical threshold. Exploratory research needs a different progress definition from a parser fix, but both need to say what another step could establish.
The semantic judge can help assess that question without owning every answer. A fresh evaluator may find an omitted requirement or explain why a proposed test is irrelevant. Fresh context alone does not guarantee independent judgment: supplying only the actor’s summary can preserve the same omission. The original MT-Bench judge study examines position, verbosity, and self-enhancement biases, along with reasoning limitations. It is not a production-loop safety evaluation. My design inference is narrower: do not make fluent agreement between models the sole evidence that a task is complete.
Use deterministic checks where the contract permits them and an external verifier where semantic acceptance remains necessary. External should mean independently controlled evidence and authority, not merely another model invocation inside the actor’s loop. The verifier needs the original requirement, actual candidate, relevant execution results, and permission to reject the completion claim. It should not need authority to keep the actor running indefinitely. Once required checks accept the frozen candidate, a controller can terminate execution and reject further effectful calls for that completed job.
Budgets remain separate constraints. Define allowances for elapsed time, tool attempts, compute, and spending where the operating policy requires them, with accounting outside the model’s context. Reserve enough capacity to save work, inspect outstanding effects, and report the result. Exhaustion should prevent new discretionary work without destroying retained evidence. Long-running child processes and previously dispatched requests need explicit lifecycle handling too; ending the conversation does not establish that their effects have ended. A resumed task must inherit the original attempt history rather than receive a blank allowance by accident.
Uncertain side effects deserve an especially firm stop. Amazon’s retry guidance warns that a timeout does not establish that an effect failed to happen, and that retries can amplify load. In this design, an unknown external write suspends replacement writes while a permitted read reconciles the original identity. That is not passive failure. It is the next authorized work. Recovery either establishes the original result or returns an owned unresolved state, never a second action sent merely to discover whether the first succeeded.
Evaluator loops also need an exit contract. Anthropic’s evaluator-optimizer pattern is described as useful when evaluation criteria are clear and iteration adds measurable value. If the remaining feedback is preference without a required defect, retain the accepted candidate and put optional suggestions in the handoff. Test the stop boundary with controlled cases: a passing artifact and a request to keep polishing, stale test evidence, alternating regressions, an unavailable prerequisite, and an unresolved write. These are proposed tests, not reported results. Give the next tool call a burden of proof: which unmet requirement will it help resolve, and what new evidence can it obtain?
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.