When an agent takes an incorrect action, contain further effects, establish what actually changed and assign an authorized owner to the recovery. Correct the affected records through supported procedures, deal separately with messages or commitments that have already reached someone, and verify the resulting work before allowing the agent to resume.
Stopping the agent does not undo its actions. Restoring its saved state does not necessarily restore the systems it changed either. Recovery needs an account of the real effects, including those still uncertain, rather than another confident completion message.
Stop further actions and give recovery an owner
Suppose Sam Taylor coordinates printer-maintenance visits for an office-equipment service company. Sam asks an approved agent to reschedule Maple Office's visit. The agent instead changes Cedar Office's booking and sends Cedar a confirmation. Its attempt to create an internal follow-up task then times out.
Claire Bennett, the service owner, needs to protect the next customer while repairing this one. The authorized operator should use the supported controls to hold the affected automated actions and check work already in progress. Closing Sam's chat may leave a scheduled run, queued message or connected process active. Establish what the stop control actually covers.
Use the company's existing urgent response route if the effects may involve security, information exposure or another serious consequence. The incident and near-miss guide explains how to obtain an accepting response owner without requiring the reporter to diagnose the cause first.
Record who coordinates recovery, who can change the booking system and who handles the customer. These responsibilities can overlap, but they must be accepted. Sam should not have to improvise a repair by granting the agent broader access or asking it to keep trying until something looks right.
Keep essential service moving through the approved continuity route. Other coordinators may be able to handle visits manually while automated rescheduling remains held. A pause can limit further damage without settling what has already happened.
Reconstruct the effects before choosing a repair
Compare the original request with current records in the connected systems. For Sam's case, inspect both customers' bookings, the outbound confirmation and the follow-up task history. Keep the relevant request, action references, times and observations connected in the restricted incident record. Preserve the original history under existing access and retention rules.
A useful reconciliation distinguishes:
- Confirmed changes. Cedar's booking now differs from its previous recorded arrangement, and the confirmation was sent.
- Required work left undone. Maple's requested reschedule has not been established as complete.
- Uncertain effects. The follow-up request timed out; its task may or may not exist.
- Later legitimate work. A coordinator may have changed either booking after the agent acted. Check that before replacing a value.
Do not convert a missing response into a confirmed failure. Ask the authorized operator to look for the task in its owning system before creating another one. If the evidence cannot settle the outcome, retain the uncertainty and assign its investigation. Repeating the whole request could change another booking or send another confirmation.
In an October 2026 Reddit discussion, a user described previously having to inspect several services' dashboards to work out what an agent had done. They said that a step record made recovery easier to follow. The account is unverified and does not establish a general cleanup time or a safe retry method. Its useful detail is the search for evidence outside the final message.
A saved checkpoint needs the same scrutiny. An August 2026 security preprint by Wu and colleagues demonstrated how restored agent state can forget an effect that persists in another service. Its selected frameworks, benchmark tasks and controlled attacks do not establish your workflow's failure rate. They identify a recovery condition worth testing.
For Claire, the question is concrete: after any restore, what does the booking system show, which messages have left, and what work still exists? The agent's memory of the run cannot settle those questions alone.
Choose a repair for each effect
Some changes can be reversed through the application. Others need a new corrective action, and some consequences cannot be removed. Have the system owner establish the available procedure and its limits before treating “rollback” as a complete plan.
Microsoft's compensating-transaction guidance explains why distributed workflows can need business-specific corrections rather than a return to the original state. It also warns that a correction can fail and must account for other work performed meanwhile. This is architecture guidance, not proof that a particular booking system supports a safe undo.
One mistaken reschedule leaves three recovery obligations
The agent changes Cedar’s booking instead of Maple’s, sends a confirmation and times out while creating a follow-up task.
Establish a valid current arrangement
Inspect the booking history and current availability. Use an authorized correction that preserves later legitimate work.
Correct what Cedar has been told
The booking repair does not retract the message. Assign the approved customer follow-up and confirm its completion.
Check before creating another
The timed-out request has an unknown result. Inspect the task system, then resume or repair through the supported route.
The branches are separate obligations, not a prescribed order. Restoring Cedar's previous time could itself be wrong if that slot has since been allocated elsewhere or the customer has accepted another arrangement. Claire needs a valid current booking, agreed through the company's normal authority and customer process, rather than an old value copied back without checking.
A sent confirmation is another boundary. Changing the booking does not make the customer forget the message. The service team must establish the correction needed and communicate the confirmed arrangement. A recall feature, if available, is not evidence that every recipient lost access to the earlier message.
Use the narrowest supported repair that addresses the affected work while preserving legitimate changes. A whole-system restore may be necessary in some incidents, but it is a decision for the responsible specialists, with its wider consequences assessed. It should not be the automatic response to one incorrect appointment.
| Proposed recovery decision | What must be established first? |
|---|---|
Restore an earlier booking value | The earlier arrangement is still valid, the relevant slot is available and later authorized changes are preserved. |
Make a new corrective booking | The service owner has approved the current arrangement and any required customer agreement is obtained. |
Resume an interrupted task | Its previous effect is known, its inputs remain applicable and the supported continuation will avoid an unintended duplicate. |
Leave part of the repair manual | A named person accepts the work, has the required access and can verify its completion. |
Do not assume that every successful earlier step should be undone. Maple's legitimate request still needs an answer. Once the incorrect Cedar effects are understood and controlled, Claire may choose to complete Maple's request through the approved manual route rather than replaying the agent's original run.
Communicate what is corrected and what remains open
A recovery update should distinguish the confirmed repair from the unfinished work. Use the audience and approval route appropriate to the incident. Customers need the usable service information and any required action; authorized investigators need the protected supporting detail.
For Sam's team, a recovery record should name:
- The corrected result and evidence. Which booking is now valid, who authorized it and where it can be checked.
- The customer follow-up. Who will confirm the arrangement with Cedar, and what remains unresolved until that happens.
- The incomplete request. Who will finish Maple's reschedule without repeating the incorrect run.
- The uncertain task. Who is checking whether the internal follow-up already exists, with a next update point.
That update does not claim that Cedar has been contacted or that Maple's work is complete. Record the later evidence when each obligation is fulfilled. Avoid closing the incident because the most visible field now looks right.
If the investigation reveals information exposure or another reportable consequence, use the established specialist notification process. A booking correction, an incident notification and a public explanation serve different purposes. The reporting guide's communication responsibilities help keep them assigned without inventing a universal notification deadline.
Verify the recovery before restarting the agent
Check the repaired records and remaining work independently of the agent's claim that it fixed them. Confirm that legitimate neighboring bookings remain intact and that the intended customer communications match the actual arrangement. Where recovery used a backup, have the responsible operator verify its suitability and integrity before relying on it.
The April 2025 NIST incident-response guidance calls for checking restoration assets, verifying the adequacy of restoration and declaring recovery complete against criteria. It concerns cybersecurity incidents and can be used voluntarily by nongovernmental organizations. It does not make every incorrect booking a cybersecurity incident or prescribe one restart checklist for all agents.
Claire also needs a decision about the agent's future scope. Correcting Cedar's booking does not show that the wrong-customer selection has been repaired. Investigate the relevant conditions, change the controls where needed and test the revised workflow in a safe setting. If the cause remains unresolved, keep the affected action restricted or use the manual process.
Rehearse recovery with the authorized operator before expanding that scope:
- Create a safe practice case. Use permitted test bookings and a controlled message destination, with an agreed expected result.
- Exercise the stop and reconciliation. Demonstrate which ongoing actions are held and how the operator finds completed, incomplete and uncertain effects.
- Perform and check the repair. Preserve a later legitimate booking change, resolve the uncertain task and demonstrate the customer-correction handoff.
- Authorize a bounded restart. Record the evidence, remaining restrictions, monitoring owner and condition that would hold the action again.
Include both a mistaken action and an interrupted recovery. A repair procedure that loses its place after a failure can create another incident. The agent evaluation guide explains how to keep recovery cases and their acceptance conditions visible alongside ordinary task completion.
Renew the applicable approval boundaries when the proposed correction or its circumstances differ from the original authorization. Successful cleanup does not authorize broader access or every future action.
For the next review of your delegated workflows, choose one action that can change a business record and contact someone outside the company. Ask the owner to demonstrate how both effects would be discovered, corrected and checked. Record any effect that cannot yet be recovered; that is a limit on the workflow's supported scope.
Questions about recovering incorrect agent actions
Can rolling back an agent undo everything it did?
No. A rollback restores only the state covered by that mechanism. Connected systems, sent messages and later legitimate work may remain outside it. Ask the authorized operator to establish what persists and choose a supported repair for each effect. The appointment recovery branches show why a corrected record and a corrected customer understanding are separate obligations.
Should we retry when an agent action times out?
First establish whether the action already happened. A timeout means the caller did not receive a timely result; it does not prove the destination stayed unchanged. Inspect the authoritative record and use the system's supported duplicate protection or continuation procedure. Keep an unresolved result assigned for investigation instead of blindly repeating the whole workflow.
Can the same agent repair its own mistake?
An agent may help with a defined, authorized repair if the required controls and checks are available. It should not be the sole source of evidence about the damage or its correction. Keep an accountable person in charge, limit the permitted changes and check the result independently. Where recovery is unsupported or uncertain, use an authorized manual or specialist route.
When can the agent resume normal work?
Resume only the scope that the responsible owner has evidence to authorize. Verify the correction, reconcile remaining effects and test the revised behavior under current permissions and conditions. Restoring a booking alone does not fix an agent's wrong-customer selection. Use the recovery rehearsal to establish restrictions and the next stop condition before restarting.
What should we tell an affected customer?
Give the customer the confirmed service arrangement, the correction to earlier information and any useful next action through the company's approved communication route. Keep unverified causes and unnecessary internal detail out of the update. If the arrangement is still unresolved, identify the responsible contact and next update rather than promise a result. Relevant specialists should decide any additional incident notification requirements.
