An AI agent can produce a confident “done” message while the thing you actually asked for is missing, incomplete or wrong. The fix is simple in principle: separate claimed completion from verified completion.
Claimed completion is only a status report
When an agent says it created a WordPress post, updated a file or completed a deployment, that statement is evidence about what the agent believes happened. It is not proof that the external system now contains the required result.
A useful workflow therefore treats “the agent says it finished” as the start of verification, not the end of the job.
A successful tool call is not the same as an accepted result
A tool can return successfully while the overall task still fails its acceptance criteria. A post might exist but have the wrong status. A file might have been written to the wrong path. A deployment command might return before the public service is healthy.
Verification should check the final system of record: read the WordPress post back, inspect the expected file, query the live endpoint, or run the relevant test.
Reasoning is not verification
Model reasoning can help choose actions and diagnose failures, but it cannot substitute for observing the external result. The strongest completion evidence comes from a source independent of the agent’s own narrative.
For example, if the acceptance criterion is “a draft exists in WordPress with this exact title”, query WordPress and compare the returned ID, status and title. If the criterion is “the page is public”, request the public URL and verify the response.
Let acceptance criteria own the completion state
Instead of allowing a worker to mark itself complete, define a small verifier for each class of job. The verifier should answer a mechanical question wherever possible:
- Does the expected artifact exist?
- Does it have the expected state and content?
- Did the required tests pass?
- Is the public endpoint healthy?
- Can the result be read back from the system of record?
Use durable receipts for autonomous workers
For recurring automation, record identifiers such as a request ID, WordPress post ID, file hash, test result or deployment version. These receipts make retries and recovery safer because a later worker can inspect what actually happened instead of trusting conversational history.
Make retries idempotent
Verification becomes especially important after timeouts. If a request may have succeeded but the response was lost, blindly repeating “create” can produce duplicates. A safer design binds the operation to a request ID, reconciles the existing result and returns the same object when the same request is replayed.
A practical completion pattern
- Intent: record exactly what should change.
- Execute: perform the bounded action.
- Observe: read the result from the external system.
- Verify: compare it with explicit acceptance criteria.
- Receipt: persist enough evidence for another worker to audit or resume the job.
- Complete: only then mark the work finished.
The broader lesson
Autonomy is not about removing checks. It is about moving the right checks into the system so a human does not have to perform them manually every time.
An autonomous worker becomes more trustworthy when it is less responsible for declaring its own success. Let the worker do the work; let external evidence decide whether the work is actually done.