The Saga pattern as the backbone of AI agents that act in the real world

For years, the Saga pattern has been explained as a solution for microservices, distributed databases and API calls. Something “backend”. Something “for architects”.

But if you look calmly at how a modern AI agent works, you notice something uncomfortable: an agent doesn’t reason, an agent acts. And the moment it acts on real systems, the problem in front of you is exactly the one Saga was solving.

Except now the thing making decisions isn’t a deterministic code flow, but a probabilistic model.

That’s where everything clicks.

The real problem isn’t intelligence, it’s damage

A modern agent can create tickets, change configurations, rotate secrets, deploy code, touch permissions, send emails, delete resources.

That is no longer “inferring text”. That is mutating state in distributed systems.

And when you mutate state, the same question always shows up: what happens if it fails halfway through? Or worse: what happens if it “believes” something failed when it didn’t? Or if it misreads an instruction?

“Oops, my bad” doesn’t cut it here. The damage is already done.

Thinking of an agent as a Saga

If you abstract a bit, an agent run looks like this:

• It decides on a plan.
• It executes a sequence of actions.
• Each action has side effects.
• The process can fail at any point.
• The agent can restart, retry or drift off course.

That is a Saga, even if nobody calls it that.

The difference is that in agents there are no transactions, no atomicity and no implicit guarantees. Everything has to be explicit.

Action + compensation + verification

If you want agents that don’t break things, every meaningful action should be defined with three elements:

1. The action itself: what is going to be done.
2. The verification: how you know it actually happened.
3. The compensation: what you do if you need to undo or mitigate.

You can’t always undo. But you should always know what you would do if things go wrong.

A simple example:

• Action: create a PR.
• Verification: check that the PR exists, has commits and points at the right branch.
• Compensation: close the PR or revert the commit.

A less comfortable example:

• Action: send an email.
• Verification: the provider confirms delivery.
• Compensation: send a second email with a correction.

That counts as a compensation too, even if it isn’t a technical one.

In agents, “rollback” almost never means undo

Here’s one of the most common mistakes: thinking of Saga in agents as “automatic rollback”.

In the real world you cannot:

• “Unsend” an email.
• “Undelete” something with no backup.
• Pretend a human action never happened.

In agents, compensation usually means:

• Creating a corrective action.
• Restoring from backup.
• Reverting with another action.
• Notifying a human.
• Opening a ticket that explains the state.

Saga doesn’t promise to go back. It promises not to leave the system in an incoherent state.

Two phases for dangerous tools

A powerful idea for agents is designing tools with explicit phases: plan/dry-run, prepare, commit, abort. This isn’t distributed two-phase commit. It’s defensive design.

Example: deleting a critical resource.

• In the prepare phase, you return what is going to be deleted, the impact and the dependencies.
• In commit, the only thing accepted is a confirmation token generated during prepare.
• In abort, the token gets invalidated.

This lets you audit, interrupt, demand human approval and, above all, keep the agent from doing something irreversible because it read the situation wrong.

That’s what makes an action “sagable”.

The Saga log as the agent’s real memory

LLMs don’t remember. They reinterpret.

A Saga needs external, persistent memory:

• Run identifier.
• Steps taken.
• Inputs and outputs.
• State of each step.
• Evidence (IDs, URLs, hashes).
• Idempotency keys.

Without this, the agent repeats actions, duplicates effects or convinces itself something never happened.

With this, you can resume, compensate, audit and explain what went on.

The difference between a toy agent and a serious one lives right here.

Idempotency: the non-negotiable law

An agent is going to retry. Always.

If an action isn’t idempotent:

• You duplicate resources.
• You duplicate notifications.
• You duplicate costs.
• You break trust.

Every action with effects needs an idempotency key and a way to check whether it already ran.

Saga without idempotency doesn’t work. In agents, it’s flat out suicidal.

Saga as a defense against prompt injection

This one is an interesting side effect.

If the agent is pushed into doing something it shouldn’t (whether through malicious text, a hidden instruction or a misreading), a Saga-style design:

• Forces verification.
• Forces logging.
• Forces going through phases.
• Allows compensation.

It won’t stop every attack, but it shrinks the impact and leaves a trail. In security, that matters more than it looks.

Types of compensation in agents

Not everything is technical. Compensation can be:

• Technical: rollback, restore, revert.
• Operational: open a ticket, create a task, raise an alert.
• Administrative: request approval, block the flow.
• Human: escalate, explain, ask for intervention.

An agent acting in the real world needs all four.

The final idea

If an agent can change the world, it has to assume it can get things wrong.

The Saga pattern isn’t an architectural fashion. It’s a philosophy of responsibility applied to systems without transactions.

AI agents heading to production don’t need more “intelligence”. They need boundaries, memory, compensations and defensive design.

And funnily enough, we already knew this years ago. It’s just that now the thing executing the steps isn’t a service. It’s an AI.

And that changes everything.