AI Agent Compensation: Why Rollback Is Not Undo

TL;DR

Once reconciliation proves that an AI agent actually produced an unacceptable effect, the recovery problem changes. Retrying is no longer the primary question. The organization must determine whether the effect can be directly reversed, requires a compensating action, should be handled through forward recovery or containment, or cannot meaningfully be undone at all.

A compensating action is a new consequential operation. It needs authority, target-state preconditions, evidence, idempotency where possible, and its own failure handling. Restoring an old configuration snapshot or issuing an opposite command can overwrite legitimate concurrent changes and create a second incident.

Recovery should produce an acceptable new state. It should not pretend the original action never happened.

Introduction

An infrastructure agent is approved to modify backup retention from thirty days to forty-five.

Instead, an execution defect sets retention to seven days.

The mistake is discovered two days later.

Operations restores the retention policy to forty-five days.

Did they roll the incident back?

Not necessarily.

Recovery points may already have been removed. Workloads may have crossed the shortened retention window. Compliance evidence may need to record the period of exposure. A service owner may need to decide whether additional backups must be created or whether another recovery method is required.

Changing seven back to forty-five fixes the current setting.

It does not recreate what was lost.

This is the point where the language of rollback becomes dangerous. Infrastructure teams often use rollback to describe any operation intended to restore service after a bad change. In distributed agent workflows, several fundamentally different recovery mechanisms hide behind that word.

The previous companion, Reconcile Before You Retry: Recovering Uncertain AI Agent Actions, established whether an external effect actually occurred. This installment addresses what comes next when the answer is yes.

Stop Calling Every Recovery Action a Rollback

Use more precise terms.

A reversal directly negates a prior mutation where the original state and relevant concurrency conditions make that safe.

A compensating action performs a new business or technical operation intended to produce an acceptable state after the original effect cannot simply be reversed.

Forward recovery accepts that the original transition occurred and moves the system toward another valid state.

Containment prevents additional harm without claiming to repair existing effects.

Remediation addresses downstream consequences that remain after the technical state has been corrected.

An irreversible effect cannot meaningfully be undone through the original system.

These distinctions are operational, not semantic.

Microsoft’s current Compensating Transaction pattern explicitly warns that compensation does not necessarily restore the system to its exact original state. Concurrent changes and business rules may make a literal rollback unsafe or impossible.

That is exactly the problem an agent control plane must represent.

Compensation Is Another Consequential Action

An agent should not receive implicit permission to “undo whatever went wrong.”

Recovery can be as privileged as the original action.

Deleting a newly created object may destroy data another process has since attached to it. Revoking a role may remove access that was legitimately granted after the incident. Restoring yesterday’s firewall policy may erase today’s approved rule. Replacing an old database snapshot can discard valid transactions.

The compensation therefore needs its own execution envelope.

At minimum, bind:

• the original action and observed effect
• the approved recovery objective
• target identity and current state
• compensation operation and parameters
• responsible executor
• required preconditions
• residual effects that the action cannot repair
• applicable approval or preauthorization
• verification requirements
• timeout and retry behavior
• escalation path if compensation fails

Do not let the model derive these permissions from the statement, “the earlier action was wrong.”

The fact that an action caused harm does not authorize every conceivable repair.

Define the Recovery Objective Before Choosing the Command

Start with the state the organization needs, not with an inverse API call.

For the backup-retention example, the objective might be:

Reestablish the approved forty-five-day retention policy, determine whether required recovery points were lost, recreate protection where technically possible, preserve evidence of the shortened-retention interval, and identify any unrecoverable exposure.

That objective is much richer than:

set retention_days = 45

A compensation plan should distinguish the configuration that can be repaired from the consequences that remain, such as missing recovery points or exposure during the incident.

Restoring the approved retention setting repairs the current configuration.

Assessing lost recovery points and the exposure interval determines which consequences still require remediation.

Never Restore an Old Snapshot Blindly

A configuration snapshot is evidence of an earlier state.

It is not automatically the correct compensation.

Suppose a firewall policy originally contained:

Rule A
Rule B
Rule C

The agent incorrectly removes Rule B.

Before operations detects the problem, an authorized engineer adds Rule D.

The current configuration is:

