# Make Agent Actions Reversible > Source: > Published: 2026-11-01 12:22:19+00:00 # Make Agent Actions Reversible Originally published at Trida AI. Most agent failures are not hard to detect. They are hard to take back. Consider the ordinary version. A run reserves stock, charges a card, and sends a confirmation, and only then discovers the delivery address it used is a depot that closed last spring. Every step succeeded. Every tool returned green. The problem is that the work now exists in three other systems, and deleting the line from your own run log does not touch any of it. Teams already plan for two failure shapes, and it is worth being precise about why neither plan covers this one. A retry handles the action that never landed. Idempotency handles the action that landed twice. The case above is a third shape: the action landed once, exactly as instructed, and the instruction was wrong. There is no error to retry and no duplicate to suppress. What the run needs is the action's opposite, and it needs to have been designed before the run started, because the middle of a failed run is a bad place to invent one. Distributed systems have a name for this already: the saga pattern. In the saga orchestration pattern, a coordinator runs a sequence of steps across services, and when a later step fails it runs compensating transactions for the steps already completed. Temporal's saga pattern describes the same discipline from the workflow side: register each step's compensation as the step completes, then run the compensations in reverse order when something fails. One detail in that write-up deserves stealing outright. A compensation registered before its step runs has to be idempotent, because the step may have failed halfway through, and nobody can know how much of it landed. Compensation never rewinds anything. A released reservation comes closest: the hold disappears and the world looks as it did before. A charge is different. It stays on the customer's statement, and what arrives days later is a second line that cancels it out; the customer has seen both, and may have acted on the first. A sent email is different again: there is no second line, only a follow-up that has to explain the first. So "reversible" is not one property but three, and the design work starts by sorting every action an agent can take into its bucket: Freely compensable: reservations, holds, drafts, internal records. An opposite action restores the prior state, and nobody outside the system ever saw the first one. Compensable at a cost: charges, bookings, anything a customer or another team can observe. The compensation works, but it leaves a residue: a refund that takes days to settle, a cancellation fee, a correction email that has to explain the first one. Not compensable: a sent message, a published page, a submitted form. There is a follow-up action, sometimes, but there is no opposite one. The pattern literature has a term for where the third bucket begins: the pivot transaction, the point of no return in a sequence, after which the earlier steps can no longer be compensated and everything remaining must be able to run forward to completion. (The pivot itself sits on the boundary: either the last step that can still be undone, or the first that cannot.) Agent runs have pivots whether anyone names them or not. Naming them is the work. Ordering follows from the sort. Everything compensable goes before the pivot; the irreversible action goes last, after the rest has succeeded. And when an irreversible action cannot wait its turn, that is not an ordering problem anymore. It is an approval gate, and it should be built as one. None of this survives as a prompt instruction. "Remember to undo your steps if something fails" asks the model to reconstruct, under failure conditions, exactly the information that was available for free at the moment each action completed. The mechanism has to be bookkeeping, kept by code. The action gateway and the register: forward writes run left to right, and on failure the compensation runner works back along the register in reverse order. So the agent's writes pass through a gateway. The gateway knows each action's class, and it refuses a compensable action that arrives without a named compensation, the same way a schema check refuses a malformed call. When a tool returns, the gateway writes one entry in an action register: what was done, the identifier the compensation will need (the reservation ID, the payment ID, taken straight from the tool result, never reconstructed from the transcript later), and the compensation itself. If a later step fails, or a person aborts the run, the compensation runner reads the register backwards. Reverse order is not a nicety; the refund has to land before anyone tries to reuse the released stock, and each compensation may depend on the state the previous one restored. Two smaller points decide whether this works in practice. Compensations are registered before their step runs whenever the step can fail halfway. Temporal's docs offer both timings, registration before or after the step, and call "before" the safer default when a step has side effects, for the idempotency reason above. And compensations get the same engineering as forward actions: their own keys, timeouts, and error reporting, because a compensation retried blindly can refund a customer twice. When a compensation itself fails, it does not disappear into a log file. It escalates to a person with the register attached. A half-undone run is precisely the state nobody should first learn about from a customer. The action register for one failed order, as the run leaves it: two compensations in reverse order, one residue the customer will see, and the irreversible step that never fired because it was scheduled last. Example values, invented for illustration. Read the example register in Figure 2 and notice what it gives you that a trace does not. The trace says the run failed at address validation. The register says what the failure costs, what has already been put back, what residue remains (the customer will watch a charge and a refund cross on the statement), and what never happened at all. That last line is the ordering rule paying off: the confirmation email was the run's pivot, it sat after validation, and so there is nothing to apologise for. Some systems offer nothing to compensate with. No cancel endpoint, no refund operation, a form that only submits. An action against such a system is irreversible in practice whatever the design document says, and it should be gated like one until the vendor gives you a way back. Compensation also assumes the world holds still while you use it, and it doesn't. If the released unit was the last one and somebody else buys it in the meantime, the forward path cannot simply be re-run. If the parcel has already left the depot, cancelling the shipment turns into an intercept request with a price attached. Compensation restores consistency. It does not restore the past, and plans that quietly assume otherwise tend to surface during incidents. There is a cost side too. Every forward action acquires a partner that needs testing, and the pair needs testing together, against partial failures first and the happy path second. A compensation that has never been exercised is a hope with a function name. For a low-stakes internal write that a person reviews before anything depends on it, an honest log and a manual fix can be the proportionate answer. The register earns its keep where the writes are valuable, fast, or hard to watch. The question to ask of any agent design fits in one line: for each thing this run can do, what is its way back, and who wrote that down before the run started? If the answer is that the team would figure it out at the time, the hole in the design is sitting exactly where production failures live. If your agents write to systems your customers can see — payments, bookings, outbound messages — and the way back from a bad run is still improvisation, bring the workflow through Trida AI's intake and we will map each action to its compensation with you. ## Key Takeaways - •Every tool returned green. - •This story was reported by **Dev.to** , covering developments in the**dev** space. - •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage. 📖 Continue reading the full article: [Read Full Article on Dev.to →](https://dev.to/tridaai/make-agent-actions-reversible-b28)