The Agent Says Done. What Does Done Mean?

START WITH THE MECHANISM

Interactive companion and laboratory update: 12 November 2026. The editorial date places the topic on the timeline; this current explanation and its measured evidence retain their actual preparation and execution dates.

THE FULL INVESTIGATION

The Agent Says Done. What Does Done Mean?

Dates and technology context

This is a retrospective editorial timeline. Topic context: 24 December 2025. First publicly available: 12 November 2026. Current text, visuals and laboratory revisions were prepared on 12 November 2026.

Contemporary code examples distinguishing stopped, produced, verified and complete were made in November 2026 and must not become December 2025 execution claims.

Prepared on 12 November 2026, this retrospective essay considers agent completion as of 24 December 2025; no earlier publication is implied.

The word done is a promise about a boundary. It says that some agreed obligation has been satisfied and that another person can safely move on.

In ordinary collaboration, the boundary is often implicit. A colleague understands the surrounding project, the meaning of the request, and the standard expected by the team. Even then, misunderstandings occur. With an AI agent, a confident completion message can arrive without the shared understanding that makes the word useful.

The agent may have produced files, passed a narrow check, or exhausted the visible steps in its plan. None of those observations automatically establishes that the requested outcome exists.

My argument is that completion should be treated as a claim requiring evidence at the boundary the user actually cares about. A good agent workflow makes that boundary explicit before work begins and preserves enough evidence for someone else to assess it afterward.

This is not a demand for endless testing. It is a demand that the meaning of done remain connected to the job.

A plausible success that stops too early

Consider a hypothetical request to add an export button to an internal application. The agent edits the interface, implements an endpoint, and confirms that a request returns a file. It reports completion.

The user opens the application on a narrow screen and cannot reach the button. Another user downloads a file whose columns do not match the agreed format. A third receives data they should not be authorized to export.

These are invented examples, not findings from a particular system. They illustrate three different boundaries: access to the interaction, correctness of the artifact, and permission to obtain it. A check of the endpoint alone does not establish all three.

The agent did not necessarily fail because it lacked intelligence. The workflow may have defined success through the easiest observable fragment of the task.

This is a common temptation in automation. A local signal is convenient and repeatable, so it gradually becomes a proxy for the larger outcome. The proxy then acquires a reassuring name: verified, complete, ready.

The repair begins by asking what a user must be able to do after the work. That question should determine the relevant checks, rather than allowing the available checks to determine what the task is assumed to mean.

The completion statement is not the observation

01 / See the idea

A completion claim needs an observation

Enlarge diagram

An agent can summarize its work fluently. It can list files, describe intended behavior, and explain why the implementation should succeed. These are useful communication abilities. They are not independent evidence that the behavior occurred.

The distinction matters because explanation can create the feeling of closure before the work has crossed the required boundary. A reader may see a coherent account and assume that its factual premises were observed.

An effective completion report should separate actions from observations. Editing a configuration is an action. Seeing the running service load that configuration is an observation. Writing a test is an action. Executing it successfully in the relevant environment is an observation. Preparing a deployment is different from completing one.

The report should also distinguish observed failure from missing evidence. If a check was not run, that does not prove the implementation is broken. It means the relevant claim remains unverified. This difference allows a user to make a proportionate decision without being misled in either direction.

The discipline is simple but demanding: do not let a description of intended behavior masquerade as a result.

Completion was already an engineering problem

Anthropic's November 2025 engineering account describes long-running agents that could prematurely regard a partly implemented project as finished. The account discusses explicit feature status, verification, and durable progress artifacts as ways to improve continuity. It is a vendor report, not a universal reliability benchmark, but it makes the failure mode concrete. Effective harnesses for long-running agents.

The broader lesson is not tied to a particular SDK. A system doing work over time needs a representation of what remains, a way to distinguish attempted work from accepted results, and a reliable handoff when context changes.

Human teams need these things too. Agents make the need easier to notice because their confidence can remain high while their context is incomplete.

That observation should lead to better workflow design, not theatrical distrust. An agent can be highly useful while still requiring an external definition of the outcome it is supposed to deliver.

Write acceptance in the language of the request

Acceptance criteria are most useful when they describe an observable result rather than restate an implementation plan. The export example should say who can obtain which data in what format, not merely that a button and endpoint must exist.

The implementation can then change without changing the promise. Perhaps the interface uses a menu instead of a button. Perhaps a large export becomes an asynchronous job. Those choices may be appropriate if they satisfy the agreed behavior and introduce no unaccepted consequences.

This also clarifies when the agent should ask for judgment. If the original request leaves a consequential ambiguity, such as which records a user is entitled to export, the agent cannot resolve it merely by producing a technically plausible default. The missing information belongs to the decision boundary.

Other ambiguities are ordinary implementation choices. The agent should be able to resolve those within the authorized scope and continue. Requiring human confirmation for every reversible detail would make delegation ineffective.

A useful contract therefore distinguishes the outcome that must be preserved, the choices the agent may make, and the decisions that require additional authority. Completion becomes easier to assess because the work has a defined shape.

