# Agent Incident Postmortem — Template

Postmortems for AI-agent incidents fail in a specific way: the write-up describes what
the *system* did and skips what the *agent* was asked, told, and remembered when it did
it. This template forces the agent side into the record. Fill it blamelessly — the
goal is the mechanism, not the culprit.

Marcus Patman, Adventure On The Wave. Free to use, no warranty. Version 1.0, October 2026.
Companion page: adventureonthewave.com/production-ai/agent-incident-postmortem

## 0. Metadata

- Incident ID / dates (detection → resolution):
- Severity and affected systems/customers:
- Filled in by:  Reviewed by:  Status: [ ] draft [ ] complete [ ] actions closed

## 1. Summary (5 lines max)

What the agent was supposed to do, what it actually did, and the impact — in plain
language a non-engineer can follow.

## 2. Impact

- Duration (detection → mitigation → full recovery):
- User-visible impact:
- Systems and data touched (including anything the agent *read*, not only changed):
- Cost of the incident: token/compute spend during the incident window, plus
  engineering time, plus [OTHER COSTS]. If spend telemetry cannot produce this number,
  that is a finding — write it down.

## 3. Timeline

Timestamp, source (trace / log / alert / human), event. Anchor every row to a trace ID.
Note the gap between the agent acting and a human noticing — that gap is your time-to-detect.

| Time (UTC) | Source | Event |
| --- | --- | --- |
| | | |

## 4. The agent's task and context

- What the agent was asked to do (the task/ticket):
- The prompt / instruction actually in effect (link or verbatim excerpt):
- What the agent remembered (memory/context files, tool states, prior runs it relied on):
- Model and version in use, and whether it changed recently:
- Tools the agent could reach during the incident:

## 5. What the agent did (from traces, not memory)

- Actions taken, in order, with trace references:
- Spend and retry counts (was a cap in effect? did it bind?):
- Where the behavior diverged from the task — the exact step:

## 6. Root cause

Pick the primary class (and describe the specific mechanism):

- [ ] Prompt/instruction ambiguity
- [ ] Context poisoning (stale/incorrect memory, prior-run contamination)
- [ ] Tool misbehavior or misconfiguration (wrong tool, wrong scope, wrong creds)
- [ ] Model behavior change (update, deprecation, provider drift)
- [ ] Loop/retry without a binding cap
- [ ] Permissions too broad (the guard that would have contained this was missing)
- [ ] Review gate bypassed, absent, or overruled
- [ ] Plain infrastructure failure (agent incidental)
- [ ] Other:

Mechanism, in one paragraph:

## 7. Containment

What stopped it (kill switch, budget cap, gate, human, luck)? How long did stopping it
take, and what would have made it faster?

## 8. What this incident proves about the guards

- Which guardrail caught it, contained it, or should have:
- Which section of the readiness checklist did this incident live in
  (adventureonthewave.com/production-ai/readiness-checklist — section number):

## 9. Action items

| # | Action | Owner | Due | Closes which gap |
| --- | --- | --- | --- | --- |
| 1 | | | | |

Rules: every action has an owner and a date; "be more careful" is not an action;
at least one action must touch a mechanism (permission, cap, gate, alert), not a document.

## 10. Follow-up

- [ ] Traces/logs retained for [RETENTION PERIOD] (link):
- [ ] Checklist re-run for the affected scope:
- [ ] Permissions matrix updated if the boundary was wrong:
- [ ] This postmortem linked from the agent's memory/context so the same agent class
      can read it (context is where agent incidents repeat or stop repeating):