Enterprise AI needs cancellation contracts before longer-running agent autonomy

Long-running agents turn cancellation into a first-class control

OpenAI’s current background-mode guidance makes the operational shift explicit. Background responses are asynchronous, can be polled while they are `queued` or `in_progress`, and can be canceled through a dedicated endpoint. The same guidance says cancellation is idempotent, so repeated cancel calls simply return the final response object instead of creating a new side effect. It also notes that background mode stores response data for roughly ten minutes to support polling and is not Zero Data Retention compatible. That matters because once work can continue after the original session drops, the stop path becomes part of the system design. The common story says the hard part is making the agent run longer. The operational reality is that the next serious question is who can stop it, what final state proves it stopped, and whether the retained state fits the organization’s data posture while that stop window exists.

Graceful cancel and hard stop are not the same operating move

The orchestration layer makes this distinction hard to ignore. Temporal’s current interruption guidance says cancellation is for graceful interruption with cleanup and state management, while termination is the immediate path when a workflow is stuck. AWS Step Functions documents a separate `StopExecution` API with explicit request parameters and a returned `stopDate`, while also noting that the action is not supported for EXPRESS state machines. GitHub’s current workflow controls add a third reminder: you can cancel a running workflow, but GitHub separately documents concurrency groups with `cancel-in-progress`, and its workflow-cancellation reference says the server reevaluates job and step conditions during cancellation so jobs or steps guarded to always continue can keep running. There is no serious enterprise state called “we can just kill it.” There are different stop semantics, different cleanup paths, and different runtime exceptions that have to be named before a long-running agent is treated as governed.

A stop button is not enough without recovery and audit context

NIST’s AI RMF Playbook puts the governance burden where it belongs. Manage 4.1 calls for post-deployment monitoring plans that include mechanisms for appeal and override, decommissioning, incident response, recovery, and change management. That is larger than a cancel API, and it should be. A long-running agent may already have opened a ticket, started a deployment, staged a draft, or reserved downstream capacity before the stop request arrives. If the organization can only say “we clicked cancel,” it still has not explained whether cleanup completed, whether a compensating action ran, whether another queue retried the work, or whether an auditor can reconstruct the stop event afterward. Cancellation becomes a real enterprise control only when the stop event is joined to the downstream recovery path and the terminal evidence sink.

Executive move: publish one cancellation contract per high-consequence workflow

Before expanding long-running agents across production workflows, publish one cancellation contract for each high-consequence path. Name the run owner, the users or systems allowed to request cancellation, the graceful-cancel path, the forced-stop path, which downstream activities must still finish, which writes are blocked after cancellation, how retries are suppressed, which jobs ignore cancellation by design, what terminal receipt or audit record proves the final state, and who owns the recovery or compensating action if the stop happens too late. Then run one live drill: start the workflow, trigger a cancellation from a second operator, confirm the visible state flips to terminal, confirm no unintended write continues, and show where the stop record lands. If the team cannot produce that proof without a war room, the rollout is ahead of its control surface.

Key takeaways

• Long-running agent autonomy raises the importance of stop authority, terminal state, and cleanup design more than it raises the importance of another orchestration demo.
• Current OpenAI, GitHub, AWS, Temporal, and NIST guidance all point to the same operating reality: cancellation semantics vary by runtime and need to be documented on purpose.
• Executives should require one cancellation contract per high-consequence workflow before broadening long-running autonomous runs in production.

Related surfaces

• Enterprise implementation path — See how LockedIn Labs frames governed rollout, implementation boundaries, and operator handoff for high-consequence workflows.
• About LockedIn Labs — Use the firm overview for the broader implementation posture behind governed workflow control and delivery discipline.
• Background-agent queue-ownership briefing — Pair stop authority with the adjacent briefing on who owns the queue, backlog, and release of long-running agent work.
• Idempotent-action briefing — Connect cancellation design to the adjacent briefing on retry-safe writes, duplicate-side-effect control, and durable action receipts.
• Incident-response playbook briefing — Use the adjacent briefing on incident response and recovery when a stopped workflow still leaves the wrong state behind.
• Contact LockedIn Labs — Discuss one long-running workflow where nobody can yet show who may cancel it, what cleanup still runs, or how the stop event is evidenced.

Sources

• Background mode
• Canceling a workflow run
• Workflow cancellation reference
• Workflow syntax for GitHub Actions
• StopExecution
• Interrupt a Workflow - Cancellation and Termination
• Manage