One problem keeps showing up in coding-Agent workflows: the Agent edits a few files, runs part of the test suite, writes a confident final message, and the surrounding system treats that message as done.
That shortcut works until the first non-trivial failure. The intended file may have changed while an unrelated file changed too. A narrow test may pass while the required suite was never run. A commit may exist locally but not on the remote. A deployment command may return successfully while the service stays on the old version. None of those facts can be established by the final message itself.
My central claim is simple: an Agent may submit a completion claim, but it should not be the authority that accepts that claim.
The longer engineering argument is in Completion Is a Claim, Not an Accepted State. The practical version for coding work can be much smaller:
Agent says done
→ read back repository and external state
→ run deterministic checks
→ inspect process, outcome, blockers, and side effects
→ accept, reject, escalate, or leave undetermined
The first layer should be deterministic whenever possible. For a repository task, I want the actual diff, the required test results, the build output, the commit SHA, and a remote readback. If the task changed a service or an issue tracker, I also want the state read from that system after the write. This is less glamorous than a judge model, but it catches the most common gap: the Agent reports what it intended to do rather than what the environment now contains.
The second layer is interpretive. A verifier can review the trajectory and ask whether the edits match the request, whether the chosen tests are meaningful, whether an external blocker caused the failure, and whether an unexpected side effect appeared. Microsoft Research’s Universal Verifier is useful here because it separates process quality from outcome attainment and retrieves evidence for individual rubric criteria. Its implementation also makes the evidence-oriented design easier to inspect.
That distinction matters in day-to-day Agent work. If an Agent follows the right procedure but hits a missing credential or CAPTCHA, the process may be valid while the outcome is not reached. If a build becomes green through an unrelated workaround, the outcome may look acceptable while the process and scope are questionable. A single success: true field throws away those differences.
I would rather preserve a small state model:
running
→ completion_claimed
→ verifying
→ accepted | rejected | escalated | undetermined
blocked and undetermined are not cosmetic states. They tell the next worker whether to retry, request authorization, repair the environment, or ask a human to decide. They also prevent a recovery worker from starting from an invented “completed” checkpoint.
The remaining question is where the acceptance authority should live. For a local refactor it might be a deterministic policy plus tests. For a production change it may require QA or an explicit human approval. For a long-running autonomous workflow, it probably needs a versioned acceptance contract that states which evidence is mandatory and who may override a failed or ambiguous check.
How are people handling this with Cursor Agents in real repositories? Which evidence do you require before a task may enter done, and do you keep blocked or undetermined outcomes separate from failed work?
Other language: 中文版本