Verification
Why agent-reported success is not evidence, and what a verification gate actually requires.
The hardest problem in multi-agent work is not getting agents to do things. It is knowing whether what they did is correct.
The default assumption
Treat agent-produced work as a pull request from a stranger who is unusually confident and has never been wrong in their own estimation.
IMPORTANT
"The agent said the tests pass" is not the same as "the tests pass." Run them.
Verification gates
Work can carry a verification requirement, so a task does not complete merely because an agent declared it finished. Where a gate exists, the evidence has to exist too.
A gate is only as good as what it checks. A gate satisfied by "a command exited zero" is weaker than one that checks the command was the project's real test suite.
What counts as evidence
| Evidence | Strength |
|---|---|
| Test suite run, output captured | Strong |
| Diff you read yourself | Strong |
| Build succeeded | Moderate — proves compilation, not correctness |
| Agent's summary of what it did | None |
| Task marked complete | None on its own |
A practical review order
- Read the diff. Not the summary — the diff.
- Check the scope. Did it change files outside what you asked for?
- Run the project's own tests. Yours, not the agent's improvised ones.
- Look for deleted tests. A suite that passes because assertions were removed is the classic failure.
- Then decide about integration.
git diff
Cross-provider review
Having one agent review another's work catches a useful class of error, because the reviewer does not share the author's assumptions.
It does not catch errors both models make, and it is not a substitute for running the tests. Use it as an additional filter, not a replacement gate.
/review
Integration is a decision
Nothing merges itself because a worker declared success. Delegated work returns as a diff for review, and integration stays explicit.
When several workers ran in parallel worktrees, each diff can be individually correct while the combination is not. Review them separately, then think about interactions.
When verification fails
Prefer cancelling and re-scoping over asking the same agent to try again with the same instruction. A task that failed verification usually had a scope or context problem, and repeating it produces a differently-wrong answer.