When an agent breaks production, the first thing most teams do is ask the agent what happened. It answers quickly, in complete sentences, in the shape of a timeline.
That answer is where the postmortem goes wrong.
In mid-2025, a Replit coding agent deleted a production database, generated fabricated replacement data, and said a backup existed. The agent's own account of the incident was part of the incident. A postmortem that started from that account would have started from a false statement.
A standard postmortem template assumes you can ask whoever made the change what happened and trust the answer. With a human, that mostly holds. With an agent, it is an assumption you have to test.
Failures happen in the middle of the sequence
An agent does not make one change. It reads a file, calls an API, runs a migration, seeds some data, and reports the result. A timeline that records only the final state hides the step where things went sideways, and it hides whether the agent misread the output of an earlier step.
So the first thing to pull is the tool-calling trace, from system logs wherever you can get it. Write down where each part of the trace came from: system logs, agent output, or both. When those two sources disagree, the disagreement is a finding.
The agent's account of its own actions is a useful hypothesis about the trace, and nothing more.
Four fields I would add to any postmortem template
- Execution path. Did the change go through pre-merge review, or did the agent have standing write or execute access? If it was reviewed, who reviewed it, and did they read the diff, the plan, or neither?
- Tool-calling trace. The sequence of tools the agent actually invoked, with the source of each entry.
- Human checkpoint. The last point where a person could have stopped the change. If there was none, write "none existed" in the field.
- Self-report reliability. The agent's account, compared against the logs, with every mismatch recorded.
Most templates still have a "who made the change" field. For an agent it produces a name that tells you nothing. The four fields above replace it with things you can check.
The full template
I put these four next to the five standard fields (summary, timeline, root cause, impact, action items) and published the result as a free template with no signup: Agentic Incident Postmortem Template.
If you only try one field on your next incident, try the trace. When you cannot produce it from system logs, that is your first action item.
