ES
Writing Field notes

Don't trust an agent that says 'done'

Enzo Snyman

AI agents will tell you a task is done. Tests pass. The deploy shipped. The pull request was merged. Most of the time, that report is accurate, and it’s genuinely useful to be able to hand off a task and get a plain-language summary of what happened back.

The trouble is the times it isn’t accurate look, from the outside, identical to the times it is. An agent that’s finished a task correctly and an agent that’s confidently describing what it intended to do, rather than what actually happened, both produce the same sentence: “done.” There’s no tone difference, no hedge, no tell. The report is generated with the same confidence either way, because the agent isn’t lying in the sense of knowing the truth and saying something else. It’s reporting its own model of what should have happened, and that model can be wrong without the agent having any signal that it’s wrong.

Why this happens

Agents are, structurally, optimising toward a goal: satisfy the instruction, reach a state that looks like completion. “Report success” is very often the path of least resistance toward that goal, especially when the actual verification step, actually re-running the tests, actually checking the deploy landed, actually confirming the merge went through clean, is more expensive or more awkward than just asserting the outcome. This isn’t a flaw unique to any particular model. It’s closer to an inherent property of any system whose job is to complete tasks and whose only feedback loop for “did I complete it” is its own internal sense of having taken the right steps.

What makes it worse is that “done” from the agent’s side and “done” from the person who asked can be different things entirely. Tests passing locally isn’t the same claim as tests passing in the environment that matters. A file being edited isn’t the same claim as the edit being the one that was actually needed. The gap between those two definitions of “done” is exactly where an unverified “done” report causes real damage, because whoever received that report now believes something is true that isn’t, and everything they do next is built on that belief.

The fix: completion as a runnable fact, not a claim

The change that actually worked was small in concept and slightly more work in practice: for anything with a genuine finish line, define that finish line as a literal, re-runnable check before starting the work, not after. Not “write good tests” as an instruction, but the actual command that proves the work is done: run this specific thing, and expect this specific output. The task isn’t allowed to count as closed until that exact check has been run again, for real, and it passed, not until someone (or something) describes it as having passed.

This sounds almost too simple to matter, and that’s part of why it works. It removes the ambiguity around what “done” means for that specific task, because the definition was written down in a form nothing can talk its way around: a command either produces the expected output or it doesn’t. It also removes the temptation to accept a self-report at face value, because the self-report is no longer the thing being trusted. The check is.

What this changes day to day

Practically, it means every non-trivial task now carries its own short list of checks, registered before the work starts rather than invented afterward to justify it. When a task is claimed as complete, those checks get re-run, not skimmed, not taken on faith, actually executed again against the current state of things. If a check fails, the task isn’t done, regardless of how confident the report attached to it sounds. If there’s no check at all for a piece of work, that’s treated as a gap to fix, not a reason to just trust the report by default.

It’s a small habit, and it doesn’t require distrusting every agent interaction or slowing everything down to a crawl. Most tasks are small enough that this costs almost nothing extra. What it buys is the difference between an agent reporting its work and an agent proving it, and that difference is exactly the gap where quiet, hard-to-trace failures like to live.

If you’re using AI to ship anything right now, worth asking plainly: when it tells you something is done, what’s actually checking that, besides the agent itself?