Your Agent Needs a Cancellation Contract, Not a Stop Button

A stop button feels reassuring until the agent has already touched the world.

It is easy to imagine cancellation as a user-interface feature: the human clicks stop, the spinner disappears, and the agent stops talking. That model works when the only thing being canceled is a text generation. It breaks down the moment the agent can call tools, reserve inventory, draft or send messages, update a ticket, hand work to a subagent, trigger a deployment, or wait on a vendor API that may still complete after the visible run is gone.

For production agents, “cancel” is not a button. It is a contract.

A cancellation contract defines what the system promises when someone interrupts an in-flight run. It answers questions the interface cannot answer by itself: which phase was the agent in, which side effects may already have happened, whether stopping now is safe, whether authority has been revoked, whether a compensating action is required, whether the work can resume later, and what evidence proves the final state.

Without that contract, cancellation creates a dangerous illusion. The user believes the work stopped. The agent runtime may believe the run ended. But the external system may still be processing the request. A payment provider may still settle. A CRM update may already be committed. A browser action may have submitted a form. A subagent may continue operating with stale context. A retry may begin because the parent run never received a clean result.

That is how a stop button turns into an incident.

The Model Context Protocol is useful evidence that agent infrastructure is moving beyond silent request-response flows. MCP includes a cancellation utility for notifying the other side that an in-progress request should be canceled, and a progress utility for reporting progress during long-running operations. Those protocol primitives matter because they treat in-flight work as something observable and controllable, not as a black box that eventually emits success or failure.

But a protocol notification is not the same as an operational guarantee. A cancellation request may arrive before a tool starts, while a tool is running, after a remote system has committed, or after the local runtime has lost visibility. The receiving side may be able to stop immediately, stop at a safe boundary, or only report that the action already completed. The contract around cancellation is what tells the product and the operator which of those states they are in.

The first field in that contract is the run phase. “Thinking,” “reading,” “awaiting approval,” “calling external API,” “committing side effect,” “waiting for callback,” “handoff in progress,” and “finalizing receipt” should not all share the same cancellation behavior. Canceling during a read-only evidence-gathering phase may be harmless. Canceling while a side-effecting tool is committing may require waiting, verification, or compensation. Canceling while a human approval is pending may mean the approval is withdrawn rather than the business action reversed.

The second field is a safe boundary. Every meaningful workflow should define where interruption is allowed without creating ambiguity. Before a tool call is a boundary. After a verified tool response may be a boundary. Between a reservation and a confirmation may not be. If the workflow has no safe boundary, the system should be honest: the request can be marked for cancellation, but the runtime must first reach a point where it can prove what happened.

The third field is side-effect status. A production runtime should distinguish “no side effect started,” “side effect requested,” “side effect committed,” “side effect failed before commit,” and “commit status unknown.” That last state is the one teams are tempted to hide. It is also the state that matters most. If the agent sent a request and the network failed before a response came back, the correct status is not “canceled.” It is “unknown until verified.”

The fourth field is authority state. Canceling a run should usually revoke the agent’s authority to initiate new work, but it may still need limited authority to read receipts, verify state, write an audit record, or start an approved compensation path. That distinction prevents two bad outcomes: an agent that keeps acting after the user said stop, and a recovery path that cannot gather the evidence needed to close the loop.

The fifth field is an evidence pointer. A cancellation event should point to the trace, tool receipt, approval record, destination-system read, or callback that supports the final status. OpenAI’s Agents SDK tracing documentation frames agent work as traces and spans across model calls, function calls, handoffs, and workflow steps. Cancellation belongs in that same execution story. If an operator cannot follow the trace from “user clicked cancel” to “tool was stopped before commit” or “tool committed and compensation was queued,” the cancellation system is not operationally mature.

The sixth field is the recovery path. Sometimes cancellation ends the run. Sometimes it pauses it. Sometimes it converts into a compensating action. Sometimes it routes to an exception queue because the system cannot safely determine the external state. The user-facing label should not flatten those cases into “stopped.” A better receipt says: “Canceled before external action,” “Cancellation requested; waiting for vendor confirmation,” “Action had already completed; correction queued,” or “Status unknown; human review required.”

The seventh field is the resume rule. Long-running agents often do useful work before interruption. If a user cancels because they need to change scope, the system may need to resume from a checkpoint rather than start from scratch. But resume is safe only when the previous work is bounded and evidenced. A cancellation contract should define whether the run can be resumed, from which checkpoint, with which authority, and after which approvals expire.

This is not just backend hygiene. It is product trust. A user canceling a customer email needs to know whether it was merely drafted or already sent. An operator canceling a deployment needs to know whether the request reached the platform. A finance team canceling an invoice workflow needs to know whether the payment instruction was never submitted, rejected, pending, or accepted. Those are different realities, and the interface should not hide them behind the same animation.

NIST’s AI Risk Management Framework uses four verbs: govern, map, measure, and manage. Cancellation contracts make those verbs concrete. Govern means defining who can cancel, resume, and approve compensation. Map means knowing which phases and tools create side effects. Measure means recording cancellation outcomes instead of relying on chat transcripts. Manage means turning ambiguity into verification, escalation, or recovery rather than pretending the run disappeared.

Teams can start small. Pick one agent workflow with real side effects. List every phase from user request to final receipt. Mark each phase as safely cancelable, cancelable only at the next boundary, or not cancelable without verification. Add structured progress events so the runtime knows where the run is. Attach cancellation events to traces. Require every side-effecting tool to return or expose a receipt that can be checked after interruption. Define the exact message a user receives for each cancellation outcome.

Then test the ugly cases. Cancel before the tool call. Cancel while the tool is waiting on a remote API. Cancel after the remote system commits but before the agent receives the response. Cancel during a subagent handoff. Cancel after approval expires. Cancel and then resume. Cancel twice. Cancel while compensation is already running. If the system cannot explain the final state in each case, it does not have cancellation; it has theater.

The goal is not to make agents harder to stop. The goal is to make stopping them truthful.

A good cancellation system should sometimes say, “stopped safely.” It should also be willing to say, “the action may already have happened, so we are verifying before closing this run.” That honesty is what protects users, operators, and the business systems the agent touches.

Before giving an AI agent authority to act, ask what cancellation means after the action starts. If the answer is just “the user can click stop,” the design is unfinished. A stop button ends an interface state. A cancellation contract closes the operational loop.