When can an AI agent say the task is complete?

In When an Agent Fails, Should You Change the Model or the System?, we argued that choosing between a model upgrade and a system repair should turn on whether it improves the actual task outcome. This article takes up the next question: what gives an agent adequate grounds to say that the task is complete?

Introduction

An agent has adequate grounds to say it is finished when the evidence supports the result the user actually requested, at the authorized scope, with the relevant constraints satisfied. That is a practical judgment, not an infallible inner sense of being done. Its basis should be inspectable: what was required, what happened, what was checked, and what remains uncertain.

The distinction matters because three things can come apart: the work the agent performed, the result that work produced, and the claim it makes about that result. Writing a file establishes that a file exists. It does not, by itself, establish that the file answers the question. Ending a run establishes that execution stopped. It does not establish either success or failure of the larger responsibility.

Observable results usually give a stronger basis for completion than the agent's narration alone. But observations have scope, tests can be wrong, and self-review can sometimes help. The useful question is therefore not “Did the agent check?” but “What conclusion does this particular check justify?” The sections below define the endpoint, match evidence to it, examine the reliability of the judgment, and use the remaining gaps to decide what should happen next.

What does done mean for this request?

Consider an agent asked to draft an email. A suitable draft may finish the task; sending it would exceed the request. Ask it to send the email instead, and exactly the same draft is incomplete. The endpoint and the permission boundary must travel together.

Even an apparently objective success condition can leave out that distinction. The original 2024 tau-bench evaluates both the final database state and required information in the agent's responses, yet explicitly warns that a successful reward can accompany a policy violation, such as issuing a return without the user's confirmation.[1] The lesson is not that state checks are useless. It is that checking the desired destination does not necessarily check whether the permitted route was followed.

A workable completion target therefore names the deliverable, its important constraints, and the extent of the responsibility. “Make a prototype” and “prepare this for production” are not interchangeable. Neither are “configure monitoring” and “keep monitoring until Friday.” Those examples are distinctions in the request, not technical facts a checker can discover after the agent silently chooses the easier endpoint.

This does not mean asking the user to specify everything. AmbiBench's mobile-task evaluation explicitly treats repetitive questions, out-of-scope questions and requests to approve trivial execution steps as invalid interactions.[2] A useful clarification should resolve a consequential uncertainty: which recipient, which scope, which quality standard, or which stopping horizon? When the answer is already present, asking again adds no missing requirement. When the user changes the goal, the completion judgment should be made against the revised request, not against whichever version is most convenient to claim success on.

For an explanation, report or design, the target may be an assessment rather than a unique state. Anthropic's research-evaluation guidance distinguishes groundedness, coverage and source quality, and says the standards for a market scan, acquisition diligence and a scientific report differ.[3] A report can contain accurate statements and still omit the comparison its reader needs. A visually attractive design can still be unsuitable for its intended audience. Here, “done” means delivering an answer or artifact that meets the task's relevant standard—not turning a subjective judgment into a database equality test.

What evidence shows that the result actually happened?

Once the target is clear, separate evidence of an attempted action from evidence of its effect. A button click may be part of completing a task; it is not necessarily the result the task asks for.

Anthropic's March 2026 application-development report gives a concrete example: during an Opus 4.6 build of a browser music workstation, QA identified an audio-recording feature whose button toggled but did not capture microphone input.[4] Testing the visible control would support “the button responds.” Exercising recording would address the actual feature. The difference is not the number of checks but the behavior they reach.

Software tests provide a more systematic warning. In a SWE-bench Verified patch study, the authors manually assessed 77 patches selected because differential testing—comparing their behavior with the reference patch—had exposed suspicious behavior; they classified 22 as incorrect, four as correct, and 51 as uncertain.[5] This is not an error rate for all generated patches. It shows why both “passed the original tests” and “differs from the reference patch” require interpretation: the former can miss a defect, while the latter need not be a defect at all.

Nor should every positive tool response be dismissed until a separate readback occurs. HTTP makes the distinction precise: RFC 9110 defines 201 Created as a fulfilled request that created one or more resources, whereas 202 Accepted means processing has been accepted but is not complete and might never occur.[6] If the requested endpoint is exactly the resource creation and the service faithfully implements that contract, its response can itself be outcome evidence. If the endpoint is the completed work of an asynchronous job, acceptance is insufficient. Additional observation is needed to support the broader claim, not because readback is a ritual every operation must undergo.

For an assessed artifact, inspect the artifact against the question. If the user asked for a comparison, identify where the alternatives are compared and whether the decisive tradeoffs are supported. If they asked for instructions, check that the steps are usable, not merely that relevant concepts appear. A citation check can address factual support without establishing coverage; a coverage check can establish that topics are present without establishing their truth.

The practical method is to pair each consequential completion claim with observations or assessments sufficient to support it, including its relevant constraints. Keep “generated,” “tested,” “accepted for processing,” and “completed” distinct. Where evidence supports only part of the request, describe that part without promoting it into the whole result.

How trustworthy is the completion judgment?

Matching a check to a requirement is necessary, but the check can still make mistakes. This applies to tests, human reviewers and models—including a model reviewing its own work.

Self-review should not be dismissed as inherently incapable of recognizing correctness. ReVISE tests whether a model can distinguish correct from incorrect answers on the GSM8K reasoning benchmark: its two-stage curriculum raises the reported correctness-discrimination AUROC, which measures how well it ranks correct answers above incorrect ones, from 71% without the curriculum to 76%.[7] That is evidence of improved discrimination in a reasoning experiment, not a 76% probability that a tool-using agent's declaration of completion is true. Improving an answer and reliably recognizing a completed task are different achievements; recognition must be measured, not inferred from improvement alone.

