A Completed Agent Task Needs an Acceptance Contract

An agent says it is done.

That statement can mean at least four different things:

• the agent has no more planned steps;
• a workflow reached a terminal status;
• the agent produced an artifact that appears plausible;
• the assigned objective has been checked and accepted.

Those are not interchangeable.

For a short, tightly bounded task, the difference may not matter. For a long-running agent that researches, uses tools, revises work, waits for input, and may prepare consequential effects, it matters a great deal. A process can end because it succeeded, failed, timed out, was cancelled, or ran out of useful options. An artifact can look finished while relying on stale evidence or an invalid assumption. A task can show partial progress that deserves to be retained without being labeled complete.

The system needs a way to separate a terminal event from an acceptance claim.

A closed workflow and an accepted outcome are different states

Temporal’s workflow-execution documentation describes Workflow Execution status as Open or Closed. Its Closed statuses are Cancelled, Completed, Continued-As-New, Failed, Terminated, and Timed Out. That taxonomy describes execution lifecycle; treating user acceptance as a separate layer is this article’s proposed design inference.

That vocabulary is useful for agent products even if they use no workflow engine. It shows why “the process stopped” is not a sufficient user-facing answer.

An agent task can be:

• Task condition: Work is still active — What the agent may truthfully say: “The task is in progress” — What it must not imply: That its current plan is guaranteed to succeed
• Task condition: Work is paused or held — What the agent may truthfully say: “The task needs a decision, dependency, or review” — What it must not imply: That nothing remains to be resolved
• Task condition: A process reached an end state — What the agent may truthfully say: “This attempt completed, failed, was cancelled, or timed out” — What it must not imply: That the user objective was met merely because execution ended
• Task condition: Evidence satisfies the acceptance conditions — What the agent may truthfully say: “The task is complete under these stated checks” — What it must not imply: That there are no remaining limitations or uncertainty

This distinction protects users from false completion and helps systems preserve valuable partial work. It also gives teams a clearer surface for review: they can ask whether the task satisfied its contract rather than only whether a model emitted a final message.

The Completion Certificate

The Completion Certificate is a proposed record created when an agent believes a task can transition from active work to complete. It is not a hidden-reasoning dump, a copy of private context, or a guarantee that the result will remain correct forever. It is a concise, user- and reviewer-readable claim about why the task can be treated as complete now.

• Certificate element: Objective — Question it answers: What outcome was the task supposed to achieve? — Why it matters: Prevents a polished artifact from substituting a different goal
• Certificate element: Acceptance conditions — Question it answers: What observable checks define sufficient completion? — Why it matters: Makes “done” testable instead of intuitive
• Certificate element: Evidence and artifacts — Question it answers: Which results support each important acceptance condition? — Why it matters: Lets a reviewer inspect the basis without replaying the entire run
• Certificate element: Scope and freshness — Question it answers: Which inputs, constraints, and time window does the claim cover? — Why it matters: Avoids presenting a time-bounded result as timeless
• Certificate element: Effect disposition — Question it answers: Were external effects only proposed, applied, blocked, or reconciled? — Why it matters: Separates an artifact from a consequential change
• Certificate element: Known limitations — Question it answers: What is incomplete, uncertain, out of scope, or dependent on later confirmation? — Why it matters: Turns uncertainty into useful information rather than silence
• Certificate element: Verifier role or mechanism — Question it answers: Which authorized role, automated check, or review state evaluated the acceptance conditions? — Why it matters: Distinguishes self-report from independent or human review without encouraging personal-name retention
• Certificate element: Completion time and lineage — Question it answers: Which task state does this certificate close? — Why it matters: Makes later corrections, retries, and handoffs traceable

The certificate should include references and concise summaries, not unnecessary private data. If an acceptance check depends on sensitive material, the record can say that a permitted check passed without copying the underlying payload into a broadly accessible task log.

Why self-assessment needs an external shape

The LongHorizon-Harness preprint argues that keeping execution, task state, and the agent’s completion judgment in one expanding context makes state harder to track and can let mistaken self-evaluations influence later choices.

Our proposed design response is to move the completion claim into a structure that can be checked separately from the agent’s moment-to-moment narrative.

For example, a coding task might require:

