What is a post-incident review?

A post-incident review is a structured examination, held after an incident is contained, of what happened, why it happened, why it was not caught sooner and what will change as a result. When an AI agent was involved, the review must cover the agent's bounds and evidence, not only the technical fault.

Why does a post-incident review matter for agents?

Agent incidents tend to have layered causes. A source changed, the agent's certificate did not cover the new case type, the customer limit was looser than intended, and the reviewer approving drafts had stopped reading closely. Fixing only the first cause leaves the others waiting for the next incident.

A review also protects trust in the programme. Staff, risk teams and supervisors will accept that agents sometimes err. They will not accept the same error twice, or an organisation that cannot explain what its agent did.

How does it work in practice?

The review usually happens within a week or two of containment, led by someone not directly responsible for the agent. It works through:

1. Timeline: from the first wrong action to the stop, built from the verdict record.
2. Impact: customers and accounts affected, actions reversed, money involved.
3. Causes: what changed or failed, and which bound should have stopped it.
4. Detection: what signal first showed the problem, and how long it took to act.
5. Response: how containment and remediation went.
6. Actions: each with an owner and a date, including recertification if needed.

The review should be blameless in tone and exact in substance. "The reviewer missed it" is not a cause; "the review screen did not highlight changed payee details" is.

What does an example look like?

An agent at a building society drafted interest rate change letters, sent after approval by a savings officer. Some letters quoted the old rate. The review finds that the agent read rates from an internal web page, not the sealed rate table; the page was updated a day late; and approvals averaged a few seconds per letter. Actions: switch the agent's rate source to the system of record, add rate fields to the review screen with their source shown, and recertify the capability. The findings are written into the AI agent incident report template.

How is it different from incident response?

AI incident response is the live work: detect, contain, assess, remediate. The post-incident review comes after and looks for causes and lasting fixes. Response asks "how do we stop the harm?"; review asks "why could it happen, and what will stop it next time?" The steps of response are covered in handling an AI agent incident.

It also differs from an investigation, which establishes facts, sometimes for regulatory or legal reasons. An investigation may feed the review; how to investigate an AI agent incident covers that work.

What should the review ask about the agent specifically?

• Was the action within the agent's certified depth for that capability?
• Were the facts it used from sources strong enough for the action?
• Did the customer's limits match what the business intended?
• Did the evidence behind the certificate include cases like this one?
• Did people reviewing held actions have what they needed to catch it?

Which terms sit close to it?

Root cause analysis, near miss and lessons learned describe parts of the same work. For how review fits into running agents, see our guide to deploying AI agents.

Where Pryme fits

Pryme's append-only verdict record lets a review rebuild the timeline exactly: every action attempted, the facts used with their provenance class, the certificate in force and the bound that decided. The review's actions often land as changes to the agent's brief, sources or bounds, followed by a fresh Attest run.