For a completion checker, the relevant question is whether it distinguishes genuine satisfaction from convincing failure in the setting where it will be used. AutoResearchEval provides one example of how to investigate this: on 50 human-labeled research trajectories, its artifact-aware judge reports failure-pattern precision of 85.4% and recall of 80.7%, compared with 70.2% and 63.5% for a transcript-only, single-call judge.[8] Precision concerns how often a flagged failure matches the reference labels; recall concerns how many labeled failures are found. Neither is a probability of overall task success. The comparison also changes both evidence access and judging procedure, so it does not isolate the value of artifact access alone.

The reference judgment needs scrutiny too. That study validates the judge on the same 50-trajectory sample used to refine its taxonomy and does not report per-pattern agreement.[8] Human labels provide a useful comparison, but the validation design limits how much confidence the aggregate score warrants outside that sample.

Tests can err in the opposite direction as well. OpenAI's July 2026 coding-evaluation audit describes a task whose visible instructions require one leading space while hidden tests require two, causing request-compliant work to fail.[9] A failed check is therefore a reason to inspect the mismatch, not automatic permission to change the deliverable away from the user's request. In the patch study, uncertainty persisted because some behavior was not specified well enough to decide whether it was correct.[5]

A usable checker-validation procedure follows from these examples:

1. Assemble representative successes and plausible failures, including partial results and constraint violations. Assess them against the request and the relevant artifacts, preserving unresolved cases instead of forcing a label.
2. Compare checker decisions with those assessments, separating missed failures from false alarms. Examine disagreements and test revised criteria on cases not used to tune them.
3. Repeat the comparison when the task, model or environment changes.

The consequences of a mistaken success claim should determine which unresolved doubts require escalation: uncertainty tolerable in a disposable draft may be unacceptable before an irreversible action. This is a method for earning bounded trust, not a universal numerical release threshold.

Adding a second reviewer is useful only to the extent that it contributes a better-grounded judgment. Two approvals do not explain what either reviewer could see, what requirements they checked, or whether their mistakes overlap. The evidence behind the judgment matters more than the job title “reviewer.”

Should the agent finish, continue, wait, or ask for help?

The next action depends on what remains unresolved. If an authorized, useful step can close a known gap, continue. If the required outcome is still processing, wait through an actual status mechanism. If progress requires a missing decision or permission, ask for it. If a resource limit ends execution, report that limit and the unfinished work. None of these states needs to masquerade as success.

Sometimes restraint is the correct response to the task's constraints. AgentAbstain pairs tasks that require action with minimally changed tasks that require abstention; for operational tasks, its evaluation checks both whether critical actions were withheld and whether the final response communicates abstention.[10] Saying “I cannot proceed” after performing the problematic action does not satisfy that standard. Equally, refusing every task would fail the tasks where acting was appropriate. The boundary is justified action or restraint, not maximal activity or maximal caution.

Continuing indefinitely is not a solution either. The preprint Verify, Repair, Repeat, or Stop? studies loops in which a noisy verifier can reject a valid candidate and a repairer can damage it; its experiments include both harmful-repair settings and a favorable setting where continued repair improves validity.[11] Some stress settings deliberately perturb the problem statement seen by the repairer, so their outcomes should not be read as an ordinary production failure rate.[11] The operational inference is narrower: another iteration should target a reason to doubt the current result, and its proposed repair should be checked against what already worked. Repeating a check or rewriting an answer is not, by itself, additional progress.

Waiting and handing over also need an intelligible status. A2A's versioned key-concepts documentation separates stateful tasks, messages and output artifacts, and provides polling, streaming and push-notification mechanisms for long-running work.[12] These are ways to communicate and resume work, not proof that a declared status is true. A useful handoff tells the recipient what exists, where it can be found, what has been checked, what remains unresolved, and what event or input enables the next step. Handoff completes the responsibility only when handoff was the requested endpoint. Likewise, in an illustrative monitoring assignment, one completed check can finish a cycle without ending the obligation to keep watching.

This yields a practical closing sequence: revisit the current request; inspect the result and constraints; investigate material gaps or conflicting checks; then choose a status whose meaning fits the evidence. Report success only for the supported scope. Otherwise, report the actual result—partial, waiting, blocked, or withheld—and the remaining dependency. “The export job was accepted; the finished file is still pending” is more useful than either a premature “done” or an unexplained refusal to stop.

Conclusion

An agent knows it has finished only in the qualified sense that it has adequate grounds for saying the agreed result was achieved. Those grounds connect the user's current request to the delivered result through checks whose scope and reliability can be inspected.

The important improvement is not a more confident final sentence or an endless review loop. It is a completion judgment that can answer: done with what, on what evidence, and with what still unresolved? Being right to stop does not automatically mean being right to say the task is complete.

Limitations

There is no task-general confidence cutoff established by the evidence discussed here. Coding benchmarks, reasoning experiments, synthetic tool environments and first-party engineering reports test different objects. Their scores cannot be combined into a universal false-completion rate, and the procedures above are an operational synthesis rather than a validated general-purpose algorithm. Genuinely evolving preferences and open-ended continuing responsibilities remain especially dependent on the user's actual terms of acceptance.

Even formal evidence requirements have a boundary. The August 2026 Evidence-Carrying Termination preprint makes its guarantee relative to an adequate requirements contract and a faithful evidence adapter—the component that supplies evidence records; omitted requirements or fabricated records can defeat that basis, and its certificate of completion does not establish external truth, effects, safety or alignment.[13] Better records make a completion claim more accountable. They do not make the world automatically match the record.