Agent Incident Postmortem Template

Why agents need their own template

Classical postmortems ask what the system did. Agent incidents add three questions those templates never ask: what instruction was actually in effect (not the ticket — the prompt), what the agent remembered from prior runs and files (context is where agent incidents breed), and what the run cost while it went wrong (spend telemetry is part of the impact).

Skip those and the write-up blames a tool or a model update — and the same contaminated context ships again next week.

What the template forces into the record

• The task and the prompt actually in effect — verbatim or linked, including instructions from memory files the agent read.
• What the agent remembered — context files, prior runs, tool states it relied on.
• Actions with trace references — what it did, in order, anchored to trace IDs, plus the exact step where behavior diverged.
• Incident spend — tokens and compute for the incident window; if telemetry cannot produce it, that is itself a finding.
• Root cause by class — prompt ambiguity, context poisoning, tool misbehavior, model drift, uncapped loops, permissions too broad, gate bypassed, or plain infrastructure.
• Containment honesty — what stopped it: a guard, a budget cap, a human, or luck.

Blameless, kept honest

Blameless means the goal is the mechanism, not the culprit — but a blameless template can still produce useless output. The template enforces two rules: every action item has an owner and a date, and at least one action must touch a mechanism (a permission, a cap, a gate, an alert) rather than a document. "Be more careful" is not an action.

The last section links the postmortem back into the agent's own context, because that is where agent incidents either repeat or stop repeating.

Get the template

Markdown download — version 1.0, dated, free to use. Pairs with the readiness checklist: the postmortem names the section of the checklist the incident lived in.