Verifying completion before saying “done”

The engineering question

What evidence must exist before an agent tells a user that a task is complete?

A report request can be valid and successfully submitted while the report is still unavailable. The user asked for the finished report. Treating a successful submission as the finished task creates a gap between the agent’s message and the result the user can actually use.

Initial conditions

The user requests a weekly report. No report exists. The tool accepts the request, creates a background job, and returns an acknowledgement. The job then remains pending.

Both variants begin with these conditions. The baseline treats the acknowledgement as enough evidence to announce success. The repaired variant reads the job status, keeps the task open while pending, and verifies the report after a scripted completion event.

In the activity timeline, select the acceptance event and inspect the world panel. Then compare the moment when each variant makes its final claim.

Baseline versus repair

Observation	Baseline	With the repair
Request accepted	Yes	Yes
Pending work recognized	No verification before the final claim	Status checked; task remains open
Status when “ready” is claimed	Pending	Completed
Report when “ready” is claimed	Absent	Exists

These outcomes come from scripted virtual steps, not measured service latency. Polling does not cause the work to finish: in the repaired path, the simulation explicitly advances the worker before the next status check.

Why the repair works

The repair changes the evidence required for the completion message. The agent first sees a pending status and reports that work is still underway. It later observes both a completed job and an existing report before claiming success.

MDN describes HTTP 202 as acceptance for processing, without a guarantee that processing will succeed. The lab uses that distinction to separate a tool-call outcome from the user’s acceptance criterion.

Production considerations

Define “done” in terms of an observable result before designing the agent’s final message. For a report, that might require a completed job and a retrievable artifact associated with the correct request. An independent check should inspect that evidence rather than ask the agent whether it thinks it succeeded.

Microsoft’s asynchronous request-reply pattern describes a status endpoint and guidance for polling, including retry timing. Real implementations also need deadlines, backoff, failure and cancellation states, and a way to report uncertainty. A job that never finishes must not produce an endless wait or an invented success message.

Keep submission errors, status-read errors, and job failures distinct. A transient failure to read status is not evidence that the original job should be submitted again. That decision can reintroduce the duplicate-action problem.

What this does not establish

The simulation guarantees the repaired job will finish at its next scripted worker step. It does not test queues, callbacks, flaky storage, artifact permissions, or real-model behavior. It also does not measure the cost or latency introduced by verification.

For your own workflow, include jobs that complete, fail, time out, and are accepted without ever producing an accessible result. Check the world state at the time of the completion claim. A result arriving later does not make an earlier statement accurate.

The cost of a completed task helps account for verification calls and failed attempts.
How to compare AI models for your application starts with task-specific success criteria.
Retrying without duplicate actions explains why another submission needs careful handling.