The industry's answer to "what happens when an agent does the wrong thing" is the Saga pattern – a thirty-year-old distributed-transactions primitive, now shipped and mature in Temporal and AWS Step Functions. It works. It also has a precondition that agent autonomy is specifically designed to destroy: you can only author the undo for an action you knew the agent would take. The more autonomous the agent, the less of the rollback toolkit applies. This is not a tooling gap waiting to be filled. It is an architectural boundary, and deciding where your system sits on it is the most consequential design choice an enterprise architect will make this year.
Ask an experienced architect how to roll back a multi-step agent that failed halfway, and you will get a good answer fast: the Saga pattern. It is the correct answer, and the tooling is real. Temporal ships a Saga class – you call addCompensation() to register an undo after each successful step, and if a later step fails, compensate() runs the accumulated undos in reverse (last-in-first-out) order. AWS Step Functions does the same through Catch blocks that route a failed state to explicit compensation states. This is not theoretical, not a 2026 novelty, and not missing. Distributed systems solved cross-service rollback years ago, and agent orchestration inherited the solution intact.
So the easy version of this memo – "agent platforms gave you tool-calling but forgot tool-uncalling" – is simply wrong, and any architect would catch it in a paragraph. The interesting problem is one layer down, and it is not a gap in the tooling. It is a tension between the tooling's core assumption and the entire premise of an autonomous agent. Two assumptions, specifically. The Saga pattern assumes failures announce themselves. And it assumes you knew, at design time, every action that might need undoing. Agents violate both – and the violation gets worse precisely as the agent gets more capable.
Failure one: the step that succeeds at the wrong thing
A Saga compensates on failure. A step throws, times out, returns a 500, and the orchestrator catches it and runs the inverse. The whole mechanism is triggered by a detectable fault. This is exactly right for microservices, where a payment either processes or errors, and the error is the signal.
It is the wrong shape for agents, because the agent failure mode that matters does not throw. An agent that sends a confidently-worded email to the wrong recipient returns success. An agent that approves a refund it should have denied returns success. An agent that files a perfectly-formatted ticket against the wrong account returns success. The tool call executed cleanly; the side effect landed; no exception was raised. The agent did precisely what it decided to do, and what it decided to do was wrong. The Saga never fires, because from the orchestrator's point of view nothing failed.
This is the failure mode the durable-execution vendors have quietly conceded they do not address. Read the reference architectures closely and they enumerate what durable execution does not fix: hallucinations, runaway loops, evaluation drift. Durable execution guarantees your workflow replays safely after a crash. It guarantees exactly-once side effects. It does not – and cannot – make a wrong decision detectable as a failure, because the wrongness is semantic, not operational. Compensation triggers on exceptions. The expensive agent errors do not raise one.
So the first half of the compensation toolkit applies only to the half of agent failures that look like traditional failures – the crash, the timeout, the malformed call. For the half that look like success, you have no trigger. You cannot compensate a transaction you do not know went wrong.
Failure two: you cannot pre-author the inverse of an action you did not foresee
The deeper tension is structural, and it goes to the definition of an agent.
The Saga pattern works because the set of forward actions is fixed and known at design time. Book hotel, book flight, book car – three steps, written by the architect, each paired with a hand-authored compensator: cancel hotel, cancel flight, cancel car. The inverse exists because a human wrote it in advance, having enumerated every step the workflow could take. Compensation is a predetermination exercise: for every action you know the system will perform, you author its undo ahead of time.
Now state what an autonomous agent is. An agent chooses its actions at runtime. The entire value proposition – the reason you reached for an agent instead of a hard-coded workflow – is that you did not have to enumerate the action sequence in advance. The agent decides, in the moment, which tools to call and in what order, in response to inputs you could not fully anticipate. That is not an incidental property. It is the definition.
These two facts collide. You can only register a compensating action for an effect you predetermined, and an autonomous agent's defining feature is that its effects are not predetermined. You cannot write the inverse of an action you did not know the agent would take. The Saga pattern requires a fixed action set; agentic autonomy is the deliberate removal of a fixed action set. The more genuinely autonomous the agent – the wider its tool access, the freer its planning – the larger the space of actions for which no compensator was ever authored, because no human enumerated them.
Name the line where this bites: the compensation boundary. On one side, the agent operates within a fixed, predetermined action set, every forward step has an authored inverse, and the full Saga toolkit applies. On the other side, the agent's autonomy exceeds the set of actions you compensated for in advance, and rollback becomes improvisation – you are now writing the undo after the unexpected action already executed, which is forensic cleanup, not compensation. Every agent system sits somewhere on this boundary. Almost no architecture diagram marks where.
The obvious objection is that you can have it both ways: constrain the agent to a fixed, well-typed set of tools – ten functions, each with a hand-authored inverse – and you get an agent that is both autonomous and fully compensable. This is correct, and it is also the entire argument restated as if it were a refutation. An agent confined to ten inverted tools is compensable precisely because you moved it toward the predetermined end of the boundary – you re-enumerated its action set, which is the thing autonomy was supposed to spare you from doing. That is a legitimate and often wise design, but notice what it costs: every tool you add to widen the agent's reach is another inverse you must author, and every action that is a composition of tools – the agent chained four calls in an order you did not anticipate to produce an effect none of them produces alone – has no pre-written compensator, because you inverted the individual tools, not the emergent sequence. The practitioner literature on Saga orchestration already names this ceiling from the microservices side: extending a fixed workflow to compensate a path the original flow did not contemplate is, in one engineer's words, next to impossible without rebuilding the flow. Constraining the toolset does not dissolve the boundary. It relocates the agent to the compensable side of it – which is exactly the trade the boundary describes, made deliberately rather than by accident. The objection is not wrong; it is the memo's thesis wearing the costume of a counterexample.
Why checkpointing is not the escape hatch
The most common move at this point is to reach for LangGraph's checkpointer and call the problem solved. It is worth being precise about why that is a category error, because the confusion is widespread and it is exactly the kind of imprecision that produces a fragile system.
Checkpointing gives you replay and resume. When an agent crashes mid-workflow, a checkpointer – PostgresSaver, RedisSaver – lets you restore the agent's state and continue from the last saved point rather than restarting and re-burning tokens. LangChain's own documentation is precise about what this is for: conversation continuity, human-in-the-loop, time travel, and fault tolerance. That is genuinely valuable, and for single-service workflows that complete in minutes it is often enough. But replay is not rollback. Restoring the agent's internal state does nothing to reverse the external side effects it already committed. If the agent sent the email before the crash, resuming from a checkpoint does not unsend it. The clearest tell is in the practitioner guidance itself: the recommended way to make a LangGraph resume safe is to give every external API call an idempotency key, so that a replay does not fire the side effect twice. That advice is an admission – the framework re-runs the action on resume, and the burden of making the re-run harmless falls on you. Checkpointing recovers the agent; compensation reverses the world. They are different primitives solving different problems, and an architecture that uses the first while believing it has the second is one incident away from learning the difference. The orchestration guides are explicit that you add Temporal-style durable execution on top of checkpointing precisely when your workflow has cross-service side effects that need compensation – the two are layers, not substitutes.
The decision this actually forces
The compensation boundary is not a problem to be solved. It is a trade-off to be located, and locating it is the architect's real work.
Every step you take toward compensability is a step away from autonomy. A fully compensable agent is one whose action set you have fully enumerated and inverted in advance – which is to say, a deterministic workflow with a language model picking branches, not an autonomous agent. A fully autonomous agent is one you cannot completely compensate, because you cannot author inverses for actions you did not foresee. There is no architecture that gives you both, and the durable-execution vendors, read honestly, are selling reliability by quietly pulling systems back toward the deterministic end – their reliability guarantees strengthen exactly as agent autonomy weakens. That is not a criticism of the tools. It is the shape of the problem they are solving.
So the design questions are concrete. First: for this workflow, what is the actual blast radius of an uncompensated wrong-but-successful action? An agent that drafts emails for human approval has a compensation boundary that does not matter, because the human is the compensator. An agent that sends them autonomously has a boundary that matters enormously. The architecture should put irreversible, high-blast-radius actions inside the predetermined set – behind authored compensators or human gates – and reserve genuine autonomy for the reversible, low-stakes surface. Second: which of your agent's actions are actually reversible? Compensation assumes an inverse exists. You can cancel a booking; you cannot fully unsend a message a human already read, and you cannot un-disclose data an agent already exposed. The set of irreversible actions is the set that must never reach the autonomous side of the boundary, full stop. Third: are your compensating actions themselves idempotent? The Saga literature is emphatic that they must be – if a refund's compensator runs twice under retry, you have refunded twice – and an agent invoking compensation dynamically makes this harder to guarantee than the static microservice case the pattern was designed for.
Bottom line
The agent-rollback problem was never that the primitive was missing. The primitive is thirty years old and shipped in every serious orchestrator. The problem is that the primitive has a precondition – a predetermined, fault-signaling action set – and autonomy is the systematic removal of exactly that precondition. Compensation and autonomy trade against each other, continuously, and there is no point on the curve that gives you the full measure of both.
The forward call: within the next year, the agent-platform marketing that currently sells "autonomous agents" and "reliable rollback" as compatible features in the same sentence will quietly bifurcate. The serious platforms will start describing a spectrum – constrained, fully-compensable workflows at one end and autonomous, best-effort-recovery agents at the other – and will price and position them differently, because their own field teams will have learned that the customers who wanted both got neither. The tell will be the appearance of a new tier in the orchestration products: something like "governed autonomy," which is the marketing department's name for the compensation boundary, drawn at last on the diagram where it belonged from the start.
The architect who draws that boundary deliberately – who decides, per action, which side of it each capability sits on – ships a system that degrades predictably. The architect who treats compensation as a feature they bought rather than a boundary they must place ships one that works in the demo and improvises in production. The pattern is old and proven. The mistake is believing it covers ground that autonomy, by definition, removed from under it.
Sources: Temporal Saga class semantics – addCompensation() / compensate(), reverse-order (LIFO) execution, and the requirement that compensators account for whether the action they undo actually executed – per Temporal SDK documentation and Temporal's Saga pattern guides (temporal.io, "Saga Pattern Made Easy" and "Compensating Actions"). AWS Step Functions compensation via Catch-block routing to undo states, reverse-order rollback, and the idempotency requirement on compensating actions, per AWS Step Functions Saga walkthroughs (Step Functions Saga implementations on Medium/DEV, 2026; theburningmonk.com), which also note the difficulty of extending a fixed Saga flow to compensate an unanticipated path. LangGraph checkpointer model (PostgresSaver, RedisSaver), "time travel" as replay/inspection, and the explicit framing of checkpointers as conversation continuity / human-in-the-loop / fault tolerance – per LangChain's persistence documentation (docs.langchain.com); the idempotency-key requirement for safe resume per LangGraph persistence practitioner guides (abstractalgorithms.dev, 2026). The enumeration of what durable execution does NOT fix (hallucinations, runaway loops, eval drift) and the durable-execution primitive landscape per the AppScale durable-execution reference architecture (2026). Multi-agent state-failure characterization (partial writes, half-changed state requiring forensic recovery) per the MAST failure taxonomy (NeurIPS 2025) and TierZero's state-failure analysis (2026). Cross-references to prior Signal Memo coverage: substrate vs. broker. The "compensation boundary," the success-at-the-wrong-thing failure analysis, the autonomy-versus-compensability trade-off, and the treatment of the constrain-the-toolset objection are original to this memo.