← Zahir Khan · Artifact · August 2026

The Agent Verification Checklist

Ten checks I run before I believe an AI agent when it says a job is done. Use it on a pull request, a status report, or an agent's own summary of its work. I work in software delivery, and most of this applies to any report you are asked to trust.

All ten come from the same problem. An agent, or a person, or a supplier says the work is finished. The only proof is that sentence. That is not proof. It only looks like proof.

So I test every item on this list, including the list itself, with one question. Can I name the exact thing that would show this is wrong? If I cannot, the item does not belong here.

Two honest limits. First, proof takes time. A standard that costs too much gets dropped quietly, so I only run this on claims I would have to explain if they went wrong. Second, proof itself can mislead. Having some evidence is where the check starts, not where it ends. That is why half of these items ask how good the proof is, and not just whether proof exists.

There is one reason agents need this more than people do. If a person says the work is done and it is not, you can go back to them later. That alone does part of the job for you. With an agent there is nobody to go back to. So the checking has to do all of the work by itself.

Tick an item only when you can name the proof, and write that proof in the box. A tick with an empty box does not count. That is this page following its own rule.

1. I saw the problem myselfIf this is a bug fix, I saw the problem with my own eyes before any code changed. A log line, an error message, a screenshot. An agent telling me something was broken is not the same as seeing it broken.
2. Proof from a tool, not a summaryEvery claim about something a user can see needs proof from a real tool. And the proof has to show the result is correct, not only that the system replied. A page can load and still show the wrong number. An API can answer and still send back nonsense. So I want to see the actual value, not a sentence about what should have happened.
3. One claim, one testEach item on the "done" list should have one clear yes or no test. I also check the work in small steps, while it happens. If I cannot name the test for an item, that item is too vague to trust. So I split it into smaller parts until I can.
4. A written plan came firstThere is a plan I can still open, written before the work started, and somebody other than the builder read it and left a comment. If no such plan exists, this item fails. Fixing a bad plan early is much cheaper than fixing a bad result later.
5. A second check from a different angleFor anything important, the second check came from a different angle or a different person. One process checking its own work and then approving it proves nothing.
6. Checked on the real systemThe proof came from the real system, running the current version, after the change went live. A passing test on an old build proves nothing. Neither does a cached page, or the right answer taken from the wrong branch.
7. One rule about what must NOT happenAt least one item on the list is about something that must not happen. A door that must stay locked. An old bug that must not come back. A list of only good outcomes will miss this kind of problem completely.
8. Read the original request againWhen the technical checks pass, I read the original request one more time. Then I make sure nothing in it was quietly dropped while the work was going on.
9. "Looks fine" is not proof"Should work." "Looks fine." "No errors." These are useful as a short summary of something I can open and check myself. They are not enough as the whole answer. If the words are there in place of the proof, I go and look.
10. Say clearly what you could not checkIf I cannot check something right now, I say so clearly and write down when I will check it. It does not go into the "done" pile just because checking it was difficult.

Everything you tick or type stays in this browser only, in localStorage. Nothing is sent anywhere. Reloading the page will not lose it.

Where this comes from

I run a home server and some automated jobs for my own projects. Market screeners I use myself, small builds, small sites like this one. The problem I keep watching for is not an agent doing the wrong thing. It is an agent telling me it did the right thing, with nothing behind that sentence. The risk is smaller on my own projects than it is at work. The problem is exactly the same. On my own projects I am free to talk about it.

About this page

An AI agent wrote the first draft of this page, using my own practice and my edits. Before publishing it, I ran the list above against the page itself.

Item 2 passed. The tick boxes here were tested in a real browser with the error console open, instead of being described to me in a summary.

Item 5 failed the first time. I asked for a review, and the review came back from the same model family as the agent that wrote the page. That is one process checking its own work. A second review, from a different company, then found what both of them had missed. Two items on this list were saying almost the same thing.

Item 7 caught me as well. I had written down what must not appear on this page. Then I wrote one of those things anyway, and a reviewer found it before I did.

Tell me I'm wrong

If one of these ten is wrong in your experience, please tell me which one and why. Find me on LinkedIn. A list that says every claim should be testable ought to be happy to be tested itself.

← Back to zahirkhan.com