A workflow that uses AI still needs a plan for interrupted work. Decide what can resume, what must be checked again and what requires a person to resolve before connecting it to business systems.
Consider a support workflow that reads an order, prepares a reply, waits for staff review, updates the service case and sends the approved response. Each step can succeed or fail independently. Recovery needs to account for the work already completed.
Separate interpretation from execution
Identify where the workflow needs a model. Preparing a reply may require interpreting the customer's question and the relevant records. Looking up an order, checking permission and submitting an approved update can use defined application behavior.
Anthropic's engineering guidance distinguishes predefined workflows from systems where a model chooses its process and tools. Use that distinction to decide where flexibility is useful. A known sequence can include model calls without handing the whole process to an agent.
Write the permitted steps and their completion conditions. If a model chooses an action, validate the proposed action before execution and retain enough progress information to resume after an interruption.
Save progress that supports a recovery decision
Use a durable record of the business operation. Record the relevant source versions, prepared output, review status and destination references. Establish when those records are saved relative to each external action.
For the support example, the recovery questions could be:
| Step | Progress to retain | Check before continuing |
|---|---|---|
| Read the order | Order reference and version | Has the relevant order information changed? |
| Prepare a reply | Saved draft and source references | Does the draft still match the current information? |
| Staff review | Approved text, reviewer and scope | Does approval cover this exact response and action? |
| Update the service case | Operation reference and destination result | Was the update applied, and is its outcome known? |
| Send the response | Approved recipient, message reference and service receipt | What does the receipt confirm, and is another send appropriate? |
The record needs to support the next decision. A transcript of the agent's conversation may not establish which change reached the destination.
Check an uncertain result before repeating the action
Suppose the service-case update times out. The destination may have applied the update while the response was lost. Mark the result as unresolved and check the destination through its supported operation lookup or another reconciliation procedure.
Define how each integration handles repeated requests. Some support an operation key that recognizes a repeated submission; others may create another record or repeat an external action. Verify the actual behavior, including the period for which that protection applies.
Amazon's guidance on timeouts and retries explains that a failed response does not establish that a side effect did not occur. It also describes how retries can add load to a struggling service. Set retry limits and delays appropriate to the integration, and avoid independent retry loops multiplying across layers.
When the final send is uncertain, check the messaging service's records before sending again. Distinguish a service accepting the message from evidence of delivery. Route a result that cannot be established to the responsible operator.
View full-size diagram
Recheck work that waited for review
A paused workflow may resume after the source information or the user's permissions have changed. Decide which conditions must still hold at execution time.
In the support example, a later order update may make the approved draft inaccurate. Preserve the reviewed version, identify the changed information and return the revised response for review when needed. Keep the approval attached to the text and action it covered.
Set a rule for abandoned or expired work. Give staff a clear way to cancel it and see which steps already completed. Test cancellation while the workflow is waiting and while an external action is in progress.
Plan corrections for completed steps
If updating the case succeeds but sending the response fails, choose the next action according to the business process. It may be appropriate to resume sending, correct the case status or ask an operator to intervene.
Microsoft's compensating-transaction guidance explains why undoing completed work can require business-specific rules and consideration of concurrent changes. A correction may itself fail and need recovery.
Identify actions that cannot be fully undone. A sent message cannot be treated like an uncommitted database edit. Put the relevant checks before that action and define how staff handle a later correction.
Test interruptions at the points that matter
Test a restart after each external step, a delayed review, a changed source record and an uncertain send. Confirm that progress survives and that resuming does not silently repeat completed work.
Give the operating team the information needed to resolve an exception: the business request, completed steps, unresolved outcome and available next actions. Measure recovery effort alongside completion quality, elapsed time and operating cost.
Start with one workflow and the systems it actually uses. X-Centric.ai's AI consulting services can help connect model use, integrations and recovery behavior with the people responsible for the process.