Your Agent Can Act. Can It Undo the Action?

2026-10-13 · Agentic Operations

Agentic operations need more than permission to execute. Leaders need rollback architecture that limits blast radius, preserves prior state, defines compensating actions, and proves recovery.

Topics: Agentic Operations, AI Governance, Revenue Operations, Operational Resilience, Enterprise AI

Execution without recovery is unfinished automation

An agent detects a renewal risk, approves an action within its delegated threshold, updates the CRM, changes a billing instruction, opens a delivery task, and sends a customer message. The workflow is fast, coordinated, and fully logged.

Then the underlying account identity proves wrong.

The enterprise now has a different problem. Can it restore the prior state? Can it reverse every downstream change? Can it identify the customer-facing consequences? Can it prove that recovery is complete?

Many agentic systems are designed around permission to act. Fewer are designed around the obligation to recover. A successful API response is treated as the end of execution even when the business action has propagated across finance, customer success, delivery, support, communications, and CRM.

An enterprise brain should not only know how to perform an action. It should know the action's blast radius, reversal method, compensation path, recovery authority, and verification standard before execution begins.

Rollback is not just restoring a database row

Technical rollback often means returning software or data to a previous state. Business rollback is more complicated.

A CRM stage can be restored. A customer email cannot be unsent. A credit memo may be canceled before posting but require a compensating transaction afterward. A service promise can be corrected, but the customer may already have planned around it. A support priority can be reduced, but the displaced work does not automatically recover its lost time.

The action therefore has at least four layers:

System state: records, fields, files, permissions, and workflow status.
Economic state: pricing, invoices, credits, commissions, commitments, and resource allocation.
Operating state: queues, owners, dependencies, schedules, and work already displaced.
Relationship state: messages, expectations, trust, and decisions made by customers or partners.

Restoring one layer while ignoring the others creates a technically clean system and an operationally damaged business.

Classify actions by recoverability

Before deciding how much autonomy an agent receives, classify the action it may take. A useful model has four categories.

Reversible. The prior state can be restored directly and completely within a defined window. Adding an internal review tag or changing a draft routing rule may fit here.

Reversible with side effects. The primary state can be restored, but downstream work must also be reconciled. Reassigning an account may trigger notifications, queue changes, and reporting updates.

Compensatable. The original action cannot be erased, but another action can offset its material effect. A posted financial adjustment, customer communication, or consumed service entitlement may require a correcting transaction or explicit remediation.

Irreversible. No reliable action can return the business to its prior condition. Disclosing confidential information, making a binding commitment, terminating access, or communicating a consequential decision can create effects that persist after every system is updated.

The category should determine the decision authority, evidence threshold, monitoring, and human involvement. An agent that may execute reversible internal changes should not inherit permission to make compensatable or irreversible customer decisions.

Create an action-recovery contract

Every material automated action should carry a recovery contract. It can include eleven elements.

Action and purpose. What exactly will change, and which outcome is it intended to support?
Pre-state snapshot. What records, values, ownership, dependencies, approvals, and customer context exist before execution?
Scope and blast radius. Which systems, accounts, users, transactions, workflows, and external parties can be affected?
Idempotency. How does the system prevent a retry from executing the same action twice?
Recoverability class. Is the action reversible, reversible with side effects, compensatable, or irreversible?
Rollback or compensation plan. Which operations return each affected layer to an acceptable state?
Recovery trigger. Which error, contradiction, customer response, policy breach, or outcome threshold starts recovery?
Recovery authority. Who may pause, reverse, compensate, or override the action?
Time boundary. How long does direct rollback remain possible before compensation or escalation is required?
Communication plan. Who must be told what happened, including customers and internal stakeholders?
Verification. What evidence proves that system, economic, operating, and relationship consequences have been addressed?

This contract extends the decision trail. The trail explains why an action occurred; the recovery contract explains how the organization remains accountable when the action must be unwound.

Use staged execution for consequential work

The safest rollback is often avoiding premature commitment. Consequential workflows should separate preparation from release.

Simulate. Show the proposed state changes, downstream systems, affected value, and likely side effects without executing.

Reserve. Confirm that required capacity, authority, evidence, and dependencies remain available. Create an idempotency key and capture the pre-state.

Commit. Execute the bounded action once, using the approved parameters.

Observe. Monitor the expected result and predefined recovery triggers during the action window.

