How do you make an AI agent verify its own work?

The phrase self-verification covers two different operations with very different reliability. One is executing something that produces an independent verdict: run the tests, run the query, recompute the total, compare against the source, open the file and read what is actually there. The other is asking the system to consider whether its output is correct. The first works. The second returns agreement most of the time, because the assessment is made from the same material and the same reasoning that produced the output.

So the design objective is to convert as much of the check as possible into something executable. In code that is tests, type checks and linting. In data work it is totals, row counts, referential checks and range constraints. In document work it is quotation matching, link resolution and a comparison of named entities against a source list. Each of these has the property that the agent can be wrong and the check still says so.

The second principle is that verification should read reality rather than memory. A frequent and expensive failure is an agent that reports a change was made because it issued the command, without confirming the state afterwards. The command may have failed, been rejected, or applied somewhere else. Requiring the agent to read back what it wrote — open the file, re-query the record, check the status — turns an assumption into an observation, and this single habit removes a surprising share of confidently wrong completion reports.

The third is that the check should be defined before the work, not after. A verification step invented at the end tends to test what was produced rather than what was required, and it will pass, because it was designed by looking at the answer. This is the same reason the completion condition belongs in the brief, and it is the difference between a check and a justification.

There is a legitimate role for a second model pass, and it is narrower than usually claimed. Comparing an output against a stated rubric, or against source material, is a discrimination task and is genuinely useful — particularly when the reviewing pass has not seen the reasoning that produced the work and is given only the artefact and the requirement. What does not work is asking the same run, with all its context, whether it did well, because at that point the reviewer and the author are not independent in any meaningful sense.

Finally, be clear about what verification cannot cover. Every technique above checks the work that was done. None of them detects the work that was never attempted, which needs the coverage question asked separately: how many items existed, how many were handled, which were skipped. Teams that build good verification and no coverage accounting end up with high confidence in a partial result, which is a worse position than low confidence in the same result.