One of the most useful changes I have made to the way I work with AI agents is also one of the least sophisticated.
I stopped treating finished as evidence that anything actually happened.
That sounds ridiculous written down.
If you give somebody a job, they return with a result, and the result looks complete, the normal assumption is that the work between those two points took place.
With agents, I no longer make that assumption automatically.
Not because every model is secretly plotting against me. That would at least be entertaining.
Because the output can look extremely convincing even when the process underneath it failed.
I learned that properly during a Music Kite research run in which a browser-enabled worker was supposed to visit known websites and capture literal evidence. The system had browser controls, source fields, validators and a controller around it. The finished batch looked beautifully complete.
It was not.
The agent had written evidence-like text into the records without actually retrieving the pages it claimed to have checked.
The more useful lesson was not simply “agent bad”.
It was that almost every control around the agent had proved a different claim from the one I actually cared about.
A browser lease proves you had a browser lease
The worker acquired a browser lease.
That looked reassuring.
Except a browser lease proves exactly one thing: a browser slot was claimed.
It does not prove a page was opened.
It does not prove the expected domain loaded.
It does not prove the text stored as evidence appeared anywhere on that page.
Agent systems are full of things that look like proof because they sit close to the thing you care about.
A tool was available.
A tool call was attempted.
A field exists.
A test passed.
A report says complete.
A file path is mentioned.
All useful signals.
None automatically proves the larger claim.
If the claim is the agent checked the official website, then the agent had browser access is weak evidence.
The evidence should demonstrate that the page was actually retrieved and that the conclusion came from it.
That may be a retrieval record, a source excerpt tied to the fetched page, a browser trace or some other inspectable artefact. The exact form depends on the task.
The principle does not.
Make the evidence match the claim.
A validator can be perfectly correct and still validate the wrong thing
The Belfast failure was almost elegant in this respect.
The validators reported zero faults and 100 per cent compliance.
They were doing their jobs.
The records had the expected fields. They had source values. They had evidence strings. They had verification statuses.
The validator proved that the evidence_quote field existed.
It did not prove that the evidence existed.
That distinction is much more dangerous than a validator that simply crashes.
A broken check eventually annoys you into investigating it.
A clean green report tells your brain the opposite: this no longer needs attention.
So one question I now ask much more aggressively is:
What exactly does this test prove?
Not what I hoped it proved.
Not what the name of the test implies.
What conclusion is actually supported by the thing being checked?
If a test confirms a file exists, the file exists.
It does not prove the contents are correct.
If an API returns 200, the request completed successfully at that level.
It does not automatically prove the user's workflow works.
If a migration is recorded, the migration is recorded.
It does not prove every production path using the changed schema behaves correctly.
Specific evidence is good.
The problem starts when a specific signal is promoted into a much larger conclusion.
I increasingly ask for artefacts rather than confidence
Agents are extraordinarily good at sounding finished.
That is convenient when they are finished.
It is not especially useful as proof.
So, for important work, I prefer the task to leave behind something inspectable.
If an agent says it changed code, I want the diff.
If it says tests passed, I want the relevant test run.
If it says it checked a source, I want evidence tied to the source.
If it says an image was generated and saved, I want the actual openable file where it claims to have put it.
If it says a production defect is fixed, I want the repaired behaviour exercised in the environment where the defect mattered.
This is not an attempt to create paperwork for machines.
I want the opposite: the smallest useful artefact that reduces the amount of trust required at the decision point.
Evidence can become its own ridiculous industry if you let it. I have built workflows where the reports started becoming nearly as elaborate as the thing being reported on.
That is not the objective.
The objective is that the important claim should be easy to inspect.
Could the system produce this proof without doing the work?
This has become one of my favourite acceptance questions.
Could the system produce this evidence without actually doing the thing?
If yes, the evidence is weak.
My research validator could receive an evidence_quote without the agent visiting the website.
Therefore the existence of evidence_quote was weak proof of website verification.
The same pattern appears everywhere.
A report saying all tests passed can exist without showing you which tests ran.
A screenshot can show a beautiful page while the interaction behind it is broken.
A database row can exist while row-level policies make the feature unusable for the actual user.
A branch can contain the fix while production is still running the previous version.
The strongest evidence tends to come from the boundary where the claim becomes real.
For a UI feature, exercise the rendered application.
For a permission repair, test the exact authorised and unauthorised cases.
For research, tie the claim to retrieved source material.
For a generated asset, open the asset.
For production, test production.
Obvious.
Still worth saying, apparently.
The builder should not be the only witness
This is another reason I separate builder and critic roles when the risk justifies it.
The builder carries context about what it intended to do. That context helps enormously while making the thing and can interfere slightly while judging it.
Humans are the same. If I have spent hours building something and a smoke test comes back mostly green, I can feel the temptation to interpret the remaining oddity generously.
A fresh reviewer has less investment in the story.
The critic does not need to invent an alternative implementation. It needs to inspect the artefacts, the acceptance criteria and the evidence.
Builder makes the claim.
Critic checks the claim.
I decide whether it is accepted.
That does not make the critic infallible. It simply gives me another witness.
Write acceptance conditions, not merely tasks
I used to write a lot of agent instructions in the form of tasks.
Fix the RLS policy.
Create the images.
Check the website.
Research these venues.
Now I spend more time thinking about what the world needs to look like when the task is accepted.
“Create five images” is a task.
“Create five landscape images, preserve the supplied likeness where required, and leave five openable outputs associated with the correct article” is an acceptance condition.
“Fix the permission policy” is a task.
“The authorised user through the previously failing authority path can complete the write; the unauthorised user still cannot” is an acceptance condition.
“Check the official site” is a task.
“Retrieve the official page, record the source, capture the relevant literal evidence and retain enough provenance to trace the claim to the retrieval” is an acceptance condition.
The second form gives the reviewer something concrete to inspect.
It also gives the agent a better target.
The amount of proof should follow the risk
There is an exhausting version of all this where every action requires three auditors, seventeen logs and a notarised statement from the GPU.
I have no interest in that.
If an agent drafts a caption and I can read it in four seconds, I am the validator.
If it changes a production permission boundary, the evidence bar should be higher.
If it claims to have verified hundreds of records from source websites, provenance matters.
If the branch affects payments, authentication or user data, the agent says it looks good is not a particularly interesting acceptance test.
Proof should be proportionate to the cost of being wrong.
That is ordinary engineering.
Agents simply make it easier to forget because plausible completion arrives so quickly.
The report is not the work
The Belfast incident changed one simple thing in my head.
I no longer treat the completion message as the end of an important agent task.
It is a claim about the task.
Sometimes that claim is enough.
Often it is not.
The task is complete when the evidence I care about supports the outcome I asked for.
A diff.
A test.
A source retrieval.
A screenshot.
A production smoke run.
An openable file.
Usually nothing glamorous.
Good.
I am not trying to make the machine sound confident.
I am trying to know whether the thing happened.
The rule I use now is embarrassingly straightforward:
Do not ask the agent whether it did the work. Design the task so the work leaves proof.