What is the difference between compensation and rollback?

A database rollback discards uncommitted changes to restore the exact prior state; it works because nothing left the database. Compensation, from the saga pattern, applies to actions that already committed in separate systems — it runs a new, forward action that approximates the inverse. Compensation does not restore the prior state; it issues a counter-action, and only when a meaningful one exists.

What is the saga pattern?

The saga pattern, introduced in 1987, models a long transaction as a sequence of steps, each with a compensating action. If step N fails, the completed steps are compensated in last-in-first-out order. It is the standard way to get transaction-like safety across systems that cannot share a single atomic commit.

// field note · concepts

Compensation is not undo

Q: Can you undo what an AI agent did?

Only sometimes. If an action is compensable, you can run an inverse action that neutralizes its effect — create then delete, reserve then release. But many real actions have no inverse: a sent email cannot be unsent, a settled payment is not undone by a refund, and rows dropped with no backup are gone. An honest system distinguishes compensable from irreversible actions and tells you which is which before you approve.

The most dangerous sentence in AI-agent tooling is "don't worry, it can roll back." Sometimes it can. Often it can't — and the gap between those two is where real damage lives. Here's the honest model of what "rolling back" an agent actually means.

ChronoMCP field notes · Aug 2026 · ~5 min read

THE SHORT VERSION

Undo restores the exact prior state. It only works while nothing has left the system — like a database transaction that never committed.
Compensation (the saga pattern) runs a new, forward action that approximates the inverse — create then delete, charge then refund. It doesn't restore the past; it counter-acts.
Some actions have no inverse at all: a sent email, a settled payment, a published message. Calling that "reversible" is a lie — and the lie is what gets you hurt.
The fix isn't a better rollback engine. It's honesty: declare each action readonly, compensable, or irreversible, and surface the irreversible ones before anyone approves.

Three words that get used as if they're one

"Undo," "rollback," and "compensation" get thrown around interchangeably, and the sloppiness is expensive. They describe three different things:

Undo / rollback (in the strict sense) is what a database gives you inside a transaction. You changed rows, you didn't COMMIT, you ROLLBACK — and it's as if it never happened, because the changes never escaped the system's control. The prior state is restored exactly. This is a beautiful, strong guarantee, and it exists precisely because everything stayed inside one atomic boundary.

Compensation is what you're forced to use the moment an action leaves that boundary. You created a customer in a billing system and a record in a CRM and sent a welcome email — three separate systems, three separate commits. There is no single ROLLBACK that spans them. If step three fails, you can't restore the prior state; you can only issue counter-actions: delete the CRM record, delete the billing customer. That's compensation. It's forward motion dressed up as reversal.

Compensation doesn't rewind the world. It takes another step and hopes the step cancels out.

The saga pattern, in one paragraph

This isn't new. In 1987, Hector Garcia-Molina and Kenneth Salem described the saga: model a long transaction as a chain of steps, each paired with a compensating action. If the chain breaks at step N, you run the compensations for steps N-1, N-2, … 1, in last-in-first-out order.¹ LIFO matters: you undo the most recent thing first, because later steps often depend on earlier ones. Nearly four decades later, every distributed-systems team rediscovers the saga the first time they need "a transaction" across services that can't share one. AI agents are just the newest team to walk into that wall — except they walk into it autonomously, at machine speed, dozens of times an hour.

Where it breaks: actions with no inverse

Here's the part the cheerful "it'll roll back" glosses over. Compensation only works if a meaningful counter-action exists. For a huge and important class of actions, it doesn't:

Action	Reversibility	Why
Read a record	readonly	No effect to reverse. Safe to retry.
Create a DB row	compensable	The inverse is a delete of the id you got back.
Reserve inventory	compensable	Release the reservation.
Send an email	irreversible	It's in their inbox. "Please ignore" is a new email, not an un-send.
Settle a payment	irreversible	A refund is a new transaction with its own fees, delay and record — not a reversal.
Post to a public channel	irreversible	Screenshots exist the instant it's live. Deleting doesn't un-see.
DROP a table, no backup	irreversible	There is nothing to run an inverse against.

Notice that a refund is not filed under compensable-with-an-asterisk — it's irreversible, because refunding is not reversing. The money moved, fees were charged, the ledger recorded both legs, and the counterparty saw a charge appear and disappear. A refund is the honest best you can do, and it is still a new forward action with its own consequences. Pretending otherwise is how "we can always roll back payments" becomes a compliance finding.

Why the honest model is the safer one

The instinct, when you build a rollback feature, is to maximize how much it can reverse — to make the demo say "and it undoes everything!". That instinct is backwards. The valuable thing is not the size of the reversal set; it's a trustworthy boundary around it. A system that tells you, before you approve, "steps 1–3 are compensable, step 4 sends an email and cannot be undone" lets a human make a real decision. A system that says "don't worry, it rolls back" and quietly can't is worse than one with no rollback at all, because it manufactures false confidence at exactly the moment confidence should be lowest.

The design rule: reversibility is a property you declare and prove, never one you assume. No metadata about a tool? Its reversibility is unknown — and unknown is treated as dangerous, not as safe.

How ChronoMCP models it

This is the whole reason the mcp-compensate extension exists. An MCP server declares, per tool, one of three honest states — and, when compensable, the exact inverse tool plus a static parameter mapping (no LLM in the rollback path, because recovery is exactly where a hijacked agent would improvise):

{
  "reversibility": "compensable",        // "readonly" | "compensable" | "irreversible"
  "compensation": {
    "toolName": "delete_record",
    "parameterMapping": { "id": "$.output.structuredContent.id" }
  },
  "notes": "Removes the created record."
}

At runtime, ChronoMCP shows you that reality in the impact diff before anything commits. Compensable steps get their inverse queued in LIFO order in case a later step fails. Irreversible steps get a loud flag and wait for a human. And if an irreversible action does run and something downstream fails anyway, the report says plainly what could not be undone — it does not pretend the saga cleaned up a mess it structurally cannot clean. That honesty isn't a disclaimer bolted on the side; it's the feature.

FAQ

Can you undo what an AI agent did?

Only when the action is compensable — when a meaningful inverse exists (delete what was created, release what was reserved). Actions like a sent email, a settled payment, or dropped rows with no backup have no inverse and cannot be undone. An honest system tells you which is which before you approve, rather than promising a blanket "rollback."

Is a refund the same as reversing a payment?

No. A refund is a new transaction with its own fees, timing and ledger entries. The original charge still happened and is still on record. Refunding is the honest best-effort counter-action, but it does not restore the prior state, which is why a settled payment is modeled as irreversible, not compensable.

What is the difference between compensation and a database rollback?

A database rollback discards uncommitted changes inside one atomic boundary, restoring the exact prior state. Compensation applies once actions have committed in separate systems that can't share that boundary — it runs a new forward action approximating the inverse, and only when one exists.

See the honest model in action

Guard a demo server and watch a saga compensate what it can — and tell the truth about what it can't.

Read the quickstart → More field notes

Reference

Hector Garcia-Molina and Kenneth Salem, "Sagas," ACM SIGMOD Record, 1987 — the original description of long-lived transactions decomposed into steps with compensating actions.