What Happens to Pending Writes When a User Cancels an AI Agent?

Design an honest stop button for AI workflows. Separate future dispatch, in-flight requests, committed effects and authorized corrections.

Stop future work and inspect work already dispatched

When a user cancels an AI agent, stop new actions, request cancellation where the integration supports it, and inspect the outcome of each business write already dispatched. A stopped conversation cannot establish that an order, message or account change was reversed. The interface should report the confirmed state of those actions separately from the state of the agent run.

This creates a practical requirement for product teams: define what the stop button guarantees before deciding what it says. “Stop generating” can be accurate for a text response. “Cancel everything” is a much broader promise when the same run can reserve inventory, notify a customer and update a database.

The guidance below is an application design recommendation. It uses an illustrative service workflow, not a customer case study. It assumes the application can identify each authorized action and inspect at least some downstream outcomes. If an integration provides neither cancellation nor dependable status lookup, the product must disclose that limitation and restrict which actions the agent can perform.

One click, several different boundaries

Consider an assistant preparing a site visit. It has read a customer record, created an internal task, started a booking request and queued a confirmation email. The user notices the wrong date and clicks Stop. Treating the entire run as a single Boolean hides which steps have happened.

An undispatched email job can be held before a worker sends it. A committed internal task already exists. A booking request may still be running, and its final result may be unknown. The next model response can be stopped without changing any of those facts. Each boundary needs its own observation and permitted action.

Before offering this workflow, the team should agree whether cancellation stops only future dispatch or also initiates specific corrections. Automatic task deletion might fit one internal workflow; automatic reservation cancellation might carry a fee or invalidate an approval. A generic stop button should not silently make those commercial decisions.

| Action at the time of Stop | Required evidence | Honest reader-facing status | | --- | --- | --- | | Draft exists but no write was dispatched | Dispatch record and queue state | Draft stopped; nothing submitted | | Job is queued but not claimed | Durable hold and worker admission check | Sending held | | Remote request is in progress | Provider cancellation result or later status | Cancellation requested; outcome being checked | | Remote write has committed | Remote receipt and current object state | Action completed before cancellation | | Dispatch occurred but response is missing | Correlation lookup or owned reconciliation | Outcome unknown; new attempts held |

These statuses describe an illustrative contract, not automatic behavior supplied by a particular agent framework. The application must enforce the contract even when the browser closes or a worker restarts.

Browser abort and protocol cancellation have narrower meanings

Browser cancellation can interrupt a fetch or response stream. MDN's AbortController reference documents those client-side capabilities. The design inference is that aborting a browser operation does not by itself prove what a remote business system committed. That proof needs an application or provider observation.

Protocol cancellation also depends on the integration. The MCP cancellation specification dated 18 June 2025 describes optional notifications and cases where receivers may ignore them, including already completed or non-cancellable requests. Use the specification version negotiated by your implementation; this dated example is not a claim about every current MCP server.

Preserve the distinction in the execution service. A transport notification can tell a worker to stop processing, while a durable operation record retains the outcome of earlier business effects. If the protocol discards a late response after cancellation, use a separately authorized status path to reconcile the effect. Do not rely on the chat transcript as the only receipt.

Persist cancellation before another worker dispatches

A proposed implementation stores the stop request against the run and its operation identifiers. Workers check that durable state when claiming new work and again at the dispatch boundary. The check in the user interface improves responsiveness, but the execution check prevents another process from continuing after the tab disappears.

Define how dispatch and cancellation are ordered locally. For example, a transactional state transition can decide whether an undispatched operation becomes held or is claimed for execution. That local mechanism cannot make a remote provider commit atomic with the stop request. Once dispatch starts, the record must admit an in-flight or unknown outcome.

Also distinguish stopping new business effects from stopping recovery. A reconciler may need to finish reading a remote status after the run is cancelled. It should have permission for that bounded investigation without regaining permission to create a new reservation. Otherwise, Stop can abandon precisely the work needed to explain what happened.

Make admission checks explicit for delayed jobs. A job's presence in a queue does not mean it should still run. Give the worker the operation reference and current authority check, rather than a self-contained command that remains executable long after the user cancels. Document how jobs are held, expired and removed, including what happens if they have already been claimed.

Give reversal its own authority and evidence

If a booking committed before Stop, reversing it is a new business operation. Bind that operation to the confirmed booking identifier and the relevant policy. Determine whether the original approval included an automatic reversal, whether another person must approve it, and whether the provider exposes a supported cancellation endpoint.

Inspect downstream consequences before announcing that the workflow was undone. Deleting an internal task may leave an assignment notification. Cancelling a reservation may retain an audit record or incur a charge. An email may already have reached an external mailbox. A corrected email is another communication, not a deletion of the first one.

Avoid making the model invent the compensating action from incomplete observations. The application should offer defined corrections with prerequisites and known limits. The model can explain the choice or collect a new instruction; the execution service validates the target, permissions and current state before performing the correction.

Keep the original operation history. Mark a confirmed effect as reversed only after the correcting operation meets its own completion condition. This gives support and engineering teams a sequence they can inspect: original intent, dispatch, confirmed effect, stop request, correction approval and correction result. Overwriting the original result with “cancelled” loses evidence.

Design the stopped screen around remaining consequences

After Stop, show a short activity summary that distinguishes held work from completed or uncertain actions. Keep any unresolved action visible until it is reconciled or assigned to the documented recovery path. Do not replace the entire run with a green “Cancelled successfully” banner if a business effect remains unknown.

For the site-visit example, useful copy could be: “Further actions stopped. The internal task was created. We are checking the booking result. The confirmation email is held.” These statements require actual evidence. If the system has only requested a hold, describe that narrower status instead.

The reader should be able to leave the page without losing the operation reference. Offer a durable activity view or another agreed status channel appropriate to the product. Do not require a marketing subscription to receive an operational correction. If the system cannot provide an unattended reconciliation service, make the limitation clear before allowing the write.

For multiple operations, aggregate only after checking the children. One uncertain child means the run cannot claim that every effect was cancelled. Keep the summary accessible with text labels rather than color alone, and announce status changes without stealing focus from a reader who is reviewing another part of the screen.

Test cancellation at the inconvenient times

Start with an isolated integration that cannot contact real customers. Test Stop before job claim, after claim but before dispatch, during remote processing, after commitment but before receipt storage, and while recovery is running. The expected outcomes differ; one successful cancellation test cannot cover the entire path.

Use an independent effect record to check whether the provider performed the action. A local cancelled status is insufficient evidence. Include a delayed cancellation notification, a browser disconnect, two workers and a restart. Verify that new writes remain held while permitted status investigation can continue.

Repeat with a provider that explicitly refuses cancellation. The user-facing behavior should remain accurate rather than hiding the refusal. Test the correcting operation separately, including rejected authority and an uncertain reversal response. Ensure the system does not repeatedly issue corrections just because it has not received a final receipt.

Limitations and the next useful step

Cancellation controls cannot guarantee a universal undo across independent systems. Some operations finish too quickly to stop, and some effects are irreversible. Recovery can also fail when records expire, correlation is absent or the application loses access to the destination. In those cases, keep the uncertainty visible and follow an owned escalation path.

Your next useful step is to write a cancellation contract for one real workflow. List every action, the last point at which it can be held, available remote cancellation, permitted corrections and the evidence required for each status. Run the timing tests against that contract before adding a reassuring success message.

Read AI tool timeouts and duplicate actions for uncertain dispatch, and AI Agent Architecture in Production for wider execution controls. Ampity's production AI engineering is the related service when your team needs to establish and test these integration boundaries.