We are racing to hand AI agents real power — agents that book travel, file expenses, edit files, move money, and deploy code, mostly on their own. The demos are dazzling. But there’s a question the excitement keeps skipping, and it’s the one that matters most once an agent is loose in the real world: when the agent finishes step five of a six-step task and step five fails, what undoes steps one through four?
That’s not a new problem. It’s the exact problem software engineers solved decades ago for distributed systems, and the answer is the saga pattern — a way to run a multi-step operation so it ends either fully done or fully backed-out. The AI-agent world is quietly re-encountering a solved problem, and the discipline that made microservices safe to automate is exactly what will make agents safe to trust. Here’s the case for treating your agents like sagas.
🤖 An agent’s to-do list is a distributed transaction
Look at what an “autonomous” agent actually does on a real task. “Book my trip” becomes: search flights, hold a seat, charge a card, reserve a hotel, add it to the calendar, email a confirmation. Those touch half a dozen different systems, each with its own state, over a span of time. That’s not one action — it’s a distributed transaction, the same shape as any microservices workflow.
And distributed transactions fail partway all the time. The flight books but the hotel is sold out. The card charges but the calendar API times out. Partial success isn’t an edge case here; it’s the normal case. An agent that can only power forward — with no notion of undoing what it already did — will happily leave you with a charged card, a booked flight, and no hotel, then cheerfully report “task complete.” The missing ingredient isn’t a smarter model. It’s failure semantics.
↩️ Give every action an undo
The saga’s core move translates directly: for every reversible action an agent takes, register its undo before moving on. Booked a flight? Register “cancel flight.” Reserved inventory? Register “release it.” When a later step fails, you run those undos in reverse, and the world ends up as if the agent never started.
The subtlety that trips people up applies to agents too: an undo is not a rewind. To reverse a charge, the agent issues a refund — a new action that leaves a trace, not a magic restore of the past. Some things can’t be undone at all (more on that in a moment). But the vast majority of what agents do — reservations, drafts, holds, edits — can be given a real, explicit compensating action. The teams building genuinely trustworthy agents are the ones writing those undos deliberately, not hoping the model improvises one under pressure.
🔁 Assume every action might run twice
Agents retry. They re-plan, they loop, a tool call times out and gets fired again, an orchestrator re-dispatches a step it isn’t sure completed. Which means an agent action can easily run more than once — and an agent that re-sends the same email, re-files the same expense, or re-charges the same card on a retry is a menace.
The saga answer is idempotency: make each action safe to run twice, so a duplicate does no additional harm. Give each intended action an idempotency key; check “did I already do this exact thing?” before doing it again. This is doubly important for agents because their control flow is fuzzier than a hand-written workflow — a model deciding what to do next is far more likely to repeat itself than a deterministic state machine. Design as if every action will be attempted at least twice, because with an LLM in the loop, it eventually will be.
🛑 Put the irreversible stuff after a go/no-go
Some actions genuinely can’t be undone: sending money, sending a message, deleting data, deploying to production. The saga pattern has a precise idea for exactly this — the pivot, a point of no return. You deliberately order the work so that all the reversible steps happen first, then a single go/no-go checkpoint, and only after it do the irreversible actions run.
For agents, that checkpoint is where a human approval (or a strict automated gate) belongs. Everything before it, the agent can freely attempt and cleanly back out of. Everything after it is committed and should only ever run once the plan is guaranteed to complete. This single structural idea resolves most of the “should I let the agent do X autonomously?” anxiety: let it do the reversible things freely, and put the irreversible ones — spend, send, delete, deploy — on the far side of a gate. It’s the same discipline as the guardrails that keep agent tools from doing damage, applied to the sequence of actions rather than the tools themselves.
🎭 Who holds the plan?
A saga needs someone to coordinate the steps and drive the undos, and agents face the same choice: a central coordinator, or a loose swarm reacting to each other. The orchestrator-worker pattern — a lead agent that holds the plan and dispatches specialist workers — is simply orchestration applied to agents. And it has the same advantage it has for microservices: one place that knows the whole plan is one place that can cleanly decide what to undo when a worker fails. A leaderless swarm of agents reacting to each other is choreography, and it drifts into the same “nobody can explain what actually happened” fog that choreographed microservices do — except now with a non-deterministic model at every node. For anything that touches money or the real world, give the agent fleet an orchestrator that owns the plan.
🧠 Why this matters now
The uncomfortable truth is that most of today’s agent frameworks are strong on planning and weak on recovery. They’ll happily generate a six-step plan and execute it, but ask “what happens when step four fails after steps one through three already changed the world?” and the honest answer is often “it doesn’t really know.” That gap is not a model problem you can prompt your way out of — it’s an architecture problem the distributed-systems field already has a mature answer for.
Treat the agent’s work as a saga and the fog clears: register compensations, make actions idempotent, put irreversible actions past a go/no-go, keep a durable log so a crashed agent can resume instead of restart, and give the fleet an orchestrator that holds the plan. Pair that with the modeling discipline of domain-driven design for AI agents and the boundary-guarding of an anti-corruption layer, and you get agents you can actually let off the leash — not because the model got smarter, but because the system around it finally knows how to fail safely. The saga pattern turned 1987, and it may be the most important idea in AI agents that almost nobody in AI is talking about.
❓ Frequently Asked Questions
What does the saga pattern have to do with AI agents? A multi-step agent task — book travel, file expenses, edit files — touches many systems over time, which makes it a distributed transaction that can fail partway. The saga pattern is the established way to run such an operation so it ends either fully done or fully undone, using compensating actions. Applying it gives agents the failure recovery most frameworks lack.
How does a compensation work for an AI agent? Before each reversible action, the agent (or its orchestrator) registers an undo — “cancel the flight I just booked,” “release the inventory I just held.” If a later step fails, those undos run in reverse. Like any saga, the undo is a new action (a refund, a cancellation), not a literal rewind, and it should be defined deliberately rather than improvised.
Why do AI agent actions need to be idempotent? Agents retry and re-plan, so the same action can be attempted more than once. Without idempotency, that means duplicate emails, double charges, or repeated file edits. Giving each action an idempotency key — and checking whether it’s already been done — makes a repeat harmless. It matters more for agents than for hand-coded workflows because an LLM’s control flow is less predictable.
How do I stop an agent from doing something irreversible? Use the saga idea of a pivot, or point of no return. Order the task so all reversible steps happen first, then place a go/no-go checkpoint (a human approval or strict automated gate), and only run irreversible actions — sending money, deleting data, deploying — after it. Before the checkpoint the agent can cleanly back out; after it, the plan is committed.
Do multi-agent systems need an orchestrator? For anything touching money or the real world, yes. An orchestrator (as in the orchestrator-worker pattern) is a lead agent that holds the whole plan, which makes it the one place that can cleanly coordinate undos when a step fails. A leaderless swarm reacting to each other is harder to reason about and to recover — the same problem choreographed microservices have, amplified by non-deterministic models.
📚 Further Reading
- What Is the Saga Pattern? — the pattern this applies to agents
- The Orchestrator-Worker Pattern — orchestration for agent fleets
- Domain-Driven Design for AI Coding Agents — modeling the boundaries agents work across
- Anti-Corruption Layers — guarding the handoffs between agent contexts
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Building agents that fail safely means borrowing hard-won lessons from distributed systems and clean design. These five carry the ideas this article applies to agents.
- Microservices Patterns — Chris Richardson · Book. Where the saga, compensations, and idempotent-consumer patterns come from — the playbook you’re now pointing at agents.
- Learning Domain-Driven Design — Vlad Khononov · Book. Drawing the boundaries and contexts an agent fleet works across, explained approachably.
- Designing Data-Intensive Applications — Martin Kleppmann · Book. Why partial failure, retries, and duplicates are the norm in any multi-system operation — agents included.
- Release It! (2nd ed.) — Michael Nygard · Book. Timeouts, retries, and stability patterns — the resilience an autonomous agent needs when a step misbehaves.
- A Philosophy of Software Design — John Ousterhout · Book. Deep modules and clean interfaces — the design taste behind safe handoffs between agents.