Your AI agent made a mistake in a live system. What should you do in the first hour, day and week?
A response plan for when an AI agent gets it wrong in your ERP, CRM or inbox: pause it, find every affected record, repair, tell people, fix the cause.
The short answer
When an AI agent makes a mistake in a live system, pause it first and keep its logs. In the first day, find every record it touched, repair them and tell the people affected. In the first week, name the cause, add the failing case to its tests and restart it in draft mode before it acts alone again.
Key takeaways
- An AI agent incident is any action the agent took, or failed to take, that a person would have to undo, explain or apologise for, whether or not anything technical broke.
- The first hour is about containment: pause the agent with a switch that stops scheduled runs, keep every log and draft, and name one person who runs the incident.
- In Gartner's survey of 297 cybersecurity leaders in the second quarter of 2026, 54% said their organisation had no defined approach to limiting AI agent access, or relied on predefined human access.
- Scope the damage from the audit log, not from memory: list every record the agent changed in the window, then check a sample of the work it did before the first report.
- Repair with traceable corrections, such as reversing entries in the ERP, rather than silent edits, and tell affected customers and suppliers in plain words.
- An agent goes back to acting alone only after the failing case is in its regression set, the cause is fixed, and a period in draft mode comes back clean.
In this article
What counts as an AI agent incident?
An AI agent incident is any action the agent took, or failed to take, that someone has to undo, explain or apologise for. Nothing has to crash. An invoice posted to the wrong supplier, a refund promised outside policy or a lead routed to a rep who left last year all count.
That definition is wider than the one most IT teams use, and it should be. Agents fail quietly. The system stays up, the dashboard stays green and the agent keeps working, while the wrong value spreads through every record that depends on it.
Agents are spreading faster than the routines for handling their errors. In KPMG's survey of 314 US leaders at firms with $1 billion or more in revenue (24 July–25 August 2026), 62% were building, deploying or developing AI agents, and 70% used AI monitoring dashboards.1 The share building controls into their agents alongside monitoring and evaluation fell to 30%, from 43% two quarters earlier.1
Our view: a dashboard tells you something went wrong, not who pauses the agent or what to tell the customer. A written response plan does that, and it is cheaper to write before the first incident.
AI agents in 2026
Agents are live; the controls around them lag
Why agent mistakes spread further than human ones
An agent repeats its mistake on every case that looks the same, at machine speed, until someone stops it. A clerk who misreads one supplier's bank details makes one bad payment. An agent with a wrong rule about that supplier makes the same error on every invoice in the queue.
Three features of agents make the damage harder to see. They act across several systems, so one error can touch the ERP, the CRM and an outbound email in a single run. They work in the background, often between check-ins. And they write fluent explanations, so a wrong action can come with a reasonable-sounding note.
Access decides how far the damage can go. In Gartner's survey of 297 cybersecurity leaders in the second quarter of 2026 (geography not stated), 54% said their organisation had no defined approach to limiting AI agent access, or relied on predefined human access.2 An agent that borrows a person's permissions can make every mistake that person could make.
The OWASP GenAI Security Project describes the same risk under the name excessive agency: an agent given more functions, permissions or autonomy than its task needs.4 Our guide to least-privilege access in an ERP or CRM covers prevention. Here we cover what happens after prevention fails.
The first hour: contain, keep the evidence, name an owner
In the first hour, stop the agent from doing more harm and keep everything you need to work out what happened. Fixing the records comes later. Teams that start repairing before they pause usually end up repairing twice.
Pause the agent properly
Use a pause switch that stops scheduled runs, ends open sessions and holds new work in a queue a person can see. Switching off a chat window is not a pause if a background job keeps running. If the agent has no real switch, revoke its credentials, which is one reason each agent should have its own account rather than a person's login.
Route incoming work to people while the agent is paused, and tell the team the queue is now manual.
Keep the evidence
Export the audit log for the incident window before any retention rule rotates it. Keep the agent's drafts, the prompt and model version it was running, the tool calls with their inputs, and the source documents it read. If the agent reads email or web pages, keep those too: an injected instruction may be the cause.
Name one incident lead
One person runs the incident, usually the agent's business owner, with IT supporting. That person decides when the agent restarts, approves messages to customers and closes the incident. Write down the time of each decision; the review a week later depends on it.
An AI agent incident, from first report to restart
Pause the agent, route work to people, export the logs and drafts, name the incident lead.
List every record the agent touched in the window, sort by harm, repair the urgent ones, tell the people affected.
Find the cause, fix it, add the failing case to the regression set, restart in draft mode.
Watch the agent's drafts and samples closely, then return it to acting alone when they stay clean.
How do you decide how serious the incident is?
Rate an incident on two questions: can the action be reversed, and did it reach anyone outside the company? Those two answers decide who gets called, how fast you move and who has to be told.
An internal, reversible error, such as a mislabelled ticket, is a routine fix for the owner. An internal error that cannot be reversed, such as a deleted record with no backup, needs IT and the system owner. An external, reversible error, such as a wrong quote that was sent but not accepted, needs a message to the customer. An external error that cannot be reversed, such as a payment to the wrong account or personal data sent to the wrong person, needs senior sign-off, finance or legal, and possibly a regulator.
Agree the levels before the first incident and write them into the agent's runbook, so nobody argues about severity mid-incident.
Rate an agent incident by reach and reversibility
Reached people outside the company →
Harder to reverse →
The first day: find every record the agent touched
On the first day, build the full list of what the agent did in the incident window, then sort it by harm. The first report is rarely the only case. It is the one someone happened to notice.
Start from the audit log
Pull every action the agent took since the last time you know it was working correctly. If it has been running a new model, prompt or tool since a recent change, that change date is a good start of the window. The log should give you, for each action, the record, the tool, the inputs and the outcome. Our field list for an agent's audit log is the minimum we would want at this moment.
If the log cannot answer which records the agent changed, that is a finding in itself. Fall back to the system's own change history, filtered by the agent's account. This is the second reason an agent needs its own login: without one, its changes are mixed with a person's.
Check beyond the reported case
Search for records that look like the one that failed: the same supplier, the same type of request, the same field. Then take a random sample of everything else the agent did in the window and check it as if a new employee had done the work. Errors cluster, and the sample tells you whether this one is isolated.
Sort by harm, then repair
Repair in the order of the severity grid: money and personal data first, customer-facing records next, internal labels last. Some fixes will wait until the cause is known; the urgent ones should not.
How should you repair the records?
Repair with corrections that leave a trail, not with silent edits. Finance, auditors and the customer may all need to see what was wrong, what changed and who approved the change.
In an ERP, that usually means reversing entries or credit notes rather than editing a posted document. In a CRM, it means restoring the old value and adding a note that names the incident. For outbound messages, it means a correction sent from a person, not from the agent that made the mistake.
Do not let the paused agent run the repair. It may still carry the fault that caused the incident. A script or a person should make the corrections, and someone other than that person should check a sample of them.
Our view: keep the incident's record list as one shared sheet with a status for each row: found, repaired, checked. It turns a stressful week into a list that shrinks, and it becomes the evidence pack for the review.
Who has to be told, and what should you say?
Tell everyone the error reached, in plain words, as soon as you know what happened to them. Customers and suppliers forgive a mistake that is explained and corrected more readily than one they find themselves.
A good message says what went wrong for that person, what you have already corrected, whether they need to do anything, and who to contact. It does not need to explain how the agent works. If an AI agent sent the wrong message, say that an automated system made the error and that a person is now handling their case.
Some incidents carry legal duties. If the agent exposed personal data, the GDPR requires the controller to notify the supervisory authority within a set deadline. The exception is a breach unlikely to put people at risk, and Article 33 sets out what the notice must contain.5 Under the EU AI Act, deployers of high-risk AI systems must monitor their operation and inform the provider when they find a serious incident.6 Bring in your data protection lead early; the deadline starts when you become aware of the breach, not when the review finishes.
Inside the company, send a short daily update to the people who depend on the agent: what is paused, repaired and still open.
The first week: find the cause, not only the symptom
In the first week, work out why the agent did what it did, and fix that. "The model made an error" is a description, not a cause. Something in the instructions, the data, the tools or the change history made the error possible.
Most agent incidents fall into a short list of causes. Name the one that applies, because each points to a different fix.
Common causes of an agent incident, and where the fix goes
- Instructions
A rule was missing, vague or in conflict with another; rewrite it and add a test case.
- Data
A source record was wrong or stale, such as an old price list or a supplier's former bank details; fix it at the source.
- Tools and access
The agent could take an action its job did not need; remove the permission or put it behind an approval.
- Change
A new model, prompt, tool or field name changed its behaviour; roll back and run the regression set.
- Outside content
An email, document or page carried an instruction the agent followed; treat it as prompt injection.
Change is the cause to check first, because it is the easiest to prove. Compare the incident window with the agent's change log: model versions, prompt edits, new tools and changes in the systems it reads. Our guide to regression-testing an agent before a change covers how to stop the next one. If outside content was involved, our prompt-injection defence plan applies.
Why a blameless review makes the next incident smaller
Hold a short written review within the week, focused on what made the error possible rather than on who approved the agent. People report incidents early only when reporting does not get them into trouble.
The review answers five questions: what happened, how it was noticed, how long the agent ran with the fault, what the fix is, and what would have caught it sooner. The last question matters most. If the answer is "a person noticed by chance", the agent's supervision has a gap.
Each review should leave behind at least one new test case and one change to supervision or access. If it leaves behind only an apology, expect the same incident again. Our guide to supervising agents that work in the background lists the digests, samples and thresholds that turn chance into a routine check.
Our view: share a one-page summary of each review with the agent's users. Seeing that an incident was found, fixed and tested builds more trust in the agent than a clean record nobody can verify.
When is it safe to let the agent act alone again?
Let the agent act alone again only when the cause is fixed, the failing case passes in its regression set and a period in draft mode comes back clean. Restarting straight into full autonomy repeats the conditions of the incident.
Restart in stages. First, the agent drafts and a person approves every action. Then it acts alone on routine cases while the case type that failed stays with a person. Finally, it returns to its full scope, with a larger random sample checked for the first weeks.
Write the exit rule for each stage before you start it, such as a set number of approved drafts with no corrections. Without a written rule, the agent drifts back to full autonomy because the queue is long, not because it is ready.
Some incidents should end with a smaller agent. If the failing case type needs judgement the agent does not have, move it permanently to a person through the exception queue. Our guide to designing the exception queue covers how to route those cases.
What should be written down before the first incident?
Write a one-page runbook for each agent before it goes live. During an incident, nobody has time to work out who owns the pause switch or where the logs are kept.
The runbook names the agent's business owner and IT contact, the pause switch and where the audit log lives. It holds the severity grid, who to call at each level, message templates and the restart stages. It also lists every system the agent can write to, because that list is the scope of any incident.
Test the runbook once before launch with a pretend incident: pause the agent, pull a day of its log, find the records it changed and restart it in draft mode. A drill that takes an afternoon will show the gaps that would otherwise surface on the worst day.
The firms that scale AI tend to be the ones that build this kind of operating routine. In Gartner's survey of 1,303 leaders at organisations with $50M or more in revenue (January–April 2026, geography not stated), 22% had scaled AI across multiple business units or adopted an AI-first approach.7 McKinsey's State of AI 2026 survey covered 1,719 participants in 97 countries (4 May–8 June 2026).3 In it, 40% of respondents at organisations with revenue above $1 billion were scaling AI agents, against 22% at $1 billion or less.3 More agents at scale means more incidents to plan for.
The plan on one page
An agent incident is handled in the same order every time: contain, scope, repair, tell, fix the cause, restart in stages. The order matters more than speed at any single step.
In the first hour, pause the agent with a real switch, route its work to people, keep the logs and name one lead. On the first day, list every record it touched from the audit log, sort by harm, repair with traceable corrections and tell the people affected. In the first week, name the cause, add the failing case to the tests, hold a blameless review and restart in draft mode.
A disclosure: Sigzen AI builds agents for clients, and we design them with an audit log, approval rules and a pause switch, so weigh our view with that in mind. Our AI automation page sets out how we scope that work.
Sources
- KPMG, AI Quarterly Pulse Q3 2026: 314 US leaders at $1bn+ firms, 24 Jul–25 Aug 2026 (Sep 2026)
- Gartner, survey of 297 cybersecurity leaders, Q2 2026; geography not stated (Sep 2026)
- McKinsey, The State of AI 2026: organisations with more than $1 billion in revenue vs $1 billion or less (Aug 2026)
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency (2025)
- European Union, General Data Protection Regulation (EU) 2016/679, Article 33
- EU AI Act, Article 26: obligations of deployers of high-risk AI systems
- Gartner, survey of 1,303 leaders at organisations with $50M+ revenue, Jan–Apr 2026; geography not stated (Sep 2026)