Rule A
Rule C
Rule D

Restoring the old complete policy produces:

Rule A
Rule B
Rule C

Rule B is back.

Rule D is gone.

The organization fixed the agent’s mistake by creating another one.

Microsoft’s compensation guidance calls out this exact architectural concern: other work may occur after the original transaction, so compensation needs to account for concurrent changes instead of blindly restoring an earlier global state.

Prefer a targeted corrective operation when the target supports it.

Use object identities, resource versions, entity tags, generations, or equivalent concurrency mechanisms to ensure the recovery still applies to the state that was reviewed.

If the environment changed materially, return to planning.

Identify the Point of No Return Before Production

Some actions become qualitatively different after a particular transition.

Call that the point of no return.

Before it, the operation may be canceled or reversed predictably.

After it, the organization may only be able to compensate, contain, or remediate.

Examples include:

Microsoft now explicitly recommends defining irreversible steps and points of no return when designing compensation workflows.

The practical agent-control implication is straightforward:

Place stronger validation, approval, and evidence requirements before the irreversible transition.

Do not wait until afterward and assume “rollback” remains available.

Use Reconciliation Before Compensation

Compensation should operate on confirmed effects.

The previous companion established several reconciliation dispositions:

confirmed executed
confirmed not executed
executed but violated
superseded
unresolved

These outcomes should control recovery.

A confirmed not executed action generally needs no compensation.

An unresolved action normally needs more evidence before applying a potentially harmful inverse.

An executed but violated action is a strong candidate for compensation, containment, or remediation.

A confirmed executed action may still be completely acceptable and require no recovery.

The model should not infer compensation solely because the workflow entered an error state.

An error in the orchestrator and an unacceptable external effect are different conditions.

Build the Compensation Plan From Observed Effects

The plan should identify each material effect separately.

Consider a hypothetical agent workflow that performs three steps:

1. Grant temporary deployment access
2. Modify a network policy
3. Send a deployment notification

A later check finds the workflow unauthorized.

These are not three identical rollback operations.

The compensation plan needs per-effect semantics.

Calling rollback_workflow() tells the operator almost nothing about what actually happens.

Register Compensation Information Before You Need It

Recovery is easier when the original action records what would be required to compensate it.

This does not mean automatically executing compensation after every failure.

It means preserving enough information to make a later decision.

A tool contract for a consequential action should identify:

operation: grant_temporary_role

forward_effect:
  target_type: identity_assignment
  expected_postcondition: assignment_present

compensation:
  supported: true
  operation: revoke_specific_assignment
  requires:
    - assignment_id
    - current_assignment_state
    - current_authorization
  preserves:
    - unrelated_assignments
  does_not_restore:
    - actions_performed_while_access_existed

point_of_no_return:
  condition: first_successful_use_of_grant

residual_review:
  owner: security_service_owner

This is conceptual design data, not a vendor schema.

The important field may be does_not_restore.

That field forces the architecture to acknowledge the consequences a compensation cannot erase.

Compensating Actions Need Idempotency Too

Compensation can fail.

A revocation request can time out. A repair workflow can crash. An orchestrator can restart during cleanup. A message bus can redeliver the compensation command.

The same distributed-systems discipline applies in reverse.

AWS’s Saga guidance highlights idempotency as an important requirement for saga participants because retries and failures occur during both forward and recovery paths.

For an agent runtime, assign a stable compensation identity derived from the recovery decision, not a new identifier for every transport retry.

For example:

original_action_id = action-017
recovery_decision  = recovery-006
compensation_id    = compensation-recovery-006

The target or adapter should be able to distinguish:

first compensation attempt
same compensation retried
conflicting compensation using the same identity
new recovery decision

Do not assume the inverse command is naturally idempotent.

“Delete this rule” may be harmless when the exact rule no longer exists, or it may fail because its identifier was reused. “Refund this transaction” can be catastrophic if executed twice.

The target contract decides.

Compensation Needs Preconditions Against Current State

The compensation was designed after the original effect.

The world may change again before recovery executes.

Revalidate:

• target still exists
• target identity still matches
• observed harmful state still exists
• no newer approved operation supersedes the repair
• compensation has not already completed
• relevant dependencies remain healthy
• recovery authorization remains current
• current state still satisfies the compensation’s assumptions

