Why completion needs a gate
Tool-using agents can stop after an action that looked successful even when the real goal was not achieved. A file may have been written with the wrong content, a button may have been clicked without the expected UI change, or a command may have returned successfully while the service remained unhealthy.
Define the outcome before execution
Write down what must be true at the end, what evidence is acceptable and which uncertainties should block a success claim. This can be as simple as a checklist or as formal as a machine-readable task contract.
Keep model confidence separate from proof
The model is useful for reasoning and choosing actions. It should not be the only authority for deciding that a real-world change worked. Important outcomes should be checked using evidence appropriate to the task.
Verify state-changing work independently
When an action changes a file, application, service or device, prefer a second observation of the resulting state rather than trusting the action acknowledgement alone.
Recovery should remain bounded
A failed check can trigger another attempt, an alternate route, a clarification request or a safe stop. Retry limits matter because resilience should not become an infinite loop.
The useful principle
A completion gate makes autonomy accountable to the user-defined outcome without requiring the public disclosure of a product's internal state machine or recovery policy.