Verification must have a stopping rule

02 / A concrete example

One export endpoint is not the whole task

Enlarge diagram

Once verification becomes important, another failure mode appears: the agent keeps checking. It repeats successful tests, broadens the scope, creates more review tasks, and delays delivery because certainty can always be improved.

That behavior can look conscientious while failing the user's request. A system that never accepts sufficient evidence cannot reliably finish.

The stopping rule should follow the original acceptance boundary. If the relevant checks have passed, the required observations exist, and no new material concern has appeared, the agent should deliver the result. Additional testing needs a reason connected to an unresolved risk or a changed implementation.

The rule must also preserve failures. A successful check of one part cannot erase a failed or missing required check elsewhere. If the export works for an administrator but the task includes ordinary users, the administrative success does not close the whole task.

This creates a balanced standard. The agent should neither substitute a convenient partial result for the requested outcome nor keep working indefinitely after the outcome has been demonstrated.

The user benefits from both forms of discipline. Reliable completion includes knowing when the evidence is insufficient and when it is sufficient.

A handoff should preserve decisions, not everything

Long tasks create continuity problems. Another session, agent, or human may need to resume the work. The handoff should preserve the facts needed to continue without repeating accepted work or losing unresolved obligations.

That usually means the intended outcome, important constraints, completed evidence, remaining work, and ownership of active resources. It does not mean saving every intermediate thought.

In the hypothetical export task, a useful handoff could say that the format has been accepted, authorization remains unresolved, and a particular interaction check has passed in the supported browser. The next worker can continue from that state rather than infer progress from the presence of code.

The distinction between accepted evidence and attempted activity is essential. A file named final does not establish that it was reviewed. A log containing a command does not establish that the command succeeded. A test report from an earlier implementation may no longer describe the current one.

Preserving this state makes collaboration more efficient because it prevents both omission and redundant effort. It also makes the final completion statement auditable without requiring the user to inspect every detail of the process.

The case for trusting a capable agent

03 / Watch the mechanism

Done requires the agreed checks together

Enlarge diagram

Static view. Play to see how the mechanism unfolds.

A reasonable objection is that all this structure could remove the benefit of an intelligent assistant. If the user must specify every condition and inspect every result, they might as well do the task themselves.

The answer is to let the agent perform much of the structuring. It can translate a request into proposed acceptance criteria, identify relevant checks, gather evidence, and produce a concise completion report. The human need not manually supervise each operation.

The crucial point is that the structure must remain connected to the user's purpose. The agent should not silently narrow the request to fit what it happened to complete, or expand it into a larger project because additional work seems useful.

Trust can grow through bounded autonomy. Give the agent room to act within a clear scope, then assess the observable result. Where consequences are reversible and easy to inspect, that scope can be broad. Where authority or interpretation is consequential, the workflow should make the relevant human decision visible.

This is more practical than treating trust as a single yes-or-no judgment about the model. Different tasks require different evidence and different permissions.

Stopped, blocked and complete are different outcomes

01 / See the idea

Execution ended: what is now established?

Enlarge diagram

A process can stop because it succeeded, because it failed, because it lacks authority, or because another attempt is unlikely to produce useful information. The fact that activity has ended tells us little about which outcome occurred.

This distinction matters for an agent because its final message often serves as the handoff. If every stopping condition becomes a confident summary of progress, the recipient has to infer whether the requested result actually exists. The agent may have behaved sensibly in stopping and still communicate the outcome badly.

Consider a hypothetical data export. The agent has prepared the code and verified the format, but it cannot establish which records an ordinary user is permitted to receive. Stopping before release may be correct. Calling the whole task complete would be incorrect. The remaining decision belongs to an authority boundary that code generation cannot resolve.

A useful report would identify the completed parts, the unresolved condition and the person or evidence required to continue. It should not bury the missing condition beneath a list of successful actions. Nor should it describe the entire attempt as worthless when useful work has been preserved.

The distinction also protects against endless effort. An agent that recognizes a missing external decision should not manufacture more internal tasks to avoid admitting the dependency. Additional activity is not progress when it cannot change the blocking condition.

Complete means the agreed outcome is established. Blocked means a required condition cannot currently be resolved within the available authority or information. Stopped means execution ended and needs a more specific explanation. Keeping those meanings distinct makes delegation easier to trust.

A useful status should also distinguish an unknown result from a confirmed failure. If an external operation loses its reply, the agent may lack evidence about what happened. Repeating the operation could create a second effect, while announcing failure could mislead the person who must reconcile the first one.

The immediate task may therefore become establishing the outcome rather than continuing the original sequence. That is a legitimate change in the next action, but it should remain connected to the user's goal. The agent should explain what is unknown, which observation can resolve it, and whether it has the authority to obtain that observation. A clear account of uncertainty is more useful than choosing a decisive label merely to make the handoff feel finished.

Evidence can expire while the artifact remains

A test result belongs to the thing tested under the conditions in which it was tested. If the implementation changes, the environment changes, or the relevant requirement changes, an earlier result may no longer establish the current claim.

