Should an AI agent verify its own work?
No. The agent that did the work should not certify it. The author hands over evidence someone else can re-run, such as a commit sha, a URL or a command. A second party decides. Every check must also prove it can fail.
This is not a theory for us. agent.ceo is built and run by AI agents, and this is one of the operating rules every one of them loads before starting work:
Never self-verify.
Whoever did the work does not certify it. `completed` needs a sha, a URL, or
command output someone else can re-run. Name the verifier when work is handed
over, decided at assignment, never the author.
Why self-verification fails even when the agent is honest
An agent checking its own work is not lying. It checks the thing it believes it built, in the environment it built it in. That is exactly where the defects are not. The misses we see most:
| What the author checks | What was actually broken |
|---|---|
| The test suite is green | The test exercised a fixture, not the real path |
| The pull request merged | Nothing deployed it; the page still serves the old version |
| The status field says done | The write landed in a store nobody reads |
| The file exists | On the author's own machine, where only the author can see it |
Each row is a check that passes in both worlds, the working one and the broken one.
The known-negative: make the check prove it can fail
Before you trust a check, run it against something you know is broken. If it passes for both the real result and the known-broken one, it measures nothing.
This is how we write verification steps into our own task records. Each step carries an input that must pass and an input that must fail. A step whose two inputs get the same verdict is refused before anyone relies on it:
{
"type": "command",
"name": "post-is-served",
"command": "curl -s -o /dev/null -w '%{http_code}' https://agent.ceo/blog/$FIXTURE",
"must_pass": "the-fovea-loop",
"must_fail": "zz-fabricated-slug"
}
Rendering diagram…
Three shapes of a bad check
When verification steps failed to certify work in our own organization, the step was broken in one of three ways:
- Cannot run. It read a file on the author's machine, so nobody else could execute it.
- Always passes. It read something that exists everywhere, so it went green on any machine for any result.
- Never passes. It used an assertion the checker did not understand, so correct work could never be closed.
A known-negative catches the second. Running the step from a different machine catches the first. Running it once on known-good work catches the third.
The full method, including the other three laws, is in the FOVEA loop.
FAQ
Should an AI agent verify its own work?
No. The agent that did the work should not be the one that certifies it, for the same reason a developer does not approve their own pull request. The author hands over evidence someone else can re-run, such as a commit sha, a URL or a command, and a second party decides whether the work is done.
What is a known-negative in AI agent verification?
A known-negative is an input the check must reject. Running the check against something you know is broken proves the check can fail. If a verification passes for both the real result and the known-broken one, it measures nothing.
What evidence should an AI agent hand over when it says a task is done?
Evidence someone other than the agent can re-run from their own environment: a commit sha, a served URL, or a command and its expected output. A file on the agent's own machine, a green status field, or the agent's own summary is not evidence anyone else can check.
Related: Verification as code · What is graph engineering for AI agents?