Cancellation is a protocol, not an exception path
Safety in agent systems is defined by the happy path — tool call success, memory persistence, structured output validation. The exception path receives a footnote: "if an error occurs, log and retry." This asymmetry hides one of the most dangerous boundaries in agent design: what happens when you try to stop working.
Agent cancellation works as well as it is designed. With no explicit protocol, stop signals are best-effort signals. The executor has 10 seconds to acknowledge the cancellation and unwind state (a bounded window, not infinite patience) before forceful termination takes over — a SIGKILL-equivalent with its own guarantees. Without either mechanism, an agent can keep working after you want it to.
The two-phase stop
Protocol-based cancellation separates the intent from the execution. First, the orchestrator sends a CANCEL task request — idempotent, acknowledged, and state-machine-tracked. The agent transitions its own internal state to CANCELLING. Second, the executor has a bounded window (10 seconds in the reference implementation) to acknowledge with CANCELLING and perform any teardown — saving checkpoints, releasing tools, closing connections.
The key property: this is a state machine, not a signal bus. The agent acknowledges receipt (CANCELLING), confirms completion (CANCELLED), or transitions to failure (FAILED). Each transition happens on defined edges, meaning you know exactly where the cancellation ended up — and what state was left in when it did.
Why best-effort is insufficient
If cancellation is asynchronous (which it must be, since agent tasks are distributed), then there is a gap between intent and action. During that window: the agent may modify data, produce outputs you didn't expect, or leave shared state in an inconsistent state across systems. Without protocol-based confirmation, you cannot know whether the stop was received or processed.
This creates a fundamental problem for auditability: a canceled agent task has left evidence only if the cancellation itself is traceable through the same chain of authority that governs the live execution. Graceful shutdown followed by hard termination must be recorded as part of the event log.
The exception handling gap
Most agent systems handle exceptions in one direction: "if tool call fails, retry or fail." The reverse — "if orchestrator says stop, what should the agent do with partial results?" — receives far less attention. A running agent that is asked to stop may be mid-workflow at arbitrary points in its own execution chain.
The difference between a safe cancellation and an unsafe one is whether the system can answer three questions after each interrupt: (1) what was the state before I stopped, (2) what is the state now, (3) did I complete any side effects? If you cannot answer at least question 2, the stop signal has incomplete safety margins — meaning the agent's cancellation contract is undefined.