An agent I’d sent off a few weeks ago to clean up a folder of personal notes came back and told me it had deleted 474 files. Not moved. Not flagged. Deleted, in the git sense, meaning the history still holds every byte of them, but they were gone from the working tree.
Its report was thorough. It explained what each file had contained, why the content now lived somewhere better, and which handful it had deliberately kept. Reading it, I believed it. I also didn’t accept it on that basis. I pulled the actual commit, counted the deletions myself, opened four of the kept files to confirm they were still there, and read eight rows of the new spreadsheet against the original notes they’d come from.
Everything checked out. The agent had done exactly what it said. The point isn’t that it was wrong. The point is that trusting an agent’s account of its own work and verifying that account are two different things, and only one of them catches the case where they diverge.
An agent’s summary inherits the agent’s blind spot
A report written by the same process that did the work will describe that work faithfully from the inside. If the process missed something, the report misses it too, for the same reason. This isn’t a trust problem. It’s a structural one: the summary and the work share an author, so the summary can’t audit the work any better than the work audited itself while it was happening.
I’d dispatched eight agents in parallel earlier the same night, each converting a different repository into the same file format. Every one of them finished cleanly and reported success. Read individually, each report was accurate. Read together, something else was true that no single report contained: none of them had updated the shared tracking document, because each one had correctly assumed the other seven might be touching it and stayed out of the way. The project’s own notes were stale the moment all eight finished, even though every individual agent had done its job exactly right. That gap only shows up when you read the reports as a set instead of trusting each one on its own.
Scale the checking to what could go wrong
I don’t verify everything the same way. A dispatch that only reads and reports gets a plausibility check: does this look right, does it match what I expected to find. A dispatch that deletes hundreds of files, or merges records, or touches anything sensitive gets something closer to an audit: pull the primary evidence, not the agent’s description of the primary evidence, and check a sample of it directly.
The question that decides how hard to check is simple. If this summary is subtly wrong, how would I actually find out, and have I done that specific thing? Not “does the explanation sound reasonable.” Whether I’ve gone and looked.
The paused project’s old number
A separate piece of the same night made the same point from a different angle. I’d resumed a project that had been sitting untouched for a month, and its own notes said fourteen repositories still needed a conversion pass. I ran a two-minute check before believing that number and found it was wrong in both directions: some of those fourteen had already emptied out from unrelated work in the meantime, and a handful of brand-new ones existed that the note had never seen, created by a different project after this one went quiet.
Nothing about the original note was a mistake when it was written. It was accurate the day someone wrote it down. It just stopped being accurate the moment anything else touched the same material, and nothing forced a re-check before I acted on it again. That’s the same failure as the multi-agent case, at a different timescale: a description of reality is a snapshot, and snapshots go stale the instant the thing they describe keeps moving.
What actually changed how I work
Not caution for its own sake. Caution is expensive if you apply it everywhere uniformly, and it teaches you nothing if you apply it nowhere. What changed is a specific habit: before trusting any claim about current state, whether it comes from an agent’s report or a project’s own notes from a month ago, ask what would actually reveal it if that claim were wrong, and go do that thing. Sometimes that’s thirty seconds with git log. Sometimes it’s re-deriving a count from scratch instead of reading it off a document. It is never zero, and it is almost never as expensive as being wrong at scale.
The 474 deletions were correct. I’m glad I checked, and I’d check again, because being right this time tells me nothing about whether I’ll be right next time if I stop looking.