Confirm or recover. Close the action only when the outcome is verified. Otherwise pause propagation and initiate rollback or compensation.

This pattern matters because one command can create a chain. An agent that changes a commercial field may trigger forecasting, billing, customer communication, compensation, and delivery workflows. The system should understand that critical path before treating the first API response as completion.

A hypothetical service-credit error

Consider a hypothetical strategic account with recurring service incidents. An agent assembles the evidence, calculates a service credit below its delegated threshold, posts the credit, updates the renewal forecast, assigns an executive recovery task, and prepares a customer message.

Minutes later, finance identifies that two incidents belonged to a different subsidiary. The credit was economically unjustified.

A weak design simply deletes the CRM note. The ledger still contains the posted credit. Forecast reporting still reflects the intervention. The executive task has displaced another account. The draft message may already have been released. The organization appears to have reversed the decision while its consequences remain active.

A recovery-aware design behaves differently. Before execution, it records the account hierarchy, evidence set, credit amount, downstream workflows, and posting rules. The financial action carries a transaction reference and compensation method. The customer message remains prepared but unreleased until the credit posts successfully. The executive task is provisional during the verification window.

When the identity conflict appears, propagation stops. Finance issues the authorized compensating transaction. Forecast state returns to the prior baseline with an audit marker. The displaced task is restored to its queue position. If the customer was contacted, the account owner receives a communication plan rather than a false claim that the action was undone.

The incident also becomes evidence. The system records that subsidiary identity must be verified before future credits for this account family.

Limit blast radius before increasing autonomy

Autonomy should expand through bounded experiments, not broad technical access. Useful boundaries include:

Maximum economic value per action and per period.
Approved account, segment, geography, and decision class.
Number of records or customers affected in one execution.
Systems the agent may change directly versus prepare for approval.
Customer-facing actions that require delayed release or human confirmation.
Time-limited permissions with automatic expiry.
Concurrency limits that prevent one faulty rule from scaling instantly.
Circuit breakers triggered by unusual volume, rejection, or outcome patterns.

A lower blast radius makes learning safer. It also makes recovery practical. An organization can investigate and compensate five bounded actions more reliably than five thousand simultaneous ones.

Where agents should help

An agent can construct the pre-state snapshot, enumerate downstream effects, verify idempotency, and compare the proposed action with its recovery contract. It can refuse execution when the compensation method is missing, authority has expired, or the blast radius exceeds policy.

After execution, it can monitor outcomes, detect recovery triggers, pause dependent workflows, and prepare the appropriate rollback or compensation package. It can also reconcile systems afterward and identify unresolved relationship consequences that cannot be fixed by an API.

But the executing agent should not be the sole judge of whether its own recovery succeeded. Material actions need independent verification, especially where money, customer treatment, access, legal obligations, or public communication are involved.

The NIST AI Risk Management Framework core makes this operational principle explicit. Its Manage function includes override, decommissioning, incident response, recovery, change management, and mechanisms to disengage systems whose outcomes conflict with intended use. For enterprise agents, recovery is part of normal control design, not an emergency feature added after failure.

Measure recovery readiness

Executives should know whether autonomous execution is recoverable in practice. Useful measures include:

Percentage of material action classes with a tested recovery contract.
Actions blocked because rollback or compensation was undefined.
Time from recovery trigger to propagation stop.
Time to restore system and operating state.
Economic value requiring compensation after failed actions.
Customer-facing incidents where relationship recovery remained open after technical closure.
Duplicate actions prevented by idempotency controls.
Rollback tests that failed because the pre-state or dependency map was incomplete.
Repeated recovery triggers that indicate a policy, data, or model defect.

A rollback plan that has never been tested is a document, not a control. Recovery drills should use realistic cross-system scenarios and verify business outcomes, not only API responses.

Responsible action includes a return path

Agentic operations promise shorter distance between signal, decision, and execution. That advantage becomes dangerous when the distance back is undefined.

Before an agent acts, the enterprise should know what state will change, how far the action can propagate, which consequences can be reversed, which require compensation, who may initiate recovery, and what evidence closes the incident.

Some actions should remain prepared rather than released. Some should stay inside strict boundaries. Some should never be automated.

The leadership test is simple: do not grant an agent more power to act than the organization has power to recover.

Related PATH AGI pages

Canonical article URL