Recovery must be designed before execution
The safest AI agent is not the one that never makes a mistake.
It is the one operating inside a system designed to detect, contain and recover from mistakes.
Most AI-product conversations focus on capability.
What can the agent read?
What can it generate?
Which systems can it access?
Which actions can it perform?
But as agents move from recommending actions to executing them, another question becomes essential: what happens when the action is wrong?
An undo button may appear to be the answer.
In real business systems, recovery is rarely that simple.
Not every action can be undone
Some actions are easily reversible.
A task can be moved back to its previous status. A draft can be restored. A temporary label can be removed.
Other actions create consequences outside the product.
An email may already have reached a customer.
A refund may have entered the payment network.
A file may have been shared externally.
A calendar invitation may have notified twenty people.
A database update may have triggered several connected workflows.
The interface can reverse its local state, but it cannot always reverse what happened in the real world.
That means product teams need to distinguish between four types of action.
Reversible actions
These actions can return reliably to their previous state.
Examples include:
Changing an internal status
Updating a draft
Reordering an unpublished list
Applying a temporary tag
For these actions, a clear undo control may be enough.
The system should still record what changed, who initiated it and whether the reversal succeeded.
Compensatable actions
These actions cannot be erased, but another action can reduce or correct their effect.
A payment cannot always be “unpaid,” but it may be refunded.
A sent email cannot be removed from the recipient’s inbox, but a correction can be sent.
An invoice cannot always disappear from an accounting trail, but it may be voided or credited.
This is compensation, not reversal.
The product should explain that difference clearly.
Approval-gated actions
Some actions are too risky to execute first and recover later.
They should require human review before execution.
Examples may include:
Deleting important records
Publishing public communication
Changing account permissions
Issuing large refunds
Sending legal or financial documents
Modifying production infrastructure
The stronger the external consequence, the more valuable approval becomes.
Irreversible actions
Some actions cannot be meaningfully reversed or compensated.
The only responsible design may be to prevent the agent from performing them autonomously.
This is where product architecture must place a hard boundary around the agent’s authority.
Not every capability should become an automated action.
Recovery is a workflow
When an agent makes a mistake, the product needs more than an error message.
A complete recovery workflow should answer:
What happened?
Which systems were affected?
Which actions completed?
Which actions failed?
Can the process be stopped?
Can completed actions be reversed?
Is compensation required?
Who must be notified?
Does a human need to take over?
How does the workflow resume safely?
Without these answers, users are left searching through several systems to reconstruct what the agent did.
That destroys trust faster than the original mistake.
Use checkpoints before high-risk execution
A long automated workflow should not be treated as one indivisible action.
It should contain checkpoints.
Before moving into a high-risk stage, the system can save the current state, validate required data and confirm whether additional approval is needed.
For example, an agent preparing a customer refund might:
Collect the customer and transaction data
Check the refund policy
Calculate the eligible amount
Prepare the proposed action
Request approval
Execute the refund
Confirm the external result
Record the evidence
If execution fails at the execution step, the workflow should not pretend that the process is complete.
It should stop, explain the failure and identify the correct recovery path.
Design for partial completion
One of the hardest automation problems occurs when some steps succeed and others fail.
Imagine an onboarding agent that:
Creates a customer account
Adds the customer to the CRM
Creates a project
Sends a welcome email
Issues an internal notification
What happens if the account and CRM record are created, but the project creation fails?
Repeating the entire workflow may create duplicate records and send the email twice.
The system needs to know which steps completed, which can safely retry and which require a different recovery action.
This is why execution history must be structured—not stored only as a conversation transcript.
Trust depends on recoverability
Users do not expect complex systems to be perfect.
They do expect the product to remain understandable and controllable when something goes wrong.
An agent becomes more trustworthy when users can:
Preview high-risk actions
Approve consequential decisions
See execution progress
Stop an active workflow
Understand partial completion
Reverse supported changes
Launch a compensation process
Hand control to a person
AI-agent UX should not end at execution.
The recovery experience is part of the product.
Before giving an agent permission to act, design what happens when that action needs to be stopped, corrected or compensated.
Because an undo button is an interface element. Recoverability is architecture.