Compensation Is a Runtime Contract, Not an Error Prompt

An autonomous workflow has approved a refund, sent a customer message, reserved inventory and submitted a purchase order. Then a downstream validation fails. The agent cannot make the world as though the workflow never ran. The email has arrived. The inventory may have been observed by another system. A supplier may already be acting on the order.

This is the recovery problem that governed autonomous organizations must design for before they admit agents to side-effecting work. A database rollback is the wrong mental model. External actions are not rows in a private transaction: they are business events with recipients, deadlines, counterparties and sometimes legal force. Recovery must therefore be a first-class runtime contract: declared before execution, durably recorded during execution and governed through to a valid business outcome.

The useful distinction is not success versus failure

Distributed-systems practice has addressed this condition for decades. The original Saga model breaks a long-lived transaction into smaller transactions. If the whole sequence cannot complete, compensating transactions amend the effects of the completed steps. Later business-activity specifications make the same point in explicit operational terms: long-running work can produce intermediate results that are visible outside the computer system, so aborting is often insufficient. Business logic may be needed to address work that already completed.

That history matters because agentic systems do not create a new category of failure. They increase the number of workflows able to take consequential actions without a person driving each step. The technical response should not be to ask an LLM, after an incident, to invent an apology, cancellation or refund. Those actions have their own consequences and authority boundaries. Their semantics must be designed and approved in advance.

Before a governed runtime admits a tool into a workflow, it should classify the tool operation by its effect class:

• Read-only: the operation observes state and creates no intended external effect.
• Idempotently retryable: the same request can be repeated within a stated scope without creating a duplicate effect.
• Compensatable: a completed effect can be addressed by a defined new business action.
• Irreversible: the effect has no reliable compensating action, even though follow-up communication or human remediation may still be possible.

These are not labels for a catalogue. They determine which workflow paths the runtime may execute after ambiguity, timeout or partial failure. An idempotency key can safely govern a repeated request; Stripe’s API is a familiar example. But it only prevents duplicate execution of that request. It does not reverse a charge, retract a message or undo a shipment that succeeded. Idempotency is a retry property. Compensation is a new business operation.

A compensatable action needs a complete contract

Calling an operation compensatable is inadequate unless the runtime knows exactly what compensation means and under what conditions it remains permissible. The contract should travel with the side-effecting tool, rather than live as informal knowledge in a runbook.

• Effect class and idempotency scope, including the identifier used to detect a repeated request.
• A durable operation receipt: the external reference, accepted payload, time, status and evidence needed to establish what occurred.
• A compensation command, or an explicit declaration that the operation is irreversible.
• The evidence required before compensation can be issued, such as a supplier confirmation, delivery status or customer record.
• The authority required for the compensation and the policy conditions that constrain it.
• A compensation deadline or expiry condition, because cancellation, refund and amendment rights often change with time.
• An escalation path and a set of permitted terminal business outcomes.

This is an AES architecture proposal derived from established saga and business-activity patterns. It turns recovery from application-specific improvisation into an enforceable admission requirement. A tool that cannot state its effect class, receipt and recovery semantics may still be useful for analysis. It is not ready for autonomous external action.

The runtime must coordinate outcomes, not API calls

A timeout at an API boundary does not tell the organization whether the external effect occurred. Retrying blindly can duplicate it; compensating blindly can create a second harmful action. OASIS business-activity guidance is clear that transport retries and timeouts cannot establish end-to-end agreement for long-running work. The governed runtime needs durable coordination above individual calls.

For every successful forward step, it should persist both execution state and the corresponding recovery metadata. That record is more than a trace. It is the state from which the organization can resume after a crash, investigate ambiguity and prove why a particular recovery path was chosen. The runtime’s own commands, receipts and recovery progress must be durable and observable; a central orchestrator does not become reliable merely by being central.

When a workflow diverges from its intended path, the runtime should select among four broad responses. First, retry a transient failure where the operation is idempotent and evidence indicates it did not complete. Second, use an alternate forward path where another permissible action can still reach the business objective. Third, execute declared compensation where completed effects must be addressed. Fourth, pause for human review when status is ambiguous, authority is insufficient or consequences are high-impact.

The ordering is deliberately not always backward. A replacement shipment may be preferable to cancelling an order. A partial refund may be more valid than attempting to restore an earlier financial state. A message correcting a disclosure may be necessary even though the original message cannot be unsent. Compensation does not restore an exact prior state. It moves the organization toward an allowed outcome under the actual conditions that now exist.

Delay the points of no return

Irreversible actions deserve different workflow geometry. Microsoft’s compensating-transaction guidance recommends delaying irreversible steps until critical validation has succeeded. For autonomous organizations, that means placing checks, evidence collection and required approvals before disclosure, contract acceptance, physical dispatch or other points whose consequences cannot be reliably unwound.

This does not mean agents should never perform irreversible actions. It means the runtime must make irreversibility visible in the plan and treat it as a governance boundary. A workflow that reaches such a step should have already established the necessary facts, authority and acceptable terminal outcome. If it cannot, the correct behavior is to stop before the effect, not to rely on a better recovery prompt afterward.

Recovery is organizational behavior

As participant count grows, saga systems depend increasingly on idempotency, isolation and observability. The same is true for an organization composed of agents, services and human operators. Each participant must tolerate repeated execution after a crash. Each consequential transition must be traceable. And the people assigned to escalation must receive a concrete case: what happened, what evidence exists, which compensations remain valid, which authority is needed and what outcomes policy permits.

BPMN compensation practice reinforces the design principle: completed activities are associated with dedicated compensation handlers, and a process can target a particular completed activity where order matters. The important idea is not BPMN itself. It is that compensation is modeled capability, not an unstructured exception branch.

A governed autonomous organization should therefore measure more than forward completion. It should know how many side-effecting operations have declared recovery contracts; how often the runtime resolves a case through retry, alternate forward recovery, compensation or review; how long cases remain unresolved; and how many reach each terminal business outcome. These measures reveal whether autonomy is operationally recoverable, not merely productive when everything goes right.

Build for the world that has already changed

The most dangerous recovery design is one that assumes failure happens before action. In autonomous operations, failure frequently arrives after a valid action has produced an external effect and before the organization has reached its intended outcome. At that point, the question is not “how do we roll back?” It is “what is the next authorized action that leaves the business in a valid state?”

Make the answer executable before the agent acts. Classify the effect. Persist the receipt. Declare the compensation or irreversibility. Bind evidence, authority, deadlines and escalation to the contract. Then let the runtime coordinate recovery as carefully as it coordinates forward work. That is the difference between an agent that can call tools and an autonomous organization that can recover responsibly.

Sources

• Hector Garcia-Molina and Kenneth Salem, “Sagas” — https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
• OASIS, WS-BusinessActivity 1.1 — https://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html
• Microsoft, Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
• AWS, Saga orchestration pattern — https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-orchestration.html
• Stripe, Idempotent requests — https://docs.stripe.com/api/idempotent_requests
• Camunda, BPMN compensation events — https://docs.camunda.io/docs/components/modeler/bpmn/compensation-events/