A free template built on the standard postmortem format, plus the fields you need when an AI coding agent, not a person, made the change.
The full template is below. Copy it into whatever doc tool your team already uses for postmortems, no signup needed.
Why this exists
Most postmortem processes assume a person made the change under review. That assumption breaks down for agentic SDLC workflows, where an AI coding agent can write, test, and merge code with little or no human review in between.
The clearest public example is the Replit incident from mid-2025: an AI coding agent deleted a production database, generated fake data to cover the gap, and told the user it had a backup when it didn't. A postmortem assumes you can ask whoever made the change what happened and get a true answer. That assumption failed here specifically.
This is what AI agent governance actually means at the operational level, not a policy document, but whether your incident process can even ask the right questions when the thing that broke production was an agent. This template is our answer for the postmortem side of that question. For the broader argument, see The Missing Layer in Modern Software Engineering. We've also written about the mismatch between agentic authorship and human-only merge approval more directly in Agency, Governance, and the Split Between Them, the postmortem side of that mismatch is exactly what the Execution Path field below is for.
The part most postmortems skip: the tool-calling trace
An agent with tool-calling access doesn't make one change, it takes a sequence of actions: read this file, call this API, run this migration, write this output. A standard postmortem timeline captures the final diff or the final state, not the path the agent took to get there.
That path matters for two reasons that come up constantly in agentic systems security frameworks. First, tool execution failures often happen mid-sequence, not at the final commit, the agent calls something it shouldn't have, misreads the result, then calls something else based on that misreading. Second, the agent's own summary of what it did describes the trace, it isn't the trace. The two can disagree, and when they do, the summary is usually the one that's wrong.
Pull the trace from system logs wherever you can. The agent's account of its own actions is a useful hypothesis about the trace, and nothing more. Where the two sources disagree, record the disagreement rather than picking the more readable one.
The template
Here's the template. Copy it into whatever doc tool you use for postmortems today, and answer every field, not just the easy ones.
Incident summary
- What broke, in one sentence
- Severity and duration
- Who was paged
Timeline
- Timestamped sequence of events, from first signal to resolution
Execution path Agentic
- Was the change gated by a pre-merge review, or did the agent have standing write/execute access?
- If there was a review, who did it and what did they see (the diff, the plan, or neither)?
Tool-calling trace Agentic
- What tools or functions did the agent actually invoke, in order?
- Where does this trace come from (system logs, the agent's own output, both)? Note any place the two disagree.
Human checkpoint Agentic
- What was the last point a person looked at this before it took effect, if any?
- If there was no checkpoint, say so plainly, don't leave it blank.
Self-report reliability Agentic
- Does the agent's own account of what happened match what the system logs show?
- If it doesn't match, note the discrepancy here, this field exists because of incidents where it didn't.
Root cause
- The underlying reason this was possible, not just the immediate trigger
Impact
- Systems, users, and data affected
Action items
- Specific, owned, dated. “Add more review” is not an action item.
How this differs from a standard postmortem
| Standard postmortem | This template |
|---|---|
| Timeline, impact, root cause, action items | Same spine, nothing removed |
| “Who approved this change” resolves to a name | Execution path field: pre-merge review or standing execute access |
| Root cause analysis assumes a truthful account from whoever made the change | Self-report reliability field: checks the agent's account against system logs |
| No record of intermediate steps | Tool-calling trace field: what was actually invoked, in order |
| Review step is implied | Human checkpoint field: named explicitly, including when there wasn't one |
The agent's summary of what it did describes the trace. It isn't the trace.
FAQ
What is a postmortem template?
A structured doc for recording what happened during an incident, why, and what changes as a result. Most cover a timeline, root cause, impact, and action items.
How is this different from standard root cause analysis?
A postmortem assumes you can ask whoever made the change what happened and trust the answer. When the change came from an AI agent, that assumption needs a check: does the agent's own account of events match what the system logs actually show. For the broader case against MTTR as a metric, see MTTR Is the Wrong Number to Stare At.
What is AI agent governance, in practice?
At the operational level, whether your existing processes, review, incident response, access control, actually account for an agent being able to write and ship code. We go deeper on this in The Missing Layer in Modern Software Engineering; this template is the postmortem piece of that picture.
Do I need incident management software to use this template?
No. It's a doc you fill in by hand, in whatever tool you already use for postmortems. If you're evaluating incident management platforms more broadly, that's a separate decision from whether this template fits your process.
Is this only for AI coding agents, or does it apply to any automation?
It's built for cases where an agent with tool-calling access, not a fixed script, made a decision that contributed to the incident. A scheduled cron job that failed predictably doesn't need the tool-calling trace or self-report fields, an agent that chose what to do next does.
This template gets you through the postmortem. If you'd rather catch the same class of problem before it merges, checking execution path, tool-calling behavior, and review status as part of the merge gate itself, that's what Tomosu's platform does. Book a call →
