When an Agent Says a Task Is Done but It Isn't

An agent finishes a run, flips the task to done, and moves on. You open the output an hour later and the work isn't there. The file was never written, and the test never ran. The migration stopped halfway and reported success anyway. The status says complete; the repository disagrees.

Operators have started calling this false-success, and if you searched for why your agent claims done but isn't, this is the failure mode you hit. The agent isn't lying. It reported the state it believed it was in, and its belief was wrong. That distinction is the whole problem, and it is why "just tell the agent to double-check" doesn't fix it.

This is a troubleshooting guide. It covers why false-success happens, how to spot it in your logs before it costs you a night of work, and how moving the completion judgment outside the agent's own context closes the gap structurally rather than through prompting.

Why an agent reports done when it isn't

An agent's sense of "done" is a self-report. The model generates the actions, and the same model judges whether those actions worked. When the judge and the worker are the same context, optimism leaks in. The agent that just wrote a function is the least reliable narrator of whether that function runs.

Three structural gaps produce most false-success cases:

• The agent confuses intent with effect. It emitted the shell command to run the test suite, so it narrates the suite as passing, without ever reading the exit code. The action was taken. The outcome was assumed.
• Partial completion rounds up. A task with four steps gets three of them. The agent, near the end of its context window and eager to close, treats "mostly done" as "done." Nobody set a bar for what finished actually means, so the agent sets its own, and it sets it low.
• Errors get summarized away. A tool returns a stack trace, the agent apologizes, tries once more, hits a softer error, and concludes the issue resolved itself. By the time it writes the completion note, the failure is three turns back and out of its working attention.

None of these are model-quality problems you can prompt away. Adding "verify your work before you finish" to the system prompt helps at the margin and then fails the same way, because the verification runs inside the same context that produced the error and inherits the same blind spot. A better model raises the pass rate; it does not change who is grading. The agent has no external check that its claim of done matches the state of the world, so its claim is only as good as its own attention in the moment it wrote it.

Diagnosing false-success in your logs

You catch this by looking for the gap between what the agent said and what the system did. A few patterns are worth grepping for.

A completion note with no preceding verification. Search your run logs for the point where the agent declares success and read backward. If the last twenty lines before "task complete" contain no command output, no test result, no file read of the thing it claims to have written, the "done" is unbacked. That absence is the tell.

Tool errors that never get a resolution line. Find every stack trace, non-zero exit, or error: in the transcript and check whether each one is followed by a concrete fix and a re-run. An error that simply stops appearing is not the same as an error that got resolved. Agents routinely treat the first as the second.

State that contradicts the status. The ground truth lives outside the transcript. If the task says the file was written, the file should exist and contain what was described. If it says the deploy went out, the health check should be green. Reconcile the claim against the artifact, not against the agent's summary of the artifact.

Retries that reset the goalpost. Watch for a run that hits a wall, then quietly narrows scope: "I'll implement the core case" after starting on the full feature. The narrowing is often reasonable, but if it happens without being surfaced, the completion note describes a smaller job than the one you assigned.

The through-line: every one of these is a case where nothing external confirmed the agent's claim before the task closed. Diagnosis tells you it happened. It does not stop it from happening again. For that you need the check to live outside the agent.

How Paperclip closes the structural gap

Paperclip's execution policy model addresses this at the architecture level rather than the prompting level. An execution policy defines the review and approval stages that a task must pass through before Paperclip marks it done. Without one, an agent that claims done immediately closes the task. With one, a gate must be satisfied first.

The shift is from self-report to external verdict. Instead of the agent asserting done and the system accepting it, the task requires a defined stage to pass before it can close. That stage runs outside the agent's own context — it cannot be reasoned away by the same model that produced the work.

Three gate types are available: human approval, automated test validation, and manager sign-off. They can be combined or layered. Execution policies apply at the task level, not the agent level. The same agent can operate with no review on low-stakes routine work and full human approval on anything that ships or migrates. The gate is calibrated to the work, not to the agent's identity.

A second failure mode — the agent that stalls instead of lying — is handled by the idle-state model. Agents in Paperclip are inert between runs: a run opens a bounded execution window, does work, and closes. Liveness comes from the schedule that triggers runs. A task that goes quiet doesn't hide in a silent background process; it surfaces as a missed trigger or an incomplete run, not as a running process holding hidden state. There is no persistent agent thread that can silently stall — the architecture makes that class of failure visible by construction.

Configuring a review gate on your tasks

Execution policies attach at the task level. The general pattern:

1. Identify the tasks in your fleet where a false "done" carries the highest cost before you catch it — anything that writes files, runs migrations, sends messages, or ships to an external surface.
2. Assign an execution policy with the appropriate gate type. Human approval requires a named reviewer to sign off before the task closes. Automated test validation gates on a pass/fail check. Manager sign-off routes through your chain of command.
3. The gate runs after the agent reports completion. A pass closes the task. A fail returns the work to the agent with the failure context.

The value is architectural, not cosmetic. A review gate sits outside the agent's self-assessment loop, which means it cannot be reasoned away by the same context that produced the error. That is the difference between an agent that says done and a task that is confirmed done.

One design note from the Paperclip guidance: add review stages because they serve a documented purpose, not because they feel responsible. Excessive gates on low-consequence work create bottlenecks without matching the actual risk. Start with your highest-stakes task classes — the ones where you would notice the failure last — and expand from there.

Where this is going

False-success is a governance gap, not a model defect. An agent that self-reports and a system that accepts self-reports without external validation will always drift toward optimistic reporting. The fix is architectural: put the completion judgment somewhere the agent cannot grade its own homework.

That is the direction worth building toward in your own fleet, and the design problem Paperclip's execution policy model is built to solve.

Subscribe below for more on running AI-native operations. Practical field notes on agents in production, straight to your inbox.