AI Agent Says "Done" But Nothing Changed — Why & How to Verify

An agent says “done.” You check. The file is unchanged, the test is red, the deploy never happened. This is not a bug — it’s the verification gap: the distance between what the agent reports and what is actually true. Here’s how to measure it on your own logs in ten minutes, and where the real fix lives.

We measured it on our own notification pipeline. Out of 21 runs, 4 ended in a false “done” — a 19% gap. On a single regression-prone task it hit 100%: every report was wrong. Neither number is unusual.

Guo and collaborators showed in 2017 that modern neural networks are systematically overconfident, and agents inherit the trait. A model that says “95% sure this is done” is, on average, accurate around 70% of the time. Most teams blame the agent. The fix is somewhere else — in the gate.

When the gate covers everything that matters, false-done collapses to zero in our experiments. When the gate has a blind spot — a style rule, an architectural convention, a side-effect on a database — the agent’s confident “done” lives precisely in that blind spot, every time.

The verification gap is a number you can measure today

You don’t need a framework to start. You need two counts: how many times the agent said “done,” and how many of those claims survive an independent check — a re-run from a clean state, not the agent re-reading its own output.

The gap is the fraction of “done” claims that turn out false. That’s it. Our baseline on a notify pipeline was 19% — about one in five completions was a confident lie the agent did not know it was telling. The first time you compute this on your own logs, the number is almost always higher than you guessed, because every false-done you didn’t catch is, by definition, one you didn’t notice.

# The whole metric. One line.
gap = false_done / N

N            = 21   # total "done" claims sampled
false_done   = 4    # claims that failed an independent re-check
gap          = 0.19 # 19% — roughly 1 in 5 was wrong

# Same pipeline, one regression-prone task in isolation:
gap          = 1.00 # 100% — every report on that task was false

The key word is independent. If the same agent that did the work also judges the work, you are measuring its self-report, not reality. The check must read the actual artifact: the file’s bytes, the test runner’s exit code, the row in the database — not the agent’s prose summary of what it believes it did.

Why agents over-claim — it’s not a personality flaw

The instinct is to read a false “done” as the agent being careless or lazy. It isn’t a character trait. It’s a measurable property of the underlying model.

Guo et al. (2017), On Calibration of Modern Neural Networks, found that as networks got deeper and more accurate, they also got more miscalibrated: their stated confidence ran well above their real accuracy. A model that emits “95%” is not lying — it genuinely “feels” that certain. It is simply, systematically wrong about how certain it should be.

Agents inherit this directly. When an agent finishes a task and reports “done,” that report is a high-confidence token sequence generated by the same miscalibrated machinery. The agent has no privileged access to ground truth — it has access to its own activations, which over-state how well things went. So a confident “done” is the expected output, not a malfunction. You cannot prompt your way out of a calibration problem. You can only put a gate outside the model that checks the world instead of asking the model how it feels.

• Stated confidence > real accuracy. “95% done” measured at ~70% true. The number on the label is not the number in the world.
• No privileged access to truth. The agent judges its work from its own activations, which already over-state success.

The real problem is gate blindness, not the agent

Here is the result that reframes everything. Hold the model constant. Change only the gate. The false-done rate moves from zero to most-of-the-time — driven entirely by what the gate can and cannot see.

# Condition A — gate covers everything that matters
gate_checks:   build + tests + lint + side-effects
false_done:    0%   # nothing slips through; "done" means done

# Condition B — gate has one blind spot (a style/arch rule)
gate_checks:   build + tests        # lint + side-effects unchecked
false_done:    80%  # confident "done" lands in the blind spot, every time

The agent did not get worse between A and B. The gate did. In condition B, every false “done” clusters in exactly the dimension the gate stopped checking — the style rule, the architectural convention, the database side-effect. The model’s overconfidence is a constant pressure; the gate is the only thing standing in front of it. A blind spot in the gate is not a place where the agent might fail. It is a place where the agent will report success while failing.

This is why “the agent is bad” is almost always the wrong diagnosis. Swap in a stronger model and the blind spot is still there; the new model just confabulates green in the same gap, more convincingly. The leverage is on the gate, not the model.

The three-level validation ladder

A gate is only as honest as the deepest level it actually reaches. Most false-done reports come from an agent that climbed to level 2, found it green, and stopped — without ever testing the thing the task was actually about.

L1 — Static analysis

Does it compile, parse, type-check, lint? Cheap, fast, necessary — and the easiest level for a confident “done” to hide behind. Green here says nothing about behavior.

L2 — Runtime behavior

Does the code run and produce the right result on its inputs? Most agents stop here. If your task touches the world beyond the function, this level is still a blind spot.

L3 — End-to-end

Did the actual outcome happen — the deploy landed, the row was written, the notification was sent, the file changed on disk? An agent that stops at L2 reports “done” and is wrong, because the thing you cared about lived at L3.

Climb the ladder to the level the task is about. A refactor can gate at L1–L2. A deploy pipeline that doesn’t gate at L3 will ship false-done the moment the deploy step silently no-ops — the tests were green, the deploy never ran, and the agent never knew the difference.

A 10-minute audit you can run on your own logs

You don’t need our tool to find out whether you have a problem. You need your last 20 “done” claims and ten minutes. Here is the exact procedure.

1. Pull your last 20 “done” claims. From agent logs, PR descriptions, task threads — anywhere the agent reported a task complete. Twenty is enough to see the shape.

   grep -i "done\|complete\|finished\|tests pass" agent_log.jsonl | tail -20

2. Independently verify each one. Re-run from a clean checkout. Read the exit code, not the prose. Check the real artifact — the file, the row, the deploy — not the agent’s summary of it.

   # for each claim: did the world actually change?
   git stash && git checkout <commit> && <your real check> ; echo "exit=$?"

3. Plot your gap. Count the false “done”s. Divide by 20. That’s your verification gap. Under 10% and your gate is probably honest. Over 10% and it has a blind spot.

   gap = false_done / 20   # > 0.10  →  your gate has a blind spot to map

If your gap is over 10%, the blind spot is rarely in one place. It’s usually a level of the ladder you never gate (L3), a convention the gate can’t see, and a side-effect nobody checks — all at once. Our harness audit maps exactly which of the six layers around your agent is thin, with evidence from your own logs.