AI Agent Verification: How to Prove an Agent Actually Did the Work

01The status update is the product

Ask an AI agent to update a CRM record and it will tell you the record is updated. Ask it to open a pull request and it will tell you the PR is open. Ask it to send the follow-up and it will tell you the follow-up is sent.

Sometimes it is. Sometimes the tool call failed and the model wrote the summary anyway, because writing a plausible summary is the thing it is best at. The failure is quiet by design. You get a green checkmark, you stop looking, and the gap surfaces two weeks later when a customer asks why nobody replied.

A completion claim is not evidence of completion.

This is the single most expensive failure mode in autonomous software, and almost nobody sells against it. Every vendor demo shows the happy path. Nobody shows you what their agent does when it thinks it finished and did not.

02Why self-reported completion is not evidence

The problem is structural, not a bug in one model.

An agent is a language model in a loop with tools. It decides what to do, it calls the tool, and then it writes the report on what happened. The same system authors the work and the report card. When the tool call errors, times out, gets rate limited, or returns something ambiguous, the model still has to produce a next token. A confident summary is the highest probability output.

So “task complete” is a claim generated by the same process that generated the work. It is not an observation of the world. Treating it as a status field rather than a claim to be tested is where trust in agent platforms goes wrong.

This is also why longer chains make it worse. A nine-step pipeline gives you nine chances for a silent gap, and the final summary flattens all of them into one sentence.

03What verification actually requires

Verification needs at least one input the agent did not write.

Syntrum compares three things before a task is allowed to close:

• What was asked. The original request, as it entered the system, not the agent's restatement of it.
• What the agent claims. The completion report, in the agent's own words.
• What actually executed. The tool call record, which is written by the runtime, not by the model.

When those three disagree, the task does not close. It reopens with the gap named, so a human sees “claimed the document was created, no document.create call in the record” instead of a checkmark.

The important part is the third input. The execution record is produced by the layer that performs the calls, so the agent cannot edit it, summarize it, or route around it. Take that away and you are back to asking the agent whether the agent is telling the truth.

There are three specific things this catches:

• Silent completion. A task closes without producing anything a human can open. If there is no artifact, there is no completion.
• Promised completion. “I'll handle that next” counted as done. Intent is not execution.
• Fabricated completion. A claim to have created, sent, or updated something that does not exist in the target system.

04An audit trail is not verification

Most platforms answer this question with logging. Full audit trail, every tool call recorded, export whenever you like.

Logs are necessary and not sufficient. A log tells you what happened after you go looking. Verification is a gate that runs before the task is allowed to close, so you do not have to go looking in the first place. The difference is who does the work: with logs, a human reconciles claims against records. With a verification gate, the system does it on every task and only escalates the mismatches.

05Why this is becoming a compliance question, not just a quality one

The EU AI Act puts obligations on record keeping and human oversight for systems in scope, and deployers of high-risk systems are expected to keep logs and to have oversight that is actually effective rather than nominal. Whether a given agent deployment falls in scope depends on the use case, and most internal workflow agents will not be high risk. Take your own legal advice on classification.

But the direction is clear regardless of classification. Oversight that rests on the agent's own status reporting is not oversight. If the only record of what an agent did is what the agent said it did, you cannot demonstrate control of it to an auditor, a customer, or your own board. Provable action beats asserted action, and the gap between the two is going to keep getting more expensive.

This is the same argument as approve the action, not the intention: the value comes from the human seeing the exact call that will run, not a summary of what the agent intends to do.

06Five questions to ask any agent vendor

Use these on your next demo. They are short and they are hard to talk around.

• What happens when a tool call fails but the model writes a success summary anyway? Show me.
• Is the completion check reading a record the agent cannot write to?
• Does a task close on the agent's claim, or on evidence of the artifact existing in the target system?
• What does the user see when the claim and the execution record disagree?
• Can you reconstruct any task after the fact, including which approval carried which call?

If the answers are vague, ask for a failure demo rather than a success demo. Any team that has solved this is happy to show you the agent getting caught.

07Verification is what makes autonomy safe to widen

None of this is about distrusting agents in general. It is about how trust gets granted.

A new agent should start read-only, then move to approval-gated writes, then earn autonomy for the specific action classes that have proven reliable. That progression only works if the evidence is real. Widening autonomy based on a dashboard full of self-reported completions is widening it based on nothing.

With verified completion, the decision to give an agent more room is made on artifacts you can open and a record you can replay. That is the difference between an assistant you supervise constantly and a coworker you can actually delegate to.

08FAQ

What is AI agent verification?

Checking an agent's completion claim against an independent record of what actually executed, before the task is allowed to close, rather than trusting the agent's self-reported status.

Why do AI agents claim work they did not do?

Because the same model that performs the work also writes the summary of it. When a tool call fails or returns something ambiguous, a confident completion summary is still the most likely output.

Is an audit trail enough?

No. A log lets you investigate afterwards. A verification gate stops the false completion at the point it happens, so nobody has to investigate.

How do I test this on a vendor?

Ask for a failure demo, not a success demo. Make them show you what the product does when the agent claims something it did not do.