Your AI Agent Needs a Cancellation Contract, Not Just a Stop Button

A stop button is insufficient for canceling an artificial intelligence agent's tasks. Simply pressing a button does not guarantee that all queued work will stop, as there may be tasks already in progress, waiting in a queue, or waiting for external outcomes. The crucial question is whether the agent can prove that no new tasks will start, whether ongoing tasks must complete, and what happened to any interrupted tasks.

To address this, cancellation should be represented as a state machine with clear stages: ACTIVE, CANCELLING, CANCELLED, COMPLETED, and UNKNOWN. The state should be stored durably with a cancel_version that increases monotonically. Workers must carry the version they observed, and dispatches are only valid if the status is still ACTIVE with the same version.

Cancellation checks should occur at every boundary where new work can be created. This includes admission, queue claims, tool dispatch, retry scheduling, browser actions, and outbound delivery. The distinction between cancellation and process liveness is important, as an agent can be alive while its run is cancelled, and can die before recording the cancellation.

Cooperative cancellation is the default, where the worker notices the state change at safe checkpoints and exits cleanly. Forced cancellation provides a deadline for non-cooperative workers. A cancellation timeout should transition the run to UNKNOWN or CANCELLING_TIMEOUT, rather than silently completing or being cancelled, to make the ambiguity visible and prevent duplicate work on restart.

To properly implement cancellation, a compare-and-set operation is recommended instead of a read followed by a write. Workers should require the exact version they observed when dispatching steps. If the update affects zero rows, the worker should not call the tool and should record CANCELLED_BEFORE_DISPATCH.

Test the cancellation feature thoroughly by injecting various failure scenarios and verifying that no unauthorized new effects are created, cancellation intents are recorded, and an operator can explain any UNKNOWN outcomes. The system should also prove that restarts can resume from durable cancellation state, and that tests inject races at every side-effect boundary.

The ultimate goal is not instant termination, but a system that can demonstrate what was prevented, what was already in flight, and what still needs reconciliation. This distinction between cancellation and process liveness is the crucial difference between a simple stop button and a robust cancellation protocol.