• a requested behavior exists;
• relevant checks or tests support that behavior;
• the change is limited to the agreed scope;
• unresolved failures are disclosed; and
• a proposed external change remains un-applied until the required approval exists.

A research task might require:

• the primary question is answered;
• material claims are linked to current sources;
• competing explanations or uncertainty are stated where relevant;
• the output does not go beyond the evidence; and
• any recommended effect is clearly separated from the analysis.

The checks vary by task. The design principle does not: define the conditions before treating an answer as complete.

Partial progress deserves its own state

A binary completed-or-failed model loses useful information. The Long-Horizon-Terminal-Bench preprint uses fine-grained grading to capture intermediate progress and partial credit that a single final-outcome score can miss. Applying that evaluation insight to task dispositions is this article’s inference.

For users, that distinction is practical. An agent may have:

• gathered verified evidence but not finished a synthesis;
• localized a problem but not produced a validated change;
• prepared a safe proposal but be waiting for approval;
• completed some acceptance checks while another is blocked by a dependency; or
• found that the objective cannot responsibly be met with current authority or information.

None of those states should be mislabeled as complete. Nor should they be discarded as failure.

The Completion Certificate can support a more honest disposition:

• Disposition: Complete — Meaning: All stated acceptance conditions are met within the recorded scope
• Disposition: Complete with limitations — Meaning: The core outcome is met, and material limits are explicit
• Disposition: Partial — Meaning: Valuable accepted artifacts exist, but the full objective remains open
• Disposition: Held — Meaning: A missing decision, dependency, or authority prevents safe completion
• Disposition: Unverified — Meaning: The agent produced a candidate result but lacks sufficient evidence to claim acceptance

This is not extra bureaucracy. It is a way to prevent an agent’s final sentence from hiding the actual state of work.

Bind completion to the current task state

Completion is always about a particular version of a task.

If a user corrects the objective, a source changes materially, an approval expires, or a new constraint narrows the allowed outcome, an earlier Completion Certificate may no longer apply. The certificate should not silently survive that change as a permanent badge.

This is why the record needs lineage and freshness:

1. Identify the task state the certificate evaluated.
2. Record the acceptance checks and their supporting artifacts.
3. Mark the scope and conditions that would require revalidation.
4. When a material correction or dependency change arrives, mark the certificate superseded, still valid, or pending review.

The result is a system that can say, “This work was accepted under this scope,” rather than, “The agent once said it was done.”

Measure the gap between claimed and verified completion

Teams can use the certificate to improve reliability without pretending that one metric captures everything.

Useful measures include:

• Claim-to-verification gap: How often does an agent declare completion before the stated checks pass?
• Acceptance evidence coverage: What share of material acceptance conditions have linked supporting evidence?
• False-completion recovery time: How quickly is an invalid completion claim detected, explained, and corrected?
• Partial-work salvage rate: How often can valid artifacts be retained when a task cannot reach full completion?
• Completion-scope drift: How often does a later correction reveal that the original acceptance claim covered the wrong objective or constraint?

These measures are not a substitute for task-specific quality judgment. They make completion behavior visible enough to improve.

A practical adoption path

1. Choose one agent workflow where a mistaken “done” state would be costly or confusing.
2. Define a small set of observable acceptance conditions with the task owner.
3. Decide what evidence can support each condition without exposing unnecessary private information.
4. Add dispositions for partial, held, and unverified work.
5. Require a Completion Certificate before the system presents a high-confidence completion message or advances to a consequential next stage.
6. Review false completions and retained partial work to refine the contract.

The goal is not to make agents ceremonious. It is to make their strongest claim—the claim that the work is complete—worthy of trust.

A general lesson for long-running agents

For long-running agent workflows, completion should be an inspectable claim tied to explicit acceptance conditions. The Completion Certificate is a proposed educational framework, not a description of a shipped Virillio Code capability.

Sources and further reading

• Workflow Execution — Temporal — Temporal documents Workflow Execution status as Open or Closed and lists Cancelled, Completed, Continued-As-New, Failed, Terminated, and Timed Out as Closed statuses.
• LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks — A recent preprint frames long-horizon execution as task-state management and reports risks when execution, task state, and completion assessment share a growing context.
• Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading — A recent preprint uses fine-grained grading to capture intermediate progress and partial credit beyond a single final outcome.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.