A status field, a report, or a UI string that says something worked is a claim, not evidence — only command output earns trust.
Every completion claim an agent makes is a suspect until something outside the agent proves it. That includes the obvious cases — “tests pass,” “deployed successfully” — but it also includes the cases people don’t treat as claims at all: a task marked done in a tracker, a report an agent wrote about its own work, a button in a UI that says “Saved” or “Synced.” All of those are text an agent, or a system built by one, produced about its own state. None of them is the state itself.
That’s the distinction I try to hold onto: run, don’t read. Reading a report and concluding the work happened is trusting a narrator. Running the actual command — the test suite, the build, the health check — and reading its output is observing the thing directly. The difference sounds pedantic until you’ve watched a report describe a passing suite that, run fresh, doesn’t pass, because the report was written from an earlier state, or from an assumption, or from a run that silently skipped the failing case and summarised the rest as green.
The distance from ground truth compounds the more layers get stacked between the claim and the thing it describes. A summary of a report is one step further removed than the report itself, and a summary of several agents’ summaries is further still — each layer smooths over exactly the detail that would have revealed the gap, because smoothing is what a summary is for. By the time a status reaches whoever’s deciding whether to ship, it can have passed through three or four of these compressions, each individually reasonable, collectively describing nothing anyone actually checked.
The UI strings are the sneakiest version of this because they’re designed to be reassuring. “Payment successful,” “Message sent,” “Sync complete” are product copy, written to make a user feel confident, not written as an audit trail. When an agent is the one reading that screen and deciding whether to proceed, it’s reading marketing language and treating it as ground truth. I’ve had an agent report a task complete because a page displayed a success toast, when the underlying write had actually failed and the toast fired regardless — the UI was decoupled from the state it claimed to describe, and nobody had told the agent that was possible.
The practical fix is to make the gate itself incapable of accepting a claim as evidence. A verification step doesn’t get to say “the report confirms the migration ran” — it has to query the database and count the rows itself. It doesn’t get to say “the deploy log shows success” — it has to hit the live endpoint and check the response. This is more work than reading a summary, on purpose, because the summary is exactly the artefact most likely to be wrong in the one case where being wrong costs the most: right before something ships.
What I’ve noticed is that this discipline catches a specific, recurring failure — not malicious fabrication, just an agent extrapolating from partial information the same way a person does when they’re confident and slightly wrong. It ran the migration on a staging copy and reported it as done everywhere. It saw one green check in a matrix of ten and summarised the matrix as passing. None of that is lying. It’s the ordinary failure of trusting a description instead of the thing described, and it happens constantly when nobody insists on the harder path.
Once a pipeline is built this way, the gate can’t be talked into a pass, which is the entire value of having one. A verbal summary, however fluent, doesn’t move the needle, because the needle only moves on command output pasted verbatim. That’s a harder standard to meet honestly, and an easier one to trust once it’s met.