How it works
A compensating action is paired with an operation that creates an external side effect. If an agent reserves inventory, creates a ticket, changes a record, or schedules work, the harness records enough information to perform the corresponding correction. A later failure can then trigger that correction under an explicit recovery policy.
A typical control sequence is:
- Validate that the forward operation is permitted.
- Record its intent and the parameters needed for compensation.
- Execute the operation and capture its confirmed outcome.
- Continue the workflow from a durable checkpoint.
- If a later step fails, select and execute the registered compensation.
- Record whether compensation succeeded, failed, or produced an unknown outcome.
Compensation is usually semantic, not a literal rewind. Cancelling a reservation may neutralize its business effect, but it does not erase notifications, audit events, timestamps, or actions already taken by another system. The harness must therefore define what “reversed” means for each operation.
The corrective operation also needs its own execution controls. It should tolerate retries where possible, use current authorization checks, and expose an unresolved state when the harness cannot establish whether either the original action or its compensation completed.
Why it matters in an agent harness
Agent workflows often cross boundaries that do not share one transaction. A model may decide what to do, but tools perform the actual writes across files, databases, queues, APIs, and human-facing systems. Once a tool call succeeds, a later model error or provider failure cannot make that side effect disappear.
Compensating actions give the harness a bounded recovery path. They reduce the pressure to treat every partial failure as a manual incident and make multi-step work safer to resume. More importantly, they force the designer to state which effects are reversible, which are only neutralizable, and which are irreversible.
That distinction affects several engineering outcomes:
- Control: Recovery behavior comes from a declared policy rather than an improvised model response.
- Reversibility: The harness can unwind completed steps in a defined order when the workflow cannot finish.
- Observability: Operators can see the original action, its compensation, and the outcome of both.
- Permission safety: Compensation can have a different permission scope from the forward action. Creating a draft and deleting a published record are not equivalent authorities.
- Failure containment: A failed downstream step does not have to leave every earlier side effect active.
- Evaluation: Tests can inject failures after each step and verify that the expected corrective operations occur.
Compensation does not make an action safe by itself. If the harness cannot distinguish failure from an unknown outcome, immediately compensating may create a second error. For example, retrying or cancelling an operation that might still be in flight can duplicate work or contradict an eventual success. The recovery contract must say when to retry, when to compensate, and when to stop for reconciliation.
Irreversible effects need a different boundary. Sending a message, disclosing data, or triggering physical work may not have a meaningful inverse. Those operations belong behind stronger approval gates, delayed-commit patterns, or narrower authority rather than a fictional compensation function.
Compensating Action vs rollback
The terms are sometimes used loosely, but the distinction changes recovery design. A rollback usually restores state controlled by one transactional system or returns execution to a known checkpoint. A compensating action performs a new operation that corrects the effect of an earlier one.
| Decision axis | Compensating action | Rollback |
|---|---|---|
| Mechanism | Executes a forward corrective operation | Restores or discards state within a controlled boundary |
| Result | Semantically neutralizes an effect | Attempts to recover an earlier state |
| External traces | Usually remain visible | May disappear inside the transaction boundary |
| Failure handling | Compensation can fail independently | Rollback is governed by the transactional mechanism |
| Best fit | Cross-tool and distributed workflows | Databases, snapshots, or isolated execution state |
A workflow can use both. It might roll back uncommitted local state while compensating for an external reservation that already succeeded. Treating those mechanisms as interchangeable hides different permissions, evidence requirements, and failure states.
The Rifty take
We treat compensation as part of the forward operation's contract, not cleanup invented after failure. We accept that semantic reversal is imperfect, but require the remaining effects and uncertainty to be legible. If an action has no credible compensation, the harness should reduce its authority or move the action behind a stronger control boundary.
Common failure modes
- Defining compensation after deployment instead of alongside the forward operation.
- Assuming the corrective action restores the exact previous state.
- Failing to persist the identifiers and prior values needed for recovery.
- Retrying a non-idempotent compensation without checking its recorded outcome.
- Running compensation when the original operation has an unknown outcome.
- Giving the recovery path broader permissions than the forward workflow requires.
- Compensating steps in creation order when dependencies require reverse order.
- Reporting the workflow as recovered while one compensation remains failed or pending.
- Treating irreversible effects as reversible because a nominal “undo” tool exists.
- Omitting compensation attempts and residual effects from the execution journal.
Frequently asked questions
When should a workflow define a compensating action?
Define one whenever a completed step creates a side effect that should not remain active if later work fails. Design it with the forward operation, while identifiers, permissions, ordering constraints, and the practical meaning of reversal are still explicit.
Does a compensating action restore the exact previous state?
Usually not. Compensation creates a new corrective event that semantically neutralizes an earlier effect. Audit entries, notifications, timestamps, or third-party observations may remain. The recovery contract should specify both the intended corrected state and any residual effects.
Should an agent decide when to run compensation?
The harness should make that decision through deterministic workflow state and recovery policy whenever possible. A model may help classify an exceptional condition, but it should not improvise destructive correction without verified outcomes, bounded permissions, and a recorded control decision.
What if the compensating action also fails?
Record the failure as an unresolved recovery state and preserve everything required for a safe retry or reconciliation. Do not mark the workflow recovered. Apply retry limits, check for idempotency, and escalate when the outcome remains unknown or the correction requires new authority.
How should compensating actions be tested?
Inject failures after each side-effecting step and verify the selected compensation, execution order, permissions, retry behavior, and final workflow state. Tests should also cover duplicate delivery, compensation failure, irreversible residual effects, and cases where the original operation has an unknown outcome.