How to Know Whether an AI Agent Actually Finished the Task
Verify final state, side effects, and user intent instead of trusting an agent's confident completion message.
Short answer
Treat the agent's final message as a claim, not proof. A task is complete only when an independent check confirms the intended final state, required side effects, and important constraints against the exact task the user approved.
Key takeaways
- Separate what the agent said from what the target system now contains.
- Verify the outcome with a read-after-write check or deterministic assertion whenever possible.
- Score partial completion and constraint violations separately from total failure.
Signs this is the problem
Start by confirming the symptom before changing prompts, models, or infrastructure.
- The transcript ends with 'done,' but no receipt, diff, record ID, or state snapshot exists.
- A tool returned success even though the requested fields, permissions, or downstream effects are missing.
- Reviewers repeatedly reopen supposedly completed work to fix omissions.
Step-by-step approach
- 1
Define the finish line
Translate the request into observable postconditions before the run: which object must exist, which fields must change, which constraints must remain true, and what must not happen.
- 2
Capture the execution receipt
Keep tool calls, arguments, returned identifiers, errors, retries, approvals, and the final response together. Without this chain, a later verifier cannot distinguish real work from a plausible summary.
- 3
Check state independently
Read the destination again through a trusted path. Compare the observed state with the postconditions rather than asking the same agent whether it succeeded.
- 4
Classify the outcome
Use complete, partial, failed, and ambiguous outcomes. Ambiguous means the evidence is missing or stale; it should not silently become a pass.
What to measure
| Metric | What it measures | How to use it |
|---|---|---|
| Verified completion rate | Share of runs whose postconditions are independently confirmed. | Use this as the primary success metric, not self-reported completion. |
| False-completion rate | Runs reported as complete that fail the final-state check. | Any increase is a release blocker for side-effecting workflows. |
| Partial-completion rate | Runs that satisfy some but not all required postconditions. | Use the missing condition to create targeted regression cases. |
Common mistakes
- Using a polite, confident final answer as the completion signal.
- Verifying through the same cached data or tool response that produced the claim.
- Collapsing partial and ambiguous runs into a generic failure bucket.
Practical checklist
- Write observable postconditions before execution.
- Bind approval to the exact target and proposed change.
- Record tool inputs, outputs, retries, and identifiers.
- Perform an independent read-after-write check.
- Preserve failed and ambiguous runs as future test cases.
Frequently asked questions
Can an LLM judge verify task completion?
It can assess semantic requirements, but deterministic state checks should verify facts such as whether a record exists, a file changed, or a permission remained intact.
What if the target system is eventually consistent?
Use a bounded verification window and record the last observed state. If the window expires, label the result ambiguous instead of retrying the mutation blindly.
Should every agent action have a verifier?
Prioritize high-impact, irreversible, customer-visible, and compliance-sensitive actions. Low-risk drafting can use lighter evidence until publication or mutation time.