AI Agent Sagas: Orchestration vs Choreography

Choose orchestration when one workflow needs clear control and ordered recovery. Choose choreography when services can act independently on stable events. For either model, name an outcome owner and define how failed or uncertain actions are resolved.

A saga links local transactions across services. For an AI agent placing an order, that could mean reserving stock, taking payment and requesting dispatch. The agent proposes actions; services enforce permissions and record what happened.

Quick Comparison

A hybrid can put payments and stock under a coordinator while events trigger notifications and analytics. Each business action still needs one authoritative trigger.

Neither model guarantees exactly-once external effects. Both need duplicate protection, bounded retries, payment-status checks after timeouts, and tested compensation. Compare support costs in £ per completed saga - not hosting costs alone - and keep approvals, tool results and recovery records outside the agent’s control.

::: @figure {AI Agent Sagas: Orchestration vs Choreography} :::

The Saga Pattern in Microservices | Orchestration VS Choreography | Distributed Transactions

Orchestration: One Coordinator Directs the Saga

The coordinator owns the workflow state, chooses the next action and records each outcome. Each service still validates requests and commits its own local transaction. The coordinator controls sequencing, not service data.[7]

In the retail order saga, that means deciding whether to reserve stock, retry payment or release stock.

Workflow State and Recovery Decisions

Persist the saga ID, workflow version number, current state, completed steps, command IDs, deadlines and compensation status. The coordinator makes recovery decisions, using retry limits and recovery rules defined for each command - not one blanket policy. Durable checkpoints let execution resume from the last confirmed boundary after a crash.[8]

A timeout is not a confirmed failure. A confirmed payment decline can trigger stock release. A missing response, however, requires checking payment status against the original command ID or idempotency key. Proceed on confirmed success, retry only when safe and escalate unresolved outcomes.[9] Compensate only for completed effects, in reverse dependency order where appropriate.[7][8]

Execution History, Debugging and Outcome Ownership

Expose a timeline of commands, attempts, responses, timeouts and compensation results. This shows the exact boundary where execution stopped; correlated service logs and traces help explain why.[5][6]

The coordinator owns the workflow outcome. A named workflow owner is accountable for the customer-level result, while service teams own local correctness. Named states make branch points and long waits explicit. A pending approval, for instance, needs a recorded deadline and escalation rule - not a running process that waits indefinitely.[8]

Coordinator Reliability and Service Contracts

Central control does not mean a single process. Use replicated workers, durable storage and task claiming or leader election to prevent duplicate decisions during recovery and maintain a single source of workflow truth. Preserve workflow versions for in-flight executions so a saga started under one set of rules can complete safely after a new deployment.[8] As the workflow grows, monitor queue backlog, execution latency and stuck workflows.

Command contracts must define valid states, what a timeout means, when retries are safe and how compensation works. Tie these contracts to business capabilities, not private database fields or internal status codes. The next model moves these decisions into service events rather than a central workflow.

Choreography: Services Respond to Events

Orchestration centralises decisions. Choreography spreads them across event handlers: each service commits locally, publishes a domain event and lets subscribers decide what happens next.[1][12][3][14] Use a transactional outbox so the state change and event record commit together. Handlers still need idempotency because delivery is usually at-least-once.[11][13][15]

Choreography reduces central control, but makes visibility and recovery depend on the event graph. Event contracts and recovery paths become the main points of control.

Define event-to-action links explicitly: OrderPlaced can trigger payment authorisation and stock reservation; StockReserved can trigger fulfilment; PaymentAuthorised can unblock dispatch; OrderDispatched can trigger notification. Define failure events and their handlers with the same precision. Subscribers own these responses; responsibility is distributed, not eliminated.[1][12][3][14]

Service Autonomy and Event Contracts

Publish facts such as PaymentAuthorised, not instructions dressed up as events. Subscribers decide how to respond, but they still depend on the event schema, its meaning and its delivery rules.

Define the event name, version, event ID, order ID, correlation ID, causation ID, timestamp and required business facts. Document ordering, retention and duplicate behaviour too. Small flows with stable contracts and clear event paths are easier to maintain. Fewer direct commands does not mean fewer dependencies.[10][3]

Tracing Events and Assigning Outcome Ownership

Carry correlation and causation IDs through processing records, including attempts, retries, duplicates and compensation status. To locate failures, operators need payload versions, timestamps, consumer status, retry counts and dead-letter records. These records are the only reliable way to reconstruct who saw what, when and why.

Use a read-only projection for visibility, not control. Still assign a named business outcome owner: service teams own local processing, while the outcome owner defines completion, cancellation, escalation and customer communication.[16][17][18]

Event Dependencies and Recovery

Maintain an event catalogue and dependency map covering subscribers, expected responses and compensation paths. As more participants join, hidden dependencies, event-cycle risks and investigation effort increase.