A compensation should fail safely when those conditions do not hold.

Do not silently regenerate a new repair around current state while preserving an earlier approval.

That becomes another unreviewed action.

Sometimes Forward Recovery Is Better

Distributed-system recovery does not always need to travel backward.

AWS distinguishes forward recovery from compensating or backward recovery in its Saga guidance.

That distinction maps well to infrastructure operations.

Suppose an agent attempts to deploy release 12, partially succeeds, and later discovers that the previous release 11 is no longer compatible with a database migration that completed successfully.

The simplistic instruction is:

rollback to release 11

The safer operation may be:

complete a corrected release 12 deployment

or:

promote a validated release 13 that supports the new schema

The recovery decision should choose the safest accepted target state, not the direction with the word rollback in its name.

Forward recovery is especially relevant when:

• earlier versions no longer satisfy dependencies
• data migrations are not fully reversible
• concurrent valid work would be lost by rollback
• current security requirements prohibit the older configuration
• the original state is unavailable or unsupported
• compensation creates more risk than finishing the transition

This is why recovery belongs to the control plane, not the language model’s intuition about what “undo” means.

Containment Comes Before Compensation When Harm Can Continue

Sometimes the first recovery operation should not attempt correction.

It should stop additional damage.

If an agent granted an unauthorized privileged role, revoke or disable the relevant execution authority before spending time determining the perfect final configuration.

If an export is still transferring data, stop the transfer path if that can be done safely.

If an unsafe network policy continues admitting traffic, establish the approved containment boundary before reconstructing the long-term rule set.

The enterprise AI incident response runbook makes this distinction operationally important. Stopping the visible agent is not enough when delegated operations, credentials, or downstream jobs can continue.

Containment answers:

What must stop now?

Compensation answers:

What new action best addresses what already happened?

Those questions may happen in parallel, but they should not be confused.

Some Effects Need Remediation, Not Technical Rollback

Consider a customer-facing agent that sends a confidential document to an unauthorized external recipient.

A later API call deletes the message from the sender’s mailbox.

That does not retract the recipient’s copy.

Technical state in the originating system may look clean while the business consequence remains.

Recovery may require:

• access revocation
• recipient notification
• legal or privacy assessment
• data-loss investigation
• credential changes
• downstream deletion requests
• regulatory or contractual processes
• evidence preservation

Those are remediation activities.

An infrastructure control plane should be able to record that the technical compensation completed while business remediation remains open.

Do not collapse them into one green workflow state.

Give Compensation Its Own Evidence Contract

A recovery action should produce evidence just like the original action.

The record should link:

Preserve the original action record.

Do not rewrite history so the incident appears never to have occurred.

A useful compensation disposition might be:

original_action:
  action_id: action-017
  disposition: executed_but_violated

recovery:
  recovery_id: recovery-006
  strategy: compensation
  objective: restore_approved_access_boundary

compensation:
  compensation_id: compensation-recovery-006
  operation: revoke_specific_assignment
  status: verified

verification:
  assignment_present: false
  effective_access_test: denied

residual_effects:
  access_usage_during_exposure: under_investigation

closure:
  technical_compensation: complete
  incident_remediation: open

The compensation can be complete while the incident remains open.

That is a more accurate operational model.

Compensation Can Fail Too

The recovery workflow needs a plan for failure in the recovery workflow.

Microsoft’s Compensating Transaction pattern explicitly notes that compensation itself can fail and should record progress so it can resume. It also recommends idempotent compensation steps where repetition is possible.

Do not assume recovery code deserves more trust because it is labeled rollback.

It may encounter:

• unavailable APIs
• changed resources
• expired credentials
• contradictory evidence
• partial compensation
• another concurrent recovery
• rate limits
• dependent-system failures
• compensation steps that themselves pass a point of no return

Record each step.

Do not restart the entire recovery from the beginning unless its semantics make that safe.

Where compensation cannot complete automatically, transition to an explicit manual state with the information an operator needs.

Microsoft also recognizes manual intervention as necessary in some compensation failures. That should be designed into the runbook rather than discovered during the incident.

Compensation Order Should Follow Risk, Not Symmetry

The natural assumption is that if the forward order was:

