An AI workflow sometimes spans several independent services. Reserving a workshop seat, allocating a kit and sending a confirmation are separate effects; if the second step fails after the first succeeds, the application cannot treat the whole job as a single database rollback. A saga coordinates local transactions and, where appropriate, uses compensating actions to restore a consistent business outcome.
This chapter follows a fictional Brookside Science Workshop with twelve intended registrations, seven verified completions, two successfully compensated failures and three cases still requiring attention. It explains why undoing a reservation differs from unsending a message, and how recovery should be recorded and checked.
It is an unnumbered technical companion to How Super Intelligence Works. The term Super Intelligence is an educational label for AI mechanisms, not a claim of achieved artificial superintelligence.
Contents and recovery routes
1. One business task can span multiple local transactions · 2. A saga is not one large database transaction · 3. Compensation is a new effect, not a time machine · 4. The fictional Brookside Science Workshop · 5. Print the twelve outcome categories · 6. Calculate completed registrations accurately · 7. The repair share has a different denominator · 8. Design the forward sequence before automating it · 9. Define the action contracts separately · 10. The first compensable step is a seat hold · 11. Equipment allocation can fail after the seat succeeds · 12. Forward recovery may be preferable to cancellation · 13. The pivot marks a consequential threshold · 14. Orchestration versus choreography · 15. State consistency needs a business rule · 16. Compensation can fail too · 17. Human approval is not an error to optimise away · 18. Source and authority versioning matter during recovery · 19. Different identifiers describe different effects · 20. A saga log should survive a model restart · 21. Why a refund differs from deleting a database row · 22. Independent transfer: the Rowan Learning Camp · 23. What remains unresolved in the transfer packet · 24. A changed-context exercise with a sent notice · 25. A paper exercise in transaction cards · 26. Frequently asked questions · 27. Primary sources and connected learning
1. One business task can span multiple local transactions
A school workshop may need a seat in a registration service, a physical kit held by an equipment service and an approved notice sent through a messaging service. Each service stores its own data and may succeed or fail independently. A model drafting the correct plan does not make these changes atomic.
The user expects one coherent outcome: participation confirmed with the necessary resources. The application must know what each service actually committed, what remains pending and which authority may reverse or correct an action.
2. A saga is not one large database transaction
Microsoft Azure’s Saga design pattern describes coordinating a series of local transactions. A successful local operation can trigger a later step; when a later step fails, an appropriate compensating operation may address previous effects.
The pattern is useful when independent services cannot simply share one atomic commit. It requires additional state management, possible temporary inconsistency and explicit knowledge of which operations are reversible. It does not mean every real-world consequence can be undone.
3. Compensation is a new effect, not a time machine
Canceling a reserved seat can counteract an earlier allocation under the workshop’s rules. The cancellation is a distinct operation requiring permission and confirmation. An original notification already read by a family cannot be literally removed from their memory; an authorised correction may be possible instead.
The correct recovery is often business-specific. Compensation may return resources to an available state, but it should not be described as exactly rewinding the world to before the operation occurred.
4. The fictional Brookside Science Workshop
Our entire laboratory is invented. Brookside accepts twelve hypothetical participation requests, each needing an authorised seat allocation and a science equipment-kit allocation. Once both are verified and a staff reviewer approves the final notice, the workflow may send a confirmation.
No real bookings, emails, payments or school equipment are involved. We stipulate statuses for twelve independent requests so a pupil can reconcile a multi-step process and identify which tasks genuinely finished.
5. Print the twelve outcome categories
Seven requests have a seat, kit and required staff confirmation, with a verified complete registration. Three cases failed when the equipment service could not allocate a kit after the seat had been held. Of those three, two seat holds were subsequently released and verified, while one release remains unconfirmed.
Two other requests remain awaiting staff review before any resources were reserved. Thus the categories are seven completed, two compensated, one compensation pending and two review pending. Their sum is twelve.
6. Calculate completed registrations accurately
Seven of twelve intended registrations have the full accepted outcome. The verified complete share is 7/12, approximately 58.3%. Two compensated cases are not additional registrations served, and a seat hold alone is not proof that the participant has a kit.
A dashboard that says ten registration operations succeeded because seven full completions and three seat holds occurred would conflate different business states. The user needs a verified coherent result, not a count of intermediate tool calls.
7. The repair share has a different denominator
Three cases reached a failure requiring compensation after seat allocation. Two have a verified released hold, so the compensation completion share for that affected subset is 2/3, approximately 66.7%.
This does not mean two of three workshop registrations were ultimately successful; compensation closes a failed path cleanly rather than fulfilling the initial event attendance goal. The one unverified release should not be labeled cancelled solely because the cancellation call was attempted.
8. Design the forward sequence before automating it
A conservative fictional sequence checks eligibility and source information, obtains staff authorisation, reserves a seat, allocates a kit and then sends a final notice once required resources are verified. Important checks should occur before irreversible communication where possible.
An agent that sends confirmation immediately after the first seat hold risks promising attendance without a kit. The model can generate text quickly, but the application should wait for the right external states rather than making speed the priority.
9. Define the action contracts separately
The seat service accepts a permitted hold request and returns a stable hold ID and status. The equipment service accepts an allocation request tied to the same registration intent. A compensation call releases a particular hold under the service’s documented contract.
The message service should only be invoked when the approval and resource predicates are true. A tool schema can make the arguments well formed; separate authorisation and actual-state checks must establish that the operations were allowed and succeeded.
10. The first compensable step is a seat hold
If a kit allocation later fails, an approved release operation can compensate for the previously reserved seat. The application must preserve the correct hold identifier and any conditions on cancellation. A model should not guess a different seat to release merely to close its task.
If the seat has already been reassigned or changed by another legitimate operation, blindly restoring a prior database snapshot may overwrite someone else’s work. Compensation should operate through the business service’s current rules.
11. Equipment allocation can fail after the seat succeeds
An equipment service may lack a suitable kit or be temporarily unavailable. A transport timeout also may not establish whether a kit allocation happened. The workflow should first diagnose the result under the service’s supported reconciliation procedure.
An uncertain result is not automatically a permanent business failure. If the kit allocation might still be committed, canceling the seat prematurely can create another inconsistent state. Correct action follows actual evidence, not the model’s impatience.
12. Forward recovery may be preferable to cancellation
When a kit is temporarily unavailable, a workshop organiser might legitimately arrange an approved substitute and continue with the participant’s permission. That can be better than canceling a scarce seat and starting again.
This is a business decision, not an agent’s automatic right. The system may propose alternatives and hold the record for an authorised reviewer. Compensation is one recovery strategy, not an obligation to reverse every partially completed task.
13. The pivot marks a consequential threshold
Microsoft’s Saga documentation describes a pivot transaction as a point after which remaining operations are expected to proceed through retryable steps rather than compensation of earlier ones. The appropriate pivot depends on the domain’s real rules and irreversibility.
For Brookside, sending the final confirmation should not occur before the prerequisite resource and approval checks are satisfied. Once someone has acted on a message, a later change may require a corrective notification rather than an invisible rollback.
14. Orchestration versus choreography
In an orchestrated saga, a central coordinator tracks local operations and chooses the next permitted step or compensation. In choreography, services respond to relevant events without one controller directing every transition. Both patterns exist and have distinct complexity and observability costs.
A classroom can model either: one pupil coordinates seat and kit cards, or participants pass event cards to the next service. In both versions, each service must preserve identity and actual outcome rather than guess from the coordinator’s prose.
15. State consistency needs a business rule
Two databases can each contain locally valid records while the overall workshop registration is incomplete. A seat held without a kit may be a temporary valid intermediate state but not an acceptable final state.
Define which temporary combinations are allowed and how long they may remain. A stalled saga should become visible for recovery rather than silently passing as a completed booking.
16. Compensation can fail too
An attempt to release the seat may time out or encounter a service error. That is why our packet has one compensation_pending case. Repeating a compensating operation can have unintended consequences unless the service supports appropriate idempotency and current-state checks.
The Azure Compensating Transaction pattern discusses the need to retain recovery state, monitor progress and design safe repeated compensation where applicable.
17. Human approval is not an error to optimise away
A staff reviewer may need to decide whether a participant can take a substitute kit or whether a cancellation should be communicated. The assistant can organise the available evidence but cannot invent that decision just to reduce the open queue.
The two cases awaiting review in Brookside should remain in that status until the appropriate decision is actually recorded. No resources were allocated for them under the packet, so they require no seat-release compensation yet.
18. Source and authority versioning matter during recovery
Suppose the workshop’s allocation rules change between the original hold and attempted compensation. The application should verify the effective business policy and the current resource state rather than assume the previous rules apply unchanged.
An earlier teacher approval may also refer to a precise notice version. If the final message changes materially, the workflow may require a fresh review before sending the corrected text.
19. Different identifiers describe different effects
A registration-intent ID groups the user’s overall goal. A seat-hold ID identifies one local resource allocation. A kit-allocation ID identifies another. A compensation operation ID identifies the release attempt. A notification ID identifies an independently delivered message.
Confusing these can cause an agent to cancel the wrong hold or report a confirmation based on an unrelated record. The application should maintain a traceable relationship without treating any one identifier as permission to access everything.
20. A saga log should survive a model restart
The coordinator needs durable records of which steps committed, which compensation actions are available, and which external outcomes remain unknown. A chat summary alone may omit the hold ID or invent a resolution.
The application can resume from a trusted state and reconcile with the individual service databases. Durable execution and saga design are complementary, but neither guarantees that every later operation will succeed.
21. Why a refund differs from deleting a database row
In domains involving money, a reversal may require a separate authorised refund under relevant policy rather than erasing evidence of the original payment. Transactions, fees, time and legal duties can affect what compensation means. An agent must never promise a full refund without the corresponding rules and record.
Brookside avoids actual money entirely. The physical-kit and seat examples teach that even non-financial effects may need domain-specific repair and communication.
22. Independent transfer: the Rowan Learning Camp
A second fictional camp receives fifteen registration intentions. Nine complete all approved steps. Four need compensation after a downstream resource failure; three of those have a verified release and one remains pending. Two requests await a staff decision before any allocation.
The categories sum to 9+3+1+2=15. Verified complete registrations are 9/15=60%. Successful compensation among the four affected cases is 3/4=75%. Neither count should be added to claim twelve completed participants.
23. What remains unresolved in the transfer packet
Rowan has one compensation_pending case and two awaiting staff review, or three open business intents. The three successfully compensated cases have closed failure paths but do not become valid registrations.
This distinction prevents a dashboard from counting a clean cancellation as both a recovered error and a fulfilled educational service. A successful recovery can mean restoring consistent resource state without providing the originally requested booking.
24. A changed-context exercise with a sent notice
Now imagine a fictional participant received a confirmation before the kit allocation was verified. The kit then becomes unavailable. Even if the seat hold can be released, the earlier message cannot be unsent. The organiser may need a truthful corrective communication through its approved process.
A model that reports ‘nothing happened’ after seat compensation would conceal the earlier external effect. Saga reasoning must include irreversible or socially consequential steps beyond database values.
25. A paper exercise in transaction cards
Give learners a seat card, kit card, review card and notice card. Ask them to place each step in a safe order, mark which effects can be compensated and identify which require a human decision. Introduce a failure after the seat card is committed.
Students should explain the observed resource states before selecting a recovery operation. Then change the failure to occur after the notice and examine why the corrective process differs.
26. Frequently asked questions
Is a saga simply a database rollback? No. It coordinates separate local transactions and domain-specific compensating actions. Does compensation always restore the exact old state? No; concurrent changes and irreversible effects can prevent that.
Should every failed step trigger immediate cancellation? Not necessarily; forward recovery may be appropriate under the business rules. Does a model claiming ‘cancelled’ prove the seat was released? No. Read the resource service’s actual state.
Applied saga recovery: competing operations, compensation failures and irreversible effects
Compensating transactions are not negative timestamps
The fact that a seat hold was released does not delete the history that the hold once existed. A participant or staff member may have seen its temporary status. The recovery log must record both the original local operation and the later release, with enough evidence to verify that the intended resource was corrected.
A system should not rewrite an old event to make it appear the initial action never happened. Transparency improves diagnosis and prevents future steps from assuming a resource was never touched.
A compensation must target the exact committed effect
If a failure occurs after seat S-104 was held, the release should target S-104 under the provider’s authorised resource contract. Releasing a different seat with the same class title would not restore the intended state and could harm another participant.
A model that cannot establish the matching hold ID should pause for reconciliation. The system must not infer the target solely from a natural-language summary, especially when concurrent registration requests have similar labels.
Compensating actions can require a new decision
A kit might be unavailable, but the organiser could offer an approved alternative. A person may prefer to continue with that alternative rather than cancel. The system should not always choose compensation automatically when the real user has an important preference to exercise.
For high-impact or ambiguous conditions, a human reviewer can decide whether to continue forward, pause or cancel. The AI may present options, but permission to suggest a plan is different from authorisation to act on it.
Choreography makes event ownership important
In a choreography-based design, the seat service may publish an event when its hold succeeds, and the equipment service may respond under its own rules. No single controller directly instructs every step. That can simplify some small workflows while making the overall path harder to trace.
A reliable implementation needs stable correlation IDs, supported event types and a way to detect when one participant never responds. Multiple services reacting to the same duplicated event should not create repeated kit allocations.
Orchestration centralises progress decisions
An orchestration-based saga uses a coordinator to track the forward sequence and decide which compensation to request after a failure. That can make complex state handling clearer, but the coordinator itself becomes a critical component needing durable state and recovery.
If the coordinator loses its process memory after the seat hold, it must not begin the saga from the start without checking the hold’s external state. The durability and idempotency chapters explain the complementary safeguards.
The pivot does not make every later step easy
A point of no return is useful for describing which actions cannot be cleanly compensated. But after that point, later steps can still fail or require authorised intervention. The design may rely on retryable operations, correction processes or manual handling.
A staff notification delivered to a family is not literally reversible. Even if a follow-up message is permitted, the original recipient may have acted on the information. An accurate recovery record must acknowledge that external effect.
A seat release may not restore the same availability
Suppose a held seat is released while another participant legitimately books the final available place. The resource state after compensation may be different from the state before the failed saga. This does not necessarily mean the release failed.
It means the compensation should follow the current business rules rather than overwrite concurrent work with an old database snapshot. Reconciliation checks whether the intended hold was removed without claiming a full restoration of all past conditions.
Race conditions matter at failure boundaries
Two registration workflows might each try to hold the last kit. An appropriate equipment service must arbitrate availability according to its own consistency rules. A language model’s belief that inventory is sufficient cannot replace those service controls.
When a kit allocation is denied, the saga must respond to the actual result. It should not create a phantom allocation so that both booking workflows appear completed.
An unknown kit result is not a definite failure
A network timeout after attempting kit allocation might leave the resource service’s state ambiguous. Immediate compensation of a seat hold can be premature if the kit allocation actually committed. Conversely, blindly attempting another allocation can consume an extra kit.
The first safe step is to query the intended allocation or use documented recovery semantics. Only after the state is established can the authorised workflow decide whether to continue, compensate or escalate.
Compensation has a separate idempotency need
If a seat-release request is retried after a lost reply, it should not accidentally release two separate reservations or a newly assigned seat. The service needs a safe way to associate repeated release attempts with one original hold and one intended compensation.
This is different from protecting the original seat-hold creation. Each consequential operation can require its own identity and documented retry contract.
An unresolved compensation should stay visible
Brookside’s one pending release cannot be silently placed in the same category as the two verified releases. The system might have attempted an operation while the target’s final state remained unknown. A reviewer needs that distinction to avoid promising that the resource has become available again.
An operational dashboard should show completed registration, verified compensated, pending compensation and awaiting human review as different states. The sum still covers all twelve initial intentions.
Release and refund are not synonyms
In a hypothetical paid workshop, freeing an equipment reservation would not automatically return money. Financial reversals follow their own approved transaction records, fees and policies. A model cannot infer that one completed resource compensation settles every related commitment.
This article deliberately avoids live financial actions. The conceptual lesson is that each domain effect has a responsible service and potentially a distinct correction or reimbursement procedure.
A corrective notification is still a new communication
If an early confirmation was sent before all prerequisites were established, a later cancellation cannot erase the earlier message. A follow-up correction may be appropriate, but it needs truthful wording, correct recipients and authorised delivery.
A dashboard should not report ‘no notification was sent’ merely because the final reservation was compensated. The communications record and resource record tell different parts of the outcome.
Select recovery from observed facts
A model may propose a compensation plan based on the known steps and rules. The application must verify which local transactions committed and what business permissions apply. A plan containing a guessed transaction ID is not safe to execute.
Recovery should be traceable through operation identities, timestamps, approvals and actual source-of-truth records. The model’s confidence is not a substitute for those checks.
Compensation failure can have its own recovery queue
A release call that repeatedly fails can be routed to an operator with the original hold ID, permitted recovery choices and last observed state. Some architectures use a dead-letter queue or incident task to preserve such unresolved operations.
These facilities should maintain enough context to repair the failed release without exposing unnecessary pupil or family information. An unprocessed recovery item is not equivalent to a completed cancellation.
Measure time to consistent resolution
The speed of detecting a failed equipment allocation is one metric; the time until the seat hold is correctly released is another. A model can identify the error quickly while external compensation takes much longer. A useful reliability study measures the whole recovery interval.
Compare the number of requests reaching an acceptable final state and the number remaining inconsistent, not just the number of compensation messages generated.
A recovery can produce a useful partial report
Suppose Brookside verifies two released holds and one release remains pending. It can inform responsible staff of exactly those facts. It should not claim that all affected capacity is free merely to make the recovery notice reassuring.
Appropriate communication may include next steps for the unresolved case. A precise partial report protects future decisions because everyone knows which records still need confirmation.
Independent transfer with a changed final step
Consider the Rowan packet, but suppose one of its nine completed registrations has a verified seat and kit yet a final required notice was never delivered. Under a stricter completion contract requiring that notice, the confirmed count would fall from nine to eight, and the affected record would move to pending communication.
The new verified share is 8/15, approximately 53.3%. Nothing about the resource allocations changed; the accepted end state did. This teaches why workflow denominators need to preserve the user’s actual requirements.
The final compensation audit card
For each saga, record the user’s intended outcome, constituent local transactions, approved versions, committed operation identifiers, available compensations, irreversible steps, current resource state and human decisions. Mark unknown outcomes explicitly.
A student can use a paper version of the card to explain why seven Brookside requests completed, two were compensated, one required release confirmation and two awaited review. That ability to reconstruct the whole sequence is more valuable than simply memorising the term saga.
One final changed-context review
Imagine a school changes its equipment requirement after a seat hold but before a kit allocation. The recorded teacher approval may no longer cover the new kit. The assistant should preserve the successful seat-hold state, identify the changed requirement and seek an authorised choice about continuing or compensating. A model’s confidence is not evidence that the new equipment is acceptable. This exercise forces learners to recognise that correct recovery depends on current policy as well as previous transactions, and that a previously valid decision cannot automatically authorise a different user outcome.
Continue the four-part agent reliability route: Durable Workflows · Event-Driven Agents · Reliability & Error Budgets. Together these laboratories trace a saved task across failures, event delivery, multi-service compensation and measured complete-task reliability. See the completed 100-topic series hub and Agent Observability for the corresponding full-system checks.
27. Primary sources and connected learning
The Azure Saga design pattern and Compensating Transaction pattern explain local transactions, compensation, orchestration and failure limits. They do not validate the invented Brookside or Rowan exercises.
Read eduKate’s Idempotency and Recovery, Durable Agent Workflows, Alignment and Human Control and How Super Intelligence Works. All records, kit allocations, messages and outcomes above are fictional. Sources reviewed 22 October 2026.