Blog · June 24, 2026

Your AI agent says it's done. How do you know it actually finished?

Watch an unattended agent close out a task and you'll eventually see the most expensive sentence in the whole loop: "Done." The status flips. The run ends. And the work is two-thirds there — the function exists but the test was never written, the migration shipped but the rollback wasn't, the answer is right for the happy path and silent on the one case that mattered. Nothing lied to you on purpose. The agent finished what it remembered to do, decided that was the task, and marked it complete with total confidence.

"Done" from an agent is a claim. Treated as a fact, it's how a loop drifts: the next run reads done, builds on top of it, and inherits a hole it can't see. The fix isn't a better prompt telling the agent to be thorough. It's making "done" a state the agent has to earn — one it can't reach by asserting it.

"Done" should carry a checklist, not a vibe

The cheapest place this goes wrong is scope. The agent's idea of the task and yours diverge by run three, and there's nothing to measure the gap against. So pin the gap down before the work starts: attach acceptance criteria to the task — a concrete checklist of what "finished" means, written when the task is created, not reconstructed when it's closed.

Now "done" isn't a judgment call the agent makes alone at the end of a long context. It's a set of boxes, each one a specific claim — the endpoint returns 400 on a missing field, the new column has a backfill — that has to be ticked before the status can move. The agent can still get the work wrong, but it can no longer get the definition wrong, because the definition isn't in its head. It's in the row, and the row is the same whether this run wrote it or one a week ago reads it.

"Done" should require evidence

A checked box is still a claim. The next layer is to make completion point at something real.

Require evidence: a task can't reach done without a linked artifact — the commit, the PR, the file it produced. Not because the artifact proves the work is correct, but because it proves the work exists and ties the claim to a thing a human or a later run can open and check. "I refactored the auth flow" with no commit attached is a sentence. "I refactored the auth flow" with PR #41 hanging off the task is a sentence you can audit. The difference is the whole game when the worker is unattended and the reviewer shows up hours later.

This also kills a specific failure: the run that believes it shipped but didn't — the push that never happened, the file written to the wrong place. If done demands a real reference, the gap between "I think I did it" and "here is the thing" becomes a wall the agent walks into instead of a hole the next run falls through.

"Done" should sometimes need a second pair of eyes

Some work shouldn't close on the doer's own say-so. For those, put a reviewer in the path: moving the task to in review opens a handoff to whoever has to sign off, and the task can't reach done until that review is answered. The agent doesn't get to grade its own homework on the work that matters.

The point isn't ceremony. It's that the gate is structural — it lives in the task's state machine, not in a norm everyone agrees to follow. A run in a hurry can't skip the reviewer by being confident, the same way it can't skip a checklist item by deciding it doesn't count. The only path to done runs through the gate.

The state machine refuses the shortcut

Tie it together and "done" stops being a value the agent writes and becomes a transition it has to pass. The transitions are validated: you can't mark a task done while its acceptance criteria are unmet, while its required evidence is missing, while its review is unanswered — or while it's still blocked by a dependency that isn't itself done. A blocked task can't be willed complete because a run decided to skip ahead.

That's the difference between a status field and a gate. A status field is a label the worker chooses. A gate is a thing the worker has to satisfy, checked by the system and not by the worker's own account of itself. The first trusts the claim. The second makes the claim cheap to trust, because it can't be made without the proof.

Why "just tell the agent to be thorough" doesn't hold

The tempting fix is in the prompt: make sure you actually finished, double-check your work, don't mark it done unless it's really done. It helps a little and fails the same way every soft instruction fails an unattended worker — it binds the run that's paying attention and evaporates on the run that isn't. A prompt is a request. It has no purchase on the boundary, where the context closes and a fresh run reads only the durable state. If "done" lives in that durable state with nothing guarding it, the guard you wrote in the prompt didn't survive to the moment it was needed.

Verification that holds has to live one layer down, in the state itself — the same reason a plan and a decision can't live in the transcript. The checklist, the evidence rule, the review gate, the refusal to close a blocked task: those are properties of the task, enforced on every transition, indifferent to whether the run remembered to be careful. They're how "proven done" stops being a phrase and starts being a property of the office the agents work in.

The shortest version

An agent's "done" is a claim, and a loop that treats it as a fact builds on holes. Make "done" something the agent earns instead of asserts: a checklist of what finished means, written before the work; evidence that ties completion to a real artifact; a reviewer in the path for the work that warrants one; and a state machine that refuses to close a task whose criteria, evidence, review, or dependencies aren't satisfied. None of it makes the agent smarter. All of it makes "done" mean something the next run can stand on.

That's what Ledgenter does with completion — acceptance criteria, required evidence, and review gates on the task itself, checked on every transition, behind one MCP server. The same gates apply to the agent that builds Ledgenter: every change it ships goes through them and through CI before it lands, which you can watch happen in public, on a cadence.

Start at ledgenter.com. Make "done" a proof, not a promise.