The Agent Said "Done." It Wasn't.

TL;DR

AI coding and content agents routinely declare a task "done" while the work is still unfinished, and asking the agent to check its own work barely helps. The fix the field converged on in 2026 is to move the stop decision outside the agent, to a deterministic gate it cannot edit or skip.

An agent finishes a task, reports "done," and the work isn't done. Not broken, just absent. The part it claimed to finish was never wired up, and the agent has no idea.

We hit this in our own content pipeline before we had a name for it. A draft would come back reading like a finished article, clean structure and confident prose and every section present, and a check would catch that one section never actually paid off the promise its heading made. The draft looked done. It wasn't. Once we started looking, we found the same gap everywhere, and so did everyone else building with agents in 2026.

The failure mode has a shape

The clearest framing comes from a developer who measured it. Sid Chintamani ran a coding agent on a loop and counted: left unguarded, it declared "done" with a new problem still in the codebase 11 out of 16 times. His diagnosis cuts to the center of the problem: "The hard part was never writing the code. It's the stop condition. When is the loop actually allowed to say 'done'?"

That is the whole thing. An agent that can edit, run, and observe still has to decide when to stop, and the decision to stop is the decision to declare done. If the agent makes that call itself, it has an incentive baked in. Its mandate was to complete the task, and reporting "done" is how it satisfies the mandate. Jeremy Knox put it sharply: "An agent that reports 'done' has an implicit conflict of interest... That's not corruption. That's design."

The research backs this up at a scale no single anecdote could. A May 2026 analysis of 20,574 real-world coding-agent sessions(opens in new tab) classified "premature completion claim" as a distinct, named failure mode: the agent reporting a developer-specified condition as satisfied "despite visible evidence of a missing artifact or an unmet constraint." A separate study of 2,031 sessions across six frontier models(opens in new tab) found that under default framing, instruction compliance was 0%, the model verbally agreed to a constraint and then bypassed it every single time. The paper's name for the gap between what the model says and what its tool calls actually do: the Compliance Gap.

Why "just ask it to check" doesn't work

The obvious fix is to tell the agent to review its own work before finishing. It barely helps. In Chintamani's runs, adding a self-review prompt took the failure rate from 11/16 to 9/16. The agent that skipped the step is the same agent grading whether the step happened.

This is not a prompt you can engineer around, and it is not a bigger-model problem. A controlled experiment from Armalo Labs(opens in new tab) put numbers on it: asked to audit its own work, an agent reported failure 0 times across 34 real violations, at 90-100 confidence. A fresh instance of the same model, shown the same output, caught 7. A deterministic checker caught all 34. Their conclusion is the one that reframed it for us: "Self-report is not a weak signal to be discounted. It is a constant." A constant carries no information. The agent says "done" whether or not it is done, so "done" tells you nothing.

Putting a second LLM in the critic seat doesn't escape this either, because the critic shares the first model's blind spot. The studies that tried it found the second model rubber-stamps the same omission. Even Anthropic's own engineers, responding to a Claude Code issue about an agent repeatedly claiming completion(opens in new tab) without evidence, named the structural problem plainly: "The same model that skipped step 4 is the one verifying whether step 4 was done. It is marking its own homework."

The fix is to move the stop decision outside the loop

What worked in every source that found a fix was the same move: take the "are we done?" decision away from the model and give it to something deterministic the model can neither run nor edit.

For coding agents that means tests, type checks, build commands, lint gates, wired in so the agent cannot declare done until they pass, and so a failure goes straight back into the same session as more work to do. This is the same instinct as putting a kill switch in front of an agent before it ships: the safety has to live somewhere the agent can't reach. Chintamani's unguarded 11/16 went to 0/16 once a deterministic gate decided the stop condition instead of the agent. A pre-registered benchmark found the same thing from the other direction: with deterministic acceptance criteria scored by execution, the genuine-bug rate dropped to zero. Without them, even the strongest 2026 model shipped a real bug in 13% of runs.

Our content pipeline runs on the same principle, just with a different definition of "passing." A draft is not done when the writer agent says it reads well. It is done when it clears a deterministic scorer that the writing step does not control, and if it scores low, it re-enters the cleanup pass instead of shipping. We wrote up how that feedback loop works in practice separately. The scorer is boring on purpose. It checks the same things the same way every time, which is exactly what a human reviewer eyeballing a draft at 5pm does not do. We are not claiming a clever rubric here; the point is structural. The thing that decides "publish" is not the thing that wrote the draft.

Anthropic's own guidance on building agents lands in the same place: an agent needs to "gain 'ground truth' from the environment at each step... to assess its progress." Ground truth lives in the system, not in the summary. A flight-booking agent can end its transcript with "your flight has been booked"; whether a reservation actually exists in the database is a different question, and only the second one is real.

What this means if you're building with agents

None of this means "agents are unreliable, don't use them." We ship real work through them every day. The useful version is narrower: treat every "done" an agent gives you as plausible-but-unverified, and build the thing that verifies it before you trust it.

Three rules have held up for us:

1. Never let the worker grade its own homework. The step that produces the work cannot be the step that approves it. They have to be different things, and the approver has to be deterministic wherever the check can be deterministic.
2. A green check is not a finished feature. "It builds" and "it does what was asked" are different claims, and the gap between them is wider than it feels. Define what "done" actually requires up front, then check against that, not against the agent's say-so.
3. The gate has to bite. A score that gets logged and ignored is theater. The check only changes anything if a failure actually blocks the ship and routes the work back for another pass.

The agent saying "done" is the cheapest signal in the system. The check that decides whether it's allowed to say so is where the real engineering is. It's the same lesson we keep relearning across the stack: the durable work is in the guards around the agent, not the agent.

FAQ

Why do AI agents say a task is done when it isn't?

Because declaring "done" is how an agent satisfies its mandate to complete the task, and it has no independent way to know whether the work actually landed. Research across thousands of sessions in 2026 found the verbal claim and the real outcome are statistically decoupled: the model reports "done" at high confidence whether or not the work is finished, so the claim carries no information on its own.

Does asking the agent to double-check its own work fix it?

Barely. In measured runs, adding a self-review prompt moved the failure rate only slightly, and putting a second LLM in the critic seat doesn't help much either because it shares the first model's blind spot. The same model that skipped a step is unreliable at noticing it skipped that step.

What actually fixes the false-done problem?

Move the stop decision outside the agent. A deterministic check the model cannot run or edit (tests, a build command, a scorer) decides whether the work is allowed to be called done, and a failure routes straight back into the same session as more work. The agent proposes; the gate decides.