A multi-step agent workflow may commit changes across systems that do not support one atomic transaction. If the fourth action fails, simply retrying the whole task can charge a card twice or reserve duplicate inventory. The Saga pattern replaces fictional ‘undo’ guarantees with explicit compensating operations and reconciliation.
What compensation actually means
A saga records a series of forward steps such as reserve stock, create shipment request and charge a payment. Each committed step has a corresponding action that aims to restore a valid business state, such as release stock or refund an authorized charge. Compensation is not the same as database rollback: the supplier may already have received the request, a refund may take time, and a confirmation email cannot be unsent. The application must define acceptable final states, not just invert API calls.
Designing a recoverable payment flow
Before any externally visible step, generate a stable operation ID. Reserve inventory with that ID and record the external reference. If the payment step reports an ambiguous timeout, query the payment provider using the same business key rather than issuing a blind new charge. If payment definitely failed, release the reservation. If payment succeeded but shipping cannot be scheduled, place the order in an exception queue and decide whether to refund. Human intervention may be safer than automatic compensation for regulated or high-value transactions.
State and retry discipline
Persist a state machine representing proposed, approved, submitted, observed, compensating, reconciled and unresolved states. Temporal documents compensating-activity patterns in long-running distributed workflows, but persistence does not guarantee that every external endpoint is idempotent. Use an outbox or audit ledger for intended side effects and put operations behind bounded retries. Never let the language model infer business completion solely from its last tool result.
Test the ugly cases
Kill a worker between the external side effect and recording the response. Simulate duplicate webhooks, partial failures, lost acknowledgments, credentials expiring while compensation runs, and a user cancelling during a non-reversible action. For each case identify the authoritative state to query, the next safe command and the on-call owner if automation cannot reconcile. Include compensation failures in the dashboard rather than counting them as successful rollbacks.
When a workflow engine helps
A durable workflow engine can persist control state, schedule retries and trigger human review, reducing custom orchestration code. It still cannot guarantee that third-party APIs are correct or that every business action has a meaningful inverse. If the process is a single deterministic update within one transactional database, an ordinary transaction is simpler. Pricing and deployment regions for any particular orchestration vendor require a separate dated evaluation.
Keep economic state separate from model state
The language model can decide which next action to propose, but the durable workflow service must be responsible for idempotency keys, external confirmations and compensation order. Put money-moving steps behind explicit business rules and approval. Never ask a model to invent a refund amount after a partial failure; calculate it from authoritative transaction data and company policy. Treat an absent tool response as an unknown state until reconciled.
Production acceptance and review test
Create a fault-injection test for every point before and after an external API side effect. Check what happens if the worker crashes immediately after a payment but before recording its identifier, and if the cancellation request arrives during compensation. Measure double charges, unreconciled states, compensation completion and required manual interventions. Publish an incident runbook naming the data source of truth for each step.
Scope, version and availability
Features documented by a current vendor page are not assumed to have existed in earlier releases. Where a historical launch date is provided, it is supported by a dated first-party publication. Exact subscription tier, market availability, quotas, API billing, licensing permissions and deployment regions are not asserted without a directly applicable record. This is researched editorial guidance rather than a claim of independent hands-on testing, deployed operation or statutory certification.
Sources and Further Reading
- Temporal — Saga pattern documentation (source reviewed 2026-10-25)
- Temporal — Temporal Patterns (source reviewed 2026-10-25)