When an AI Agent Goes Wrong: Stop, Trace, Repair

An AI agent can fail after it has already changed something. Imagine a fictional follow-up run that updates the next-contact date on eight customer records, then stops before sending the planned status messages. One request has since been resolved; another changed owners. A blind retry might update those records again or send messages based on old information. The first question is what the agent actually did, what is still queued, and who can halt the next action.

This guide begins after a bad or incomplete run. The companion agent approval matrix defines which actions should be allowed before a run starts.

Stop new work at the action boundary

Name one operator who can pause the agent’s schedule or queue and disable the specific write or send capability involved. They should also know how to stop in-flight work when the platform supports it. Confirm the pause at the destination system: no new messages, payments, or record updates should continue. If the agent shares a connection with other work, the systems owner must choose the narrowest safe shutdown instead of guessing that revoking one account has no wider effect.

Write down the triggers in advance: a wrong recipient or account, an unexpected high-impact action, duplicate changes, a lost approval record, or a run that keeps acting after its limit. NIST’s AI Risk Management Framework calls for mechanisms to disengage systems whose outcomes conflict with their intended use, and for incident response and recovery plans. The trigger and operator are local decisions; NIST does not supply a universal button.

Trace actions, not only the final answer

Preserve the run identifier, time, version of the agent and tools, source records used, proposed and approved actions, tool calls, results, and external record IDs. Then compare that trail with the destination systems. An agent’s final message may say “failed” while a customer record was already changed. A successful tool response may also be missing from the final summary. The action ledger needs to distinguish planned, attempted, confirmed, and uncertain effects. If one agent handed work to another, follow both runs through to the final system change.

OpenAI’s Agents SDK tracing documentation describes traces for runs, model turns, tool calls, guardrails, and handoffs. That is one way to inspect a run, not a substitute for the destination system’s own audit history. Limit access and retention for traces that contain customer data or tool arguments; preserve what the incident team needs without making a second uncontrolled copy of sensitive records.

Repair the actual side effects

For each confirmed action, decide whether to leave it, correct it, reverse it, or notify an affected person. In the fictional follow-up run, compare all eight updated records with their prior values and the current source request. Mark which updates remain correct, which need a person to restore, and which messages were never sent. Do not rerun the entire job to discover this. Keep one repair ledger with the original record ID, the change made, the repair owner, the outcome, and who checked it.

Some effects cannot be silently reversed. A customer may already have read a wrong message; a refund or account change may have downstream consequences. The business owner decides who needs a correction and when. NIST’s framework explicitly includes communication with affected parties and documented recovery from incidents; the organization still has to apply its own customer, legal, and operational duties to the specific event.

Treat retries as new actions until proved otherwise

Microsoft’s Power Automate guidance describes retries, error paths, termination, and logging for failed workflows. Those features help with temporary faults, but an agent that can send or change records needs an additional check before a retry: did the previous attempt already complete at the destination? Use a stable action ID or a destination-side duplicate check where possible. Resume from the last confirmed step rather than replaying every step.

A retry rule must also cover changed facts. If a draft was approved yesterday and the recipient, amount, or source record changed today, the old approval should not authorize the new action. Return it to a reviewer. If the platform cannot show which step completed or cannot prevent duplicate effects, keep the action manual while the workflow is repaired.

A one-page recovery runbook

• Stop: Who can pause the schedule, queue, and affected tool? How will they verify that new actions stopped?
• Find: Which run IDs, logs, approval records, and destination records show what happened?
• Classify: Which actions were planned, attempted, confirmed, or uncertain? Which customers or staff may be affected?
• Repair: Who owns each correction, reversal, or notification, and who checks the result?
• Restart: Which test must pass, who signs off, what smaller scope is allowed, and what trigger pauses it again?

Rehearse the runbook with one ordinary failure and one partial-write case before broad rollout. Time the pause, count records that require manual reconciliation, record the repair minutes, and ask an operator outside the build team to find the evidence. Put that effort into the scale decision. A recovery exercise that cannot identify the affected records is a reason to narrow the agent’s authority, even when its normal outputs look strong.

The restart decision

Restart only after the business owner confirms the repair ledger, the systems owner confirms the cause and the new guard, and a limited replay passes on comparable cases. Record the remaining uncertainty. If the team cannot verify that new writes have stopped, cannot account for external effects, or cannot prevent the same failure from repeating, continue manually. The value of an agent is completed, accepted work; a run that cannot be safely stopped and repaired is not ready for more authority.

Source note: NIST provides the risk-management expectations for disengagement, response, recovery, and communication. OpenAI documents one tracing implementation, and Microsoft documents workflow error handling. The customer scenario and runbook are editorial examples, not a report of a real incident or a claim that any provider handles every failure automatically. Sources checked October 3, 2026.