How to check what an AI agent did

The first week of running agents feels fine, because you read everything. By the fourth week you cannot. Somewhere in between, review turns into sampling without anyone choosing it. You sample whatever you had time for. At that point the honest answer to "is this work good" becomes "some of it, probably".

More attention will not fix this. Decide in advance which questions a machine answers, which a model answers and which a person answers. Then never spend a person's time on a question the first two could have settled.

Layer one: what a machine can decide

Start here, because it costs nothing and never gets tired. Much of "did the agent do this properly" comes down to questions with clear answers:

• Does the test suite pass, and did coverage move the way the task said it would?
• Do the required fields of the proof of work exist and contain something?
• Does the diff stay inside the files the task named?
• Does the referenced commit or document exist, and is it the one the report was pinned to?

None of these needs judgment. All of them are common failure modes, especially the last one. If work references something that has since changed, a green tick can easily end up meaning nothing.

Anything a deterministic checker settles is something a reviewer does not have to open.

Layer two: what a model can judge

The second layer handles questions that need reading but not authority. Does the evidence support the claim? Does it match what was asked?

A model is useful here, but only with a constraint. Do not ask "is this good work". That gets you a confident essay with nothing in it you can check. Ask it to compare two specific documents: the definition of done, and the proof of work attached to the task. Then have it report where they agree, where they do not, and what it could not tell either way.

The last category is the most valuable. A model that says "the definition asked for a rejects file and I cannot find one referenced anywhere" has done something useful, in a form a person can check in seconds.

One rule keeps this layer honest: the model reports but never decides. If its judgment becomes the gate, you have swapped one unverifiable claim for another and added a step.

Layer three: what only a person settles

Some questions need a person. Was the outcome worth having? Will the approach cause a problem in six months? Is the thing that passed every check still the wrong solution to the right problem?

You will need to sample. The design question is at what rate. If you sample everything, you have automated nothing. If you sample nothing, nobody audits the first two layers. That matters because a checker with a bug can pass everything.

So the rate should be set by rule, not by someone's choice on the day. Derive it from the agent's track record, apply it by formula, and raise it when the record gets worse. Sample a new agent heavily, and one with a long clean history less. Log any manual override of the rate with a reason, because "we waived review that week" is exactly what you will want to find later.

What makes any of this possible

All three layers depend on one thing being true before verification starts. The record of what happened has to be trustworthy.

If an agent reports its own actions, you are checking a story it told about itself. The story will hang together, and it may still be entirely wrong. No amount of careful reading at layer two will reveal the difference. When tool calls pass through a gateway that writes the log, the trace records what the agent did instead of what it said it did. Then the two layers above have real data to work with.

The same goes for evidence. If proof of work can be edited after the fact, it shows how things look now, not how they looked when someone approved them. If it is versioned and append-only, it can answer the question people ask later: what did this look like when somebody said yes?

Where to start

Do not build all three at once. Take the last thing that went wrong and ask which layer would have caught it.

If a test would have caught it, you have a layer-one gap, and it is the cheapest to close. If it needed someone to read the definition of done next to the output, that is layer two. If it took judgment about whether the work was worth doing, that is layer three. It means your sampling rate is too low or aimed at the wrong tasks.

Most teams find the first answer more often than they expect. That is good news, because layer one scales without taking up anybody's time.