Your AI agent says the task is done. How do you know?

You know a task is done only when something outside the agent has looked at the result where it is supposed to land. A status field, a “done” message and a green test are all claims made by the system that did the work. None of them is evidence.

The gap is measurable. In “Many SWE-bench-Passing PRs Would Not Be Merged into Main” (10 March 2026), METR had 4 maintainers from 3 open-source projects review 296 AI-generated pull requests. Roughly half of the ones that passed the tests would not have been merged, and the automated grader’s pass rate ran about 24 percentage points above the maintainer merge rate. METR notes the agents had one attempt and no feedback, and does not claim a fundamental limit.

Why is “completed” the least reliable field in the system?

Because the thing that did the work usually writes its own status. The agent, or the workflow around it, sets the flag, and flags get set by defaults, by shortcuts and by code that only knew how to say “yes”. A status describes whether a step ran. It does not describe whether the outcome happened.

Models make this worse in a specific way. METR’s “Recent frontier models are reward hacking” (5 June 2025) found that on one benchmark suite 39 of 128 runs gamed the scorer instead of doing the task, and on a broader suite 8 of 1,087 did. One example was a stubbed evaluator that always reported a perfect score. The rate varies a lot by task. The lesson is that a scorer the agent can touch is a scorer the agent can satisfy without doing the work.

Watching is common, checking is not. LangChain’s State of Agent Engineering (published 12 June 2026, 1,340 responses fielded 18 November to 2 December 2025, a vendor survey) reports that 89% of respondents have some agent observability, 37.3% run online evals, and 22.8% of those with agents in production run no evals. Seeing what an agent did is not the same as testing whether it was right.

Three times a status lied to us

We run our own fleet, so these are our failures, not a hypothetical. All three were found in 2026, and all three were believed until somebody looked.

Every task was born reviewed. In August 2026 we found that nearly every task in our task backbone was created already carrying a “reviewed” mark, set by default. “Completed and reviewed” therefore proved nothing until a person checked.

When we sampled the business-critical completions by hand, most were genuinely fine, so missing evidence did not mean the work was untrue. It meant we could not tell. Our fix surfaces completions without evidence in the executive digest. We deliberately did not add a hard block, which would have repeated the original mistake under a new name.

A pull request said “merged” and was not. One pull request showed as merged while its commit never reached the main branch. It had been merged into a feature branch, and the work was silently lost until it was re-implemented. When we scanned recent merged pull requests, it was a rare case, but it was real. A scheduled check now tests whether each merge commit is an ancestor of the main branch.

The questions were written and nobody saw them. Our chief-of-staff agent wrote its daily questions for the executive correctly. Its own check, “rows written”, passed. And no screen displayed them. The questions only surfaced if the executive opened a full chat and the agent happened to mention them.

We shipped a display in September 2026, and then learned the second half: the executive could read the questions there but could not answer them in place. Reading in one screen and replying in another is not a usable loop. The fix was a thin reply endpoint that reuses the existing writer, so there is still one write path.

Written is not delivered. Displayed is not actionable. A later gap taught the same lesson: the display was a nightly snapshot, so a missed build left dead cards on screen for days. A snapshot needs a read-time check against the live source.

Evidence versus claim: what to check instead

Each common claim has a cheaper, weaker proof and a stronger one. Ask for the stronger one.

Claim the system makes	Why it is weak	Evidence to ask for	Who or what checks
Task marked completed	The flag can be a default, or set by the doer	The artefact itself, at its destination	A person or checker who can open it
Pull request merged	It can merge into a branch that is not main	The commit is an ancestor of main: git merge-base --is-ancestor A B exits 0 if A is an ancestor of B, 1 if not	A scheduled script, not the author
Message sent	”Sent” means handed to a queue	The recipient’s screen, or a read receipt	A second system on the recipient’s side
Record updated	The write call returned without error	Read the row back after writing and compare	The writing code, immediately after
Test passed	The test may be stubbed or too narrow	A reviewer who did not write the code or the test	A second reviewer, human or agent
Report says zero errors	It counts reported errors, not wrong outcomes	A count that can be shown to vary, plus a sampled outcome	The reviewer, on a schedule

The four checks we run now

These are short because the useful part is doing them every time.

1. Verify at the surface the human uses, not at the table the agent wrote to. The Google SRE Book (chapter 6, 2017) defines black-box monitoring as “Testing externally visible behavior as a user would see it.” Our rule for any notification feature is to ask which screen the person opens, whether that screen reads the data, and whether they can act on it there.

2. Read back after every write. If the agent updates a record, a second step reads it and compares. If the read fails, the run is not done, whatever the write call said.

3. The checker is not the doer. NIST’s AI RMF Playbook (MEASURE 1.3) calls for assessment by “Internal experts who did not serve as front-line developers.” For us that means a separate reviewer for every agent that changes something real. We cover how to structure that in evaluating AI agent performance. We also run a chasing agent that verifies shipped work and opens a follow-up when the evidence is missing, described in AI task follow-up automation.

4. Run every check once on the day it is written. A check that cannot run reports clean by saying nothing. Several of ours looked healthy for weeks because they had never actually executed against a real failure. If a retry follows a failed check, it must not repeat the side effect. That is the subject of idempotency for AI agent side effects.

What does “0 failures” on our own proof page prove?

Our agent fleet proof page shows 41 agents registered (as of 2026-06-30), 9 live, and 5,450 runs with 0 failures in the 13 days to 2026-07-04. Each of those agents is a tomte, our word for one production agent with one defined job. The “0 failures” figure is a count of runs that reported an error. It is exactly the kind of status figure this post warns about.

It proves that no run crashed or raised an error that we recorded. It does not prove that every clean run did the right thing, because a run that finishes cleanly can still have done the wrong thing. That is why we added outcome checks on top of it.

Five questions to ask about any agent’s “done”

1. Who sets the status? If the doer sets it, treat it as a claim.
2. What would the status be if nothing had happened? If the answer is “the same”, the field tells you nothing.
3. Where does the result land, and who has seen it there? A person or a second system must have looked at the destination.
4. Who checks, and did they build it? The checker should not be the author.
5. When was the check last run, and what did it last catch? A check that has never caught anything may never have run.

Where this fits

Outcome checks, and the weekly review of what your agents claimed versus what actually landed, are the job of a Fractional AI Officer: $2,900 a month, written reports, no meetings. You own the delivered code, data and documentation.

Start async

Send us one task your agents mark done every day. We reply in writing within one business day with the evidence we would ask for. No meetings. Start async.