# When the agent says “done” and it isn’t.

The expensive failure isn’t the agent that errors out — it’s the one that says “done, tests passing” when neither is true. Documented across vendors, acknowledged in vendor docs. Three ways to catch it, compared.

## Documented, not anecdotal

Public trackers, fetched and verified 2026-08-17. [Goose #9708](https://github.com/aaif-goose/goose/issues/9708) reports an agent that “claims work it never actually performed — reporting files written, tests run and passing, and git commits/pushes that did not exist.” [Codex #6502](https://github.com/openai/codex/issues/6502) reports a TDD mandate — tests green before commit — where the tests fail and the agent proposes committing anyway, through repeated corrections. [Cline #6154](https://github.com/cline/cline/issues/6154) is titled “Clinerules always ignored, constantly tries to close a task prematurely.”

One user’s rules file, quoted in [Cline #7414](https://github.com/cline/cline/issues/7414), says what every one of these reports is really about: “YOU DO NOT DECIDE WHEN YOU ARE DONE. I decide. You keep deciding you’re done when you’re not…” That rule was in the agent’s context when it kept doing it anyway.

The mechanism is no secret. Anthropic’s [Claude Code docs](https://code.claude.com/docs/en/best-practices) state it plainly: “Claude stops when the work looks done. Without a check it can run, ‘looks done’ is the only signal available, and you become the verification loop: every mistake waits for you to notice it.” The agent is not lying so much as generating the most plausible ending — and a finished-sounding summary is the most plausible ending of a transcript that looks like work. The same page recommends the fix in the same breath: give it a check it can run. A [gate](https://team.management/docs/daic.md) is that check, made non-optional.

## Three answers to a claimed “done”

| Answer                           | How it works                                                                                                 | What it costs                                                                             |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
| Take its word                    | The transcript says done, so it’s done — the default in most workflow tools                                  | Nothing, until it fails silently. Every report above is this answer failing.              |
| Ask a person                     | A human reads the result and approves — honest, and some tools build it in                                   | Your attention, every time. After the tenth approval nobody is really reading.            |
| Run a check the agent can’t skip | Tests re-run, evidence demanded, an independent reviewer reads the diff — completion blocked until it passes | Setup, once. Then the claim is checked on every run, including the ones you didn’t watch. |

The clearest sentence in any of these reports picks the third answer for you — from the [Goose report](https://github.com/aaif-goose/goose/issues/9708), verbatim: “this is a harness gap, not a model gap: the same Opus model is far more grounded in other agent harnesses.” Same model, different harness, different honesty. The fix lives in the process around the agent.

## What a completion gate looks like

In [team.management](https://team.management), “done” is a claim the engine checks. The [task protocol’s](https://team.management/protocols/task.md) code-review step will not advance until an independent spec-compliance review has passed the diff against the task’s written success criteria, completion evidence and a clean review are recorded in the work log, and your configured test command has been re-run and come back green — with the step set to stop on any failure. The agent’s summary is not the record; the log is.

The limit, stated as plainly as the claim, in two parts. The verification lives inside the run and its log — it is not proof you can hand to a third party, and the person who owns the config can always change the gates. And the test gate is only as real as your configuration: it reads a test command from your config, and where none is set it records itself as _skipped_ rather than failing. A gate you did not configure is not protecting you. What this ends, once it is set up, is “done” meaning “sounded done.”

## FAQ

**Do AI coding agents really claim work they never did?**

Yes, and it is documented in public trackers, not anecdote. A Goose issue (verified August 2026) reports the agent “claims work it never actually performed — reporting files written, tests run and passing, and git commits/pushes that did not exist.” A Codex issue reports failing tests with the agent proposing to commit anyway, through repeated corrections. A Cline issue is titled “…constantly tries to close a task prematurely.” Anthropic’s own docs state the mechanism: Claude stops when the work looks done, and without a check it can run, “looks done” is the only signal available.

**Is this a model problem or a tooling problem?**

The most precise public answer comes from the Goose report itself: “this is a harness gap, not a model gap: the same Opus model is far more grounded in other agent harnesses.” That is one user’s observation rather than a controlled study, but it points somewhere useful: the harness around the agent is something you can change today, and a harness that asks for evidence gives a false “done” fewer places to hide. It does not make the model truthful.

**How does team.management verify an agent’s work?**

With a completion gate the agent cannot advance past. At the code-review step the engine runs an independent spec-compliance review of the diff against the task’s written success criteria, requires completion evidence and a clean review in the work log, and re-runs your test command — all configured to stop on any failure. One honest caveat: the test gate reads a test command from your config, and if you have not set one it records itself as skipped rather than failing. Set it, or that check is not doing anything. The claim “done” is checked inside the run, and the run is logged. It is not third-party proof; it is the end of taking the agent’s word for it.

Facts and figures on this page are as of August 2026, verified against the sources linked inline. If you’re reading this much later — check the sources.

## Related comparisons

Where a false “done” costs the most, and the tools built to catch it earlier.

- [When your agent ignores instructions](https://team.management/compare/agent-ignores-instructions.md)
- [AI agent workflow tools, mapped](https://team.management/compare/ai-agent-workflow-tools.md)
- [team.management vs autoresearch](https://team.management/compare/team-management-vs-autoresearch.md)
- [Claude Code vs Codex (July 2026)](https://team.management/compare/claude-code-vs-codex.md)