This seems obvious until work spans several sessions. An agent may find a report marked successful and assume it closes a requirement. The report may describe an earlier revision, a different configuration or only one part of a larger task. Its existence is a fact; its applicability is another question.

In a hypothetical application change, the export format passes a check before the agent modifies the filtering logic. The format check may remain valid, while the evidence about which records appear needs renewal. Repeating every earlier check would be wasteful. Reusing every earlier result would be unsafe. The useful distinction is which claim the new change could invalidate.

A handoff should therefore connect evidence to a revision, environment and acceptance question. This need not require a heavy system. A clear record can state what was checked, what changed afterward and which obligations remain open.

The same logic applies to human approval. Approval of one proposed action should not silently become approval of a different action that happens to occupy the same place in the workflow. When the meaningful object changes, the system must decide whether the prior authorization still applies.

Completion is consequently not a permanent property attached to a file name. It is a judgment about an outcome under specified conditions. Good automation preserves enough context for that judgment to remain intelligible when the work is resumed.

A smaller completed task can still leave the request unfinished

Agents can be good at decomposing a request into steps. Decomposition becomes misleading when success at the steps is allowed to redefine the original request.

Suppose a user asks for a report they can use in a meeting. The agent collects information, creates a document and checks that the file opens. The document contains unresolved placeholders and does not answer the decision the meeting is meant to make. Several subtasks are complete; the requested outcome is not.

The remedy is to preserve a link from each subtask to the acceptance boundary. The question is not only whether the document exists, but whether it serves the agreed purpose. An agent should not quietly substitute an easier outcome simply because that outcome is more convenient to verify.

There is an opposite danger too. The agent may keep adding optional improvements after the requested result is already established. It can transform a bounded job into a larger project, delay handoff and consume the user's attention with decisions they never asked to make.

Both failures lose the same reference point: the user's actual goal. One narrows it without authorization; the other expands it without necessity. A disciplined workflow keeps required work separate from optional improvements and makes a material scope change explicit.

This is not an argument for rigidly following a poor initial plan. New evidence can reveal that the plan is insufficient. The agent should adapt the work while preserving the intended result, rather than treating either the original checklist or the latest discovered possibility as the goal itself.

Later code makes the neighboring milestones concrete

Contemporary laboratory note, prepared 12 November 2026. These examples were produced after the essay's December 2025 context.

The reusable-source laboratory separates a completed operation from a consumed result. Its educational provider rejects reuse while the prior result remains unconsumed, and also rejects a reentrant begin while completion is still being published. The executed checks make those boundaries visible in code.

The segmented-parser laboratory distinguishes examined input from committed progress. Looking at bytes is not equivalent to having accepted a complete message. Its correctness work includes deliberately varied boundaries and endings rather than only a single convenient input.

These are not demonstrations that software state machines can solve the semantics of every human request. The analogy is narrower: two milestones can be close together and still carry different obligations. Collapsing them makes later behavior harder to reason about.

For an agent, writing a file, observing a check, satisfying an acceptance criterion and communicating completion are similarly related but distinct. A useful workflow should know which transition it has actually observed.

The laboratories also illustrate why evidence needs a scope. Their passing tests concern the included implementations and declared scenarios. They do not validate every application that uses the same runtime features. An agent reporting such work should preserve that limit instead of turning a specific successful run into a universal assurance.

Completion should transfer control cleanly

The final handoff is an interface. Its recipient needs to know what they can now rely on, what remains uncertain and whether any activity is still running on their behalf.

This last question is easy to overlook. A task can produce its main artifact while leaving a browser, process or temporary service active. Sometimes that is intended. Sometimes it is an accidental obligation the user inherits. A responsible handoff states the relevant resource state rather than assuming that the absence of visible activity means the work is closed.

The report should be proportionate. A small prose correction does not need a long operational ledger. A task that builds and tests software across several environments may need links to the actual evidence and a clear account of unrun checks. The form should help the user decide what happens next.

The agent should also stop when the evidence is sufficient. A completion report that immediately launches another unsolicited improvement undermines the boundary it just declared. Optional follow-up can be proposed separately without making the accepted result feel provisional forever.

Clean transfer of control is therefore part of what done means. The result exists, the relevant obligations have been assessed, and the user can take over without discovering hidden work or unexplained gaps.

Make done useful again

A good completion message should allow the recipient to decide what happens next. It should name the delivered outcome, identify the evidence that matters, and state any remaining limitation that changes the decision.

It need not be long. The detailed evidence can live in artifacts linked from the report. Brevity becomes trustworthy when it compresses verified work rather than conceals missing work.

The next time an agent says done, ask which boundary the word refers to. Did the user-visible outcome occur? Were the required checks actually executed? Can another person understand what remains without reconstructing the entire interaction?

Then ask the complementary question: if those conditions are satisfied, are you prepared to accept the result and stop?

Delegation works when completion is neither a persuasive sentence nor an unattainable ideal. It is a decision supported by enough observable evidence to move the work forward.