A -> B -> C

recovery must always be:

C -> B -> A

Sometimes that is appropriate.

Sometimes it is not.

Microsoft’s guidance notes that compensation does not always need to happen in exact reverse order, and some steps can potentially execute in parallel.

For an agent system, choose order based on dependencies and exposure.

Suppose an erroneous workflow:

1. creates privileged access
2. opens network connectivity
3. starts a workload

The safest recovery order may be:

That order is selected because authority and exposure matter more than recreating a perfectly symmetrical workflow.

Document why.

Irreversible Actions Need Stronger Admission

If an action has no meaningful compensation, the architecture needs stronger preventive controls.

Use combinations of:

• stronger human approval
• multiple independent policy checks
• staged execution
• simulation or preview
• explicit point-of-no-return confirmation
• narrower target scope
• delayed commitment
• protected backups or recovery points
• dual control for particularly consequential operations
• evidence capture before commitment

The aim is not to make irreversible actions impossible.

Enterprises perform irreversible work constantly.

The objective is to stop treating them as if they carried the same recovery assumptions as changing an easily restored configuration value.

An agent that can send money, release data, delete the only copy of information, communicate externally, or make a legally significant commitment needs a different operating envelope from an agent that updates a reversible staging label.

Build a Recovery Strategy Per Tool

The reliable agent tool design pattern becomes more useful when each consequential tool declares its recovery characteristics.

For every write tool, document:

The tool contract should not claim reversible: true merely because someone can imagine an opposite API call.

Recovery characteristics need tests.

Test the Compensation Path Before Production

For one consequential agent action, create a test sequence that includes legitimate concurrent work.

For example:

1. establish baseline resource state
2. execute the bounded test action
3. independently verify the effect
4. introduce a second legitimate change
5. trigger the compensation
6. prove the compensation corrects only the original effect
7. verify the second change remains intact
8. repeat the compensation request using the same identity
9. interrupt the compensation response and reconcile it
10. verify the final state and retained evidence

Then test failure cases:

• compensation credential revoked
• target revision changed
• compensation request times out after commitment
• compensation runs twice
• one step of multi-step compensation fails
• evidence service becomes unavailable
• recovery action reaches an irreversible stage
• human review is required but unavailable

A recovery mechanism tested only against the exact untouched state produced by the forward operation has not exercised realistic concurrency.

Set a Compensation Budget

Autonomous recovery should not have unlimited authority.

Define a compensation budget that limits what the recovery workflow may do without escalation.

The budget might constrain:

number of resources
maximum privilege scope
maximum financial value
number of external recipients
data volume
number of recovery steps
time window
allowed target systems
permitted compensation tools

If fixing one bad firewall rule requires changing twenty unrelated network objects, the operation has crossed into a different recovery decision.

Stop and escalate.

A compensation budget gives the control plane a deterministic boundary when recovery begins expanding beyond the failure it was meant to address.

Ownership Must Follow the Residual Risk

The technical platform team can own the compensation engine.

It should not automatically own the decision that the remaining business impact is acceptable.

An agent can assist every one of these participants.

It should not collapse them into one self-approved recovery workflow.

Conclusion

The word rollback is too imprecise for consequential agent actions.

Some changes can be directly reversed.

Some need compensating transactions that account for current state and concurrent work.

Some should move forward into another valid configuration.

Some require containment and business remediation.

Some cannot be undone at all.

The control plane needs to know which kind of effect it is dealing with before it chooses a recovery action. It also needs to treat compensation as another privileged operation, with independent authority, current preconditions, idempotency, evidence, failure handling, and explicit residual impact.

A clean current configuration is not proof that the incident has been erased.

The control plane must not grade itself. Recovery must not rewrite history either.

Take one tool your agent can use today and answer one question precisely: if this action succeeds and later proves wrong, what exactly can your system restore, what must it compensate, and what can never be undone?

External References

Microsoft Learn: Compensating Transaction pattern

AWS Prescriptive Guidance: Saga patterns

AWS Prescriptive Guidance: Saga orchestration pattern

NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management

NIST SP 800-184: Guide for Cybersecurity Event Recovery

The post AI Agent Compensation: Why Rollback Is Not Undo appeared first on Digital Thought Disruption.