Executive Leadership
The AI Incident Playbook: What Executives Owe Their Team When an Agent Fails
At 2:14 on a Tuesday morning, an agent in my fleet published a page with a claim we had never made. This is the playbook that morning produced.
The sentence the agent wrote was plausible. That was the problem. It took two real figures from two different contexts and averaged them into a third number that described nothing, then placed that number on a customer-facing page with complete confidence. A customer emailed about it before anyone on my team had seen the change.
The morning cost us one corrected page, one embarrassed apology, and about four hours of reconstruction work. What it gave us in return was worth more: a written playbook. When I went looking for the executive version of what to do when an AI system fails in production, I found plenty of model-level postmortem templates and almost nothing for the person who owns the outcome rather than the architecture. This is the document I wished existed at 2:14 a.m.
Decide what counts as an incident before you have one
Most teams define severity in the middle of their first real failure, which is the worst possible time to have that argument. Someone is saying it is a typo while someone else is quietly checking whether money moved. A working ladder settles the argument in advance:
- Cosmetic. Wrong tone, off-brand phrasing, broken formatting. Fix it in the normal queue and note it in the weekly review.
- Internal wrong. An agent misroutes work, duplicates effort, or burns spend on the wrong target. No customer sees it, but time or money is gone.
- Customer-visible wrong. A fabricated claim, bad pricing, a confident incorrect answer delivered to someone paying you. This requires correction and usually an apology from a named human.
- Material. Money moved, data exposed, or a commitment made that the company cannot honor. Legal is in the room, and so is the board.
The rung that deserves the most preparation is the third one. That is where the large majority of AI incidents live, and it is exactly where most organizations have no script at all.
The first hour belongs to containment
Stop the agent. Every production agent in my fleet has a kill switch, and we test the switches the way other teams test backups, because an untested kill switch is a rumor. Freezing the agent’s mandate comes next: nothing new gets queued until someone has read what it already did.
Then snapshot everything. Logs rotate, queues drain, caches expire, and the evidence you want at noon is gone by breakfast if nobody freezes it. Pull the full output history for the window in question and store it somewhere the incident itself cannot touch.
The last containment step is blast radius. The question is never what the agent did wrong once. The question is what else it did while nobody was looking, so everything the agent touched in the preceding days gets pulled and reviewed by a human before the agent earns its mandate back.
The 24-hour rule
Within twenty-four hours of a customer-visible incident, write down what happened in plain language and send it to everyone with a stake. Not a legal review. Not a deck. A note.
The note has two jobs. It tells the truth about what happened, in sentences a customer could read, and it states plainly what changes as a result. Customers affected by the incident hear from a person, by name, before they have a chance to discover the problem themselves. The fastest trust repair I have ever seen came from a company that called its customers before breakfast; the slowest came from one that waited for its lawyers to approve adjectives.
What I tell my own board
I tell them before they ask.
A material incident goes to the board with the same 24-hour note, unedited. Boards that only hear about AI failures inside quarterly decks draw one of two conclusions, and both are bad: either the failures are being hidden, or management cannot see them. A director who receives a plain note within a day learns something far more useful, which is that the detection system works and the executive running it is awake. I have written about the questions boards should be asking on this front in the director’s oversight agenda, and the disclosure habit is what makes those questions answerable.
The postmortem has to change the system
A postmortem that ends with “we updated the prompt” is unfinished. Prompts are suggestions. Constraints are architecture. The durable fix lives in a place the agent cannot talk its way out of: a verification step, a narrower permission scope, a publishing gate that requires a signature.
My Tuesday morning ended with one new rule. No agent in the fleet publishes customer-facing copy without a human or a dedicated checker agent signing the diff, line by line, against a source-of-truth document. The rule cost us some speed on low-stakes pages. It has since caught two fabrications before they shipped, and both times the signature requirement was the entire difference.
Assign the follow-through the way you would assign any deliverable: one named owner, one date, one verification that the fix actually shipped. I covered the broader discipline in what broke when I scaled agents into executive workflows, and the pattern holds here. Incidents repeat themselves in organizations where the postmortem produces agreement instead of change.
Incidents are tuition
Every fleet that does real work will produce real failures. The dividing line between companies is what each failure purchases. In the good case, an incident buys a permanent improvement to the system and a little more trust from everyone who watched you handle it honestly. In the bad case, it buys a quiet rule that agents should do less, which is another way of deciding that competitors get the leverage and you get the illusion of safety.
You will have your own 2:14 a.m. Write the playbook now, while the stakes are imaginary, and the morning after will go considerably better.
This article is part of the Executive Leadership cluster, focused on board governance and the operating discipline required to run AI systems responsibly at the executive level.