Completion is a claim about a task

Agent work is becoming durable. A request can outlive the connection that created it. Clients can poll later, subscribe to updates, receive a webhook, or retrieve an artifact after the original session has ended. This is a necessary step beyond the fiction that every useful action fits inside one synchronous response.

The latest A2A task lifecycle distinguishes working, interrupted, and terminal states. The November 2025 MCP revision also introduced experimental durable tasks with polling and deferred result retrieval. Protocols are learning to represent time.

Time exposes a harder question: what does completed mean? A protocol state tells the client that the server considers its task finished successfully. It does not prove that the requested change reached the outside system, that every step completed once, that the artifact reflects the final state, or that the caller's real objective was satisfied.

A terminal state closes a protocol obligation

Terminal states are valuable because clients need to stop waiting. Without them, polling continues forever and retries become guesswork. A declared completion point gives systems a shared lifecycle boundary.

But that boundary belongs to the protocol. Consider an agent asked to update three records. It changes two, encounters a policy block on the third, and produces a report. The task might correctly be completed if the contract was “attempt the updates and report.” It should fail if the contract was “make all three records consistent.” The same sequence supports two different terminal states because success depends on the task definition.

The ambiguity grows across agents. A delegating agent may translate a human objective into a narrower remote task. The remote agent completes exactly what it received. The delegator then marks the broader objective complete. Each transition is locally plausible. The end-to-end claim can still be false.

Completed is not a property of activity. It is a claim that an agreed condition became true.

This is why artifacts cannot be treated as automatic proof of success. An artifact shows that something was produced. It may be a plan for an action that never happened, a receipt from one of several targets, or a snapshot taken before a delayed write became visible. The artifact must be evaluated against the completion condition, not merely attached to a terminal status.

Delivery mechanisms create different evidence

A2A supports polling, streaming, and push notifications. Its current specification requires ordered stream events and warns clients that webhook deliveries may be duplicated, so notification processing should be idempotent. These mechanisms can report the same logical lifecycle while producing different observational gaps.

A stream can end after the server generated an event but before the client received it. A webhook can arrive twice. A polling client can miss intermediate states and see only the latest snapshot. None of these behaviors is necessarily defective. They mean that the client must not infer a complete history from a final state.

The task record should distinguish state transitions generated by the server from transitions observed by the client. It should preserve event identifiers where available, retry and delivery attempts, and the artifact version associated with each update. Otherwise a later reviewer cannot tell whether an event never happened, happened but was not delivered, or was delivered and ignored.

Cancellation needs the same care. A canceled task may stop future work while leaving completed side effects intact. A rejected task may have performed validation or disclosed metadata before rejection. A failed task may have partially succeeded. Terminal vocabulary must not erase the state already created in the world.

Define success before submission

The durable task should begin with an explicit completion contract. What state must be true? Which systems must confirm it? Is partial success permitted? Which artifact demonstrates the outcome? How fresh must that evidence be? Who may declare the condition satisfied? These fields need not all live in the transport protocol, but the institution should bind them to the task identifier.

The contract should also define the observation window. Some effects are eventually consistent. A submitted job may be accepted before it is executed; a revoked permission may remain cached; an email provider may acknowledge a message before final delivery. Immediate verification can produce a false failure, while indefinite waiting can turn uncertainty into apparent success. The task needs a deadline and a state for outcomes that remain unresolved at that deadline.

Nested tasks require explicit aggregation. If one child task fails, can the parent complete? If a child is canceled after producing an artifact, may the parent use it? The parent should record the child identifiers and the rule used to combine their states. Otherwise a clean parent status can hide a disputed or incomplete branch that materially shaped the result.

At completion, the server can provide its claim and supporting artifacts. The caller should then perform the checks appropriate to the consequence: compare expected and observed targets, confirm idempotency keys, verify external acknowledgements, or require a human to accept an exception. The remote state and the institutional state may be recorded separately.

This preserves a useful division of labor. Protocols define interoperable lifecycle mechanics. Applications define what success means. Evidence connects the two. No protocol needs to understand every business objective, but no institution should inherit a protocol's terminal flag as its own conclusion without examination.

Durable tasks are an advance because they let work survive the conversation. Durable responsibility requires one step more: a completed state whose meaning survives the agent that declared it.

— Dispatches · Summit Cognitive