Name owners for timeout detection, retries and compensation triggers. Consumers must store pending state for out-of-order arrivals: arrival order is not business order. Compensate independent branches in parallel, but treat voids and refunds as separate transactions, each with its own failure paths.[1][4][14]

Orchestration vs. Choreography: Trade-offs

The choice is where coordination lives - not whether it exists. Orchestration centralises decisions; choreography distributes them.

With both patterns defined, the next decision is where control should sit for this saga.

Choose by Complexity, Risk and Accountability

Start with accountability. If one team must explain a high-risk action, its approval and its recovery, orchestration often gives that team a clearer control point.

Before choosing, check the operating rules:

• Outcome: name who declares completion, failure or manual intervention.
• Retries: define retryable failures, maximum attempts, backoff, timeouts and an overall deadline.
• Agent constraints: limit tools by role, scope, amount and approval requirement. Treat generated instructions as requests, not authority.
• Evidence: distinguish proposed, authorised, attempted, completed and compensated actions.

Compare Build and Support Costs

For UK SMEs, compare total support effort, not just hosting bills. Removing a coordinator shifts costs into event design, instrumentation and recovery. It doesn't remove them.

Calculate cost per completed saga = (recurring infrastructure + engineering support + incident response + manual recovery costs) ÷ successful sagas. Use actual £ figures from the same reporting period.

Keep one-off build costs separate. Report failed, retried and manually recovered sagas alongside the result, so a low unit cost doesn't hide poor outcomes.

Combine Both Models with Clear Control Boundaries

Hypothetical design: an order orchestrator owns payment authorisation and stock reservation. Once both succeed, it publishes OrderReadyForFulfilment. The orchestrator authorises high-risk tool calls; downstream services handle notifications and analytics. The orchestrator owns core retries, compensation and escalation; consumers own their separate side effects.

That boundary works only if duplicate delivery cannot trigger a duplicate business action.

Give each business action a single authoritative trigger. The next section shows the controls that stop duplicate execution.

Reliability Controls for Both Models

Both models need retries, reconciliation and compensation. Neither guarantees exactly-once external effects. In orchestration and choreography alike, a third party may receive a request even if the caller times out. Persist the last known state and treat a timeout as an unknown outcome, not proof of failure.[19][2] The controls take different forms, but share the same purpose: prevent duplicate side effects, make recovery visible and keep ownership clear.

Idempotency and Reliable Message Delivery

Start with duplicate handling. Whether a coordinator or an event subscriber drives a step, assign a stable idempotency key to each side effect. Persist its status and result, return the original result for duplicate requests, and reject parameter changes under the same key. Use sequence numbers where order matters.

A transactional outbox provides local atomicity, while a consumer inbox handles deduplication. Neither makes an external tool call atomic. If the tool does not support idempotency, persist a request reference ID and reconcile before retrying. Route outcomes that cannot be verified to manual review.[22][24][26]

Timeouts, Compensation and Manual Recovery

With duplicate handling in place, define how to recover when a step fails. Set per-step timeouts within the overall deadline, bound retries, and use exponential backoff with jitter. Retry transient failures, not validation errors or business rejections.

Send work that has exhausted its retries to a dead-letter queue. Include correlation data, failure details and a named escalation owner aligned with the saga’s control boundary. Unknown outcomes need reconciliation, not blind retries. Give operators external references, completed-step records and controlled recovery actions - not a blanket retry.[22]

Give compensation its own idempotency keys, retries, monitoring and escalation. An attempted refund is not a confirmed refund. Test crashes after external effects, delayed responses, duplicate and out-of-order events, provider downtime and failed compensation. Irreversible actions need corrective work or human review, not a promise of rollback.[19][22]

Agent Permissions and Audit Records

Reliability also depends on who can trigger a step and what evidence remains afterwards. Treat proposals as untrusted until validated. Protect both agent tool use and business execution by checking tool arguments, resource ownership and business rules. Use allowlisted operations and short-lived, least-privilege credentials, with human approval for high-impact actions.[23][25]

Record correlation and causation IDs, approvals, the policy version, validated arguments, tool results, recovery attempts and the final state. Keep these records outside the agent’s control. Use tamper-resistant storage, role-based access, retention rules and secret redaction, and retain as little personal data as possible. Only observed actions belong in the execution record; model reasoning does not.[20][21]

Conclusion: Make Control and Recovery Ownership Clear

Once you’ve weighed the trade-offs, decide who owns control and recovery. Orchestration centralises sequencing and recovery. Choreography distributes both, making event contracts and traceability the means of control. Choose based on business risk, workflow complexity and support capacity, not architectural preference.[19][2]

Name a business owner for the outcome and a technical owner for recovery.

Start with One Bounded Workflow

Start small: map the participants, expected outcome and failure paths. Before adding more agents or branches, show that the workflow can recover from partial completion. Measure recovery time, manual interventions and duplicate side effects.

Hokstad Consulting supports AI strategy, AI transformation and custom agent implementation.[27]

FAQs