An AI workflow may read documents, prepare drafts and call connected systems before the user presses cancel. Some work can stop immediately; some may already have completed elsewhere. Ask the agency to describe cancellation in terms of business effects, not only whether a spinner disappears from the screen.
Related service: AI automation development- 01Receive cancellation
- 02Stop new work
- 03Reconcile in-flight steps
- 04Show completed and pending effects
SECTION 01
Classify every step by its effect
Separate read-only work, draft creation and external writes. Describe whether each provider supports cancellation and what a cancellation acknowledgement actually means. A local request timeout does not prove a remote action stopped. The interface should distinguish cancellation requested from cancellation confirmed.
Microsoft's compensating-transaction pattern explains that reversing completed distributed work can require additional business actions rather than a simple rollback. Ask which steps can be compensated, who authorizes that compensation and which effects cannot be undone. Do not promise a universal undo button for all integrations.
SECTION 02
Illustrative example: preparing a customer follow-up batch
Imagine an assistant reads a set of approved service notes and prepares follow-up drafts for review. The operator notices the wrong date filter and cancels halfway through. Already created drafts remain visible as canceled-batch outputs, while unscheduled items do not start. None should be sent because this release is draft-only.
If a later version includes approved sending, cancellation must report messages already accepted by the sending system separately from unsent drafts. A resumed run uses the corrected filter and checks prior action receipts. This hypothetical scenario demonstrates why stopping future work and reversing earlier effects are different requirements.
SECTION 03
Test the awkward moment between request and receipt
Cancel during document reading, while a tool call is in flight and immediately after a destination accepts an action. Close the browser and reopen the workflow. The resulting status should remain consistent because cancellation is recorded by the application, not stored only in the page.
Microsoft's retry guidance is relevant to resumption: repeating a step can repeat a side effect. Request step-level receipts, a reconciliation queue and documented resume rules. A simpler first release may stop new tasks while requiring staff to resolve in-flight writes. That limitation is acceptable when explicit; hiding uncertain effects behind a completed cancellation message is not.
SECTION 04
Frequently asked questions
Can every AI provider stop a request immediately?
No. Support and timing vary. The implementation should expose the actual provider behavior and keep the application state honest.
Should cancel delete partial outputs?
Not automatically. Partial drafts and receipts may be needed to explain or reconcile the run. Apply the agreed retention and access rules.
Can we restart from the beginning instead of resuming?
Only when completed effects are safely recognized or intentionally repeated. Otherwise a fresh run can duplicate actions that already succeeded.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Compensating Transaction patternMicrosoft Learn
- Retry patternMicrosoft Learn
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy