When an AI Workflow Fails Halfway, Decide What to Undo

An assistant helping to run a paid workshop reserves a seat and requests payment. The seat is held, but the payment provider rejects the request. The workflow displays ‘failed’. Meanwhile, the booking system still counts the seat as taken. A second customer is told the workshop is full, even though the first booking never went through.

This fictional failure is easy to miss in a demonstration. A single status describes the outcome of the workflow, but the business has to deal with the effects of each step. Before putting an AI-assisted process in charge of a booking, ask what should happen to changes that have already taken effect when the next step cannot finish.

A failure can leave something behind

In the workshop example, drafting a friendly confirmation and holding a seat are very different actions. Discarding a draft is straightforward. A reservation changes what other customers can book. If the workflow stops after making that reservation, somebody or something must address it.

The Azure Architecture Center describes a compensating transaction as a way to address the effects of completed steps after a later failure. The recovery action follows the rules of the business. It need not recreate the original state of the entire system. Restoring an old copy could erase legitimate changes that other people made in the meantime.

For the workshop, the proposed recovery action is to release the particular reservation that the failed booking created. Setting the whole event’s availability back to yesterday’s number would be a different operation. It could ignore a legitimate booking made while the first customer was trying to pay. A useful recovery rule names the record it changes and the state that permits that change.

Decide whether to finish, reverse or pause

The AWS guide to saga patterns distinguishes continuing the original process from compensating for work already done. A temporary interruption can sometimes be resolved by completing the outstanding step. A definite rejection may instead call for reversing an earlier effect. Neither decision should be based on a generic ‘something went wrong’ message.

Suppose the payment provider gives a definitive rejection and the seat is still held for that booking. The team might allow automatic release. Now change one fact: the payment request timed out and the provider’s result is unknown. The team cannot assume the payment failed. It needs to check the authoritative payment record before taking an action that could leave a customer charged without a place.

Make this distinction visible in the staff view. ‘Payment declined; seat released’ describes a settled outcome. ‘Payment outcome unknown; check required’ tells an operator why the case is still open. Give the operator the booking and payment references, the last verified step, and a way to see what has already been attempted.

Design the recovery as a workflow of its own

Releasing the seat may also fail. The booking system could be temporarily unavailable, or the reply confirming release could be lost. Microsoft’s guidance recommends recording the progress of recovery and making its steps safe to repeat. In this example a retry should target the same reservation and should not make a second seat available if the first release already succeeded.

Name a person responsible for unresolved cases and define what they need to see. For a small workshop business that may be the owner, but the dashboard should still show whether the seat remains held, whether a release was requested and whether the result is known. A queue entry that says ‘retry failed’ is a starting point for investigation, not a completed repair.

MaryChuks.com’s guide to checking an AI agent’s action log explains the evidence a team may need after a failure. Pair that evidence with explicit recovery rules. An action log can show that the system reserved a seat; the booking rules determine when it should release it and who can intervene.

Ask for a demonstration with a deliberate interruption

Use a test event and test records. Ask the builder to stop the workflow after a seat has been held, then show the outcome in the booking system as well as in the assistant’s conversation. In a second run, interrupt the recovery itself. A rehearsed success is useful only if the team can also explain the unresolved cases.

• Definite rejection: verify that the correct reservation is released and other customers’ reservations are untouched.
• Uncertain result: verify that the system checks the payment record or routes the case to review before proceeding.
• Repeated recovery request: verify that the same reservation cannot be released twice in a way that increases available places.
• Recovery unavailable: verify that the unresolved case remains visible and reaches the person responsible.

A smaller workflow may be the better design. If the customer can review the booking before external actions occur, or if a single booking service can keep the relevant changes together, there may be less separate work to repair. Keep messages that imply completion until the facts support them. If an inaccurate confirmation has already reached a customer, correcting the record does not erase the message; someone still needs to put the expectation right.

An AI assistant can help draft recovery scenarios, but the business must choose which changes it will reverse, when to wait for evidence and who decides what happens next. Test that decision where it matters: in the record that controls the seat, and in what the customer is told.

Sources

Primary technical guidance: Microsoft Azure Architecture Center, Compensating Transaction pattern; AWS Prescriptive Guidance, Saga patterns. Both are maintained references checked on 11 November 2026. The workshop, recovery rules and acceptance scenarios are illustrative.