AI Agent Rollbacks: Plan the Undo Before You Grant Write Access
An agent can complete the first step and fail on the second. A rollback plan tells it how to recover without erasing newer work or leaving your store half-changed.
You approve an AI employee to launch a weekend promotion. It activates the discount in Shopify, turns on the ad campaign, and then fails while scheduling the customer email. The agent has not finished the job, but it has already changed two live systems.
A retry may finish the email. It may also repeat a write, use data that changed after approval, or leave the promotion live longer than intended. Before you give an agent write access, define how each completed action will be reversed or compensated if a later step fails.
Approval controls the start; recovery controls the failure
Human approval answers whether the agent may begin a proposed job. It does not guarantee that every connected service will accept its part of the work. APIs time out, credentials expire, records change, and business rules reject requests. A workflow that writes to several systems can stop after any successful step.
Treat recovery as part of the original job definition. For each write, record the expected result, the evidence needed to verify it, and the action that creates an acceptable business state if the job stops. The recovery action may restore a previous value, cancel scheduled work, pause a campaign, or create a task for a person.
Microsoft describes this approach as a compensating transaction. The workflow records each completed step and the information required to undo it. If the operation fails, it works through the completed steps and applies the relevant recovery actions.
Classify actions as reversible, compensable, or irreversible
A reversible action can return to its prior state without harming work that happened afterward. If an agent changes a product tag and no one has edited the product since, it can restore the saved tag set. The agent should compare the current record with the version it changed before writing the old value back.
A compensable action cannot be erased, but another action can repair the business outcome. A customer email cannot be unsent. The recovery may suppress the remaining sends, alert support, and prepare a correction for approval. A refunded payment may require a new charge or an accounts-receivable task rather than an attempt to pretend the refund never happened.
An irreversible action crosses a point where automated recovery carries too much risk. Fulfillment may have released an order, a carrier may have collected a parcel, or a customer may have acted on a message. Stop the workflow and give a person the full record instead of adding more writes.
The Saga pattern uses a similar boundary between steps that can be compensated and a point of no return. For an ecommerce operator, the useful question is practical: which actions can the agent repair on its own, and which require human judgment?
Save enough of the before-state to recover safely
A rollback needs more than an old value. Save the record identifier, the fields the agent read, the last update time or version, the requested change, and the result returned by the destination. Keep the approval and job identifier beside that snapshot.
Check for newer work before restoring anything. If a merchandiser changes the product price after the agent's promotion update, writing the old snapshot back would erase that change. Microsoft warns that a compensating transaction must account for concurrent work rather than restoring a whole system to an earlier state.
Restore only the fields the agent changed and only when their current values still match the agent's write. If they do not match, stop and present the difference to the owner. This turns a dangerous automatic rollback into a bounded review.
A DTC promotion launch that fails after two writes
Consider a hypothetical skincare brand preparing a 20% weekend promotion. The approved job has three actions: activate a Shopify discount at 9:00 a.m., enable a Meta campaign that points to the promotion, and schedule a customer email for 9:05 a.m.
Before execution, the agent saves the discount state, the campaign state, the schedule, and the identifiers for all three records. It also records the recovery plan. The discount can be deactivated. The campaign can be paused. A scheduled email can be canceled before send time, but a sent email requires a person to decide whether customers need a correction.
Shopify and Meta accept their updates. The email platform rejects the schedule because the selected audience is no longer available. The agent verifies that neither live record has changed since its own write, pauses the campaign, deactivates the discount, and marks the email step failed. It sends the operator one review packet with the error, completed actions, recovery results, and current state.
Now change one fact: an order used the discount before recovery began. The agent should not overwrite or cancel that order. It can close the discount and pause the campaign, then route the customer and order impact to a person. Recovery aims for a correct business state, which may differ from the exact state before the job started.
Use explicit states so a partial job cannot look complete
Give the job a small set of states that the team can read: pending approval, running, recovery required, recovering, recovered, completed, and needs human review. Store each action result under the job instead of reducing the run to one success or failure flag.
A recovery action can fail too. Record its progress and make it safe to resume. AWS and Microsoft both note that compensating workflows need their own failure handling because they may cross the same unreliable services as the original job. If recovery stops after pausing the campaign but before closing the discount, the next run should continue from the open step.
Set a recovery deadline and an owner. A failed promotion launch needs attention before traffic or scheduled messages create more customer impact. The agent can attempt the approved recovery path, but it should escalate when the deadline passes, the record changed, or an irreversible event occurred.
Build a rollback plan before the first live write
Start with one multi-tool workflow. Document the successful path and stop the test after each write so you can inspect the recovery behavior.
Where ShopDucky fits
ShopDucky AI employees keep tool actions, approvals, and run history tied to the job they are executing. Teams can define recovery steps for connected workflows and route consequential exceptions to a person with the evidence attached. Book a demo to see how approval-gated ecommerce work runs across your existing tools.
AI agent rollbacks, answered
What is an AI agent rollback?+
An AI agent rollback is a planned recovery process for work the agent already completed before a later step failed. The process may reverse a change, apply a compensating action, or route the case to a person when the original state cannot be restored safely.
Can every ecommerce action be undone?+
No. Some writes can be reversed, while customer messages, captured payments, fulfilled orders, and other real-world events may require a compensating action. Classify that difference before the agent runs.
Do human approvals remove the need for rollbacks?+
No. An approved multi-step job can still fail after its first successful write. Approval controls whether work may begin; a rollback plan controls what happens when only part of the approved work finishes.
What should an agent save before it changes a record?+
Save the record identifier, relevant field values, version or update time, the requested change, and any business event tied to the action. The recovery step needs enough evidence to avoid overwriting newer work.
