Postmortem Writing by Hand vs With an AI Agent: What Changes and What Doesn't

Writing a postmortem by hand means an engineer reconstructs a timeline from chat logs, pager history, and dashboards days after the incident, then drafts the document alone. With an agent, the draft is assembled from the recorded incident history and the confirmed root cause, and a human reviews and approves it. The format is not new: the Google SRE book chapter on postmortem culture describes the blameless structure, and Etsy's write-up on blameless postmortems explains why the culture matters. What an agent changes is who does the assembly work. It does not change who owns the conclusions.

Key Takeaways

• •Most of the manual effort in a postmortem is reconstruction: collecting the timeline and evidence from several tools, not analysis.
• •Our dw-postmortem-writing skill, run by the Incidents Agent, authors a blameless postmortem from incident history and the confirmed root cause.
• •An agent drafts from what was recorded. It cannot supply context nobody wrote down, so a human still approves the root-cause narrative and the action items.
• •Evaluate an agent on a real past incident you already know well. Check the timeline against the record and check that no individual is blamed.
• •Our opinion: the biggest win is that postmortems actually get written for smaller incidents, which manual workflows tend to skip.

Postmortem writing by hand vs with an AI agent: the short version

A postmortem is a blameless written record of an incident: what happened, why, what it cost, and what changes as a result. The job usually lands on whoever was on call or whoever resolved the incident. They write it after the pressure is gone and while their next project is already waiting. Done by hand, it works when the team protects the time. It degrades when incidents are frequent, when the timeline lives in five tools, or when the author was not the person who found the root cause.

The question for most data teams is not whether an agent can write prose. It is which part of the job is assembly and which part is judgment. Assembly can be delegated. Judgment about cause, severity, and follow-up still needs an accountable person.

The job and who does it today

In a data platform team, the postmortem author is typically the on-call data engineer or the engineering lead of the affected pipeline. The reader list is wider: analytics consumers who saw bad numbers, a governance owner if a policy was involved, and leadership asking whether this will happen again. The document has to serve all of them, and it has to stay blameless. That means it describes system conditions and decisions rather than pointing at a person.

The manual workflow, step by step

We have seen the same sequence at most teams, with small variations. These are our observations, not a measured benchmark.

• •Collect the raw record: the pager or alert history, the incident channel thread, and the ticket if one was opened.
• •Rebuild the timeline: detection time, first response, hypotheses tried and discarded, the change that fixed it, and the time of recovery.
• •Pull supporting evidence: query logs, orchestrator run history, a lineage view of affected tables, and any recent deploys or schema changes.
• •Confirm the root cause. This is often a conversation with whoever made the fix, because the chat thread contains several wrong theories before the right one.
• •Quantify impact: which tables, dashboards, and downstream consumers were affected and for how long.
• •Draft the document in the team template: summary, timeline, root cause, contributing factors, what went well, what went poorly, action items.
• •Circulate for review, revise, assign owners to action items, and file it where people can find it later.

Where it breaks: steps 1 through 3 are slow and tedious, and they depend on memory and on which tool someone remembers to check. The timeline is the most error-prone piece, because chat timestamps, orchestrator timestamps, and alert timestamps rarely agree. Step 4 stalls when the person who fixed the incident is on leave. Step 7 stalls when nobody owns it. The usual failure is not a bad postmortem but a missing one, especially for incidents that were fixed quickly and felt minor.

What an agent does instead

Our Incidents Agent ships a skill called dw-postmortem-writing. Its description is narrow on purpose: it authors a blameless postmortem from incident history and the confirmed root cause. It starts from two inputs, the recorded history of the incident and the root cause once it has been confirmed, and produces the written document. It does not decide what the root cause was. That input arrives already confirmed.

Every Data Workers agent is an MCP server, so the skill can be invoked from Claude Code, Cursor, or any MCP-compatible client. The Model Context Protocol is the open standard behind that. In practice, an engineer finishes the fix and asks for the postmortem in the same terminal session. This matters because the context is still fresh and the history is still attached to the incident.

The agent is the same one that debugs failed pipelines and traces root cause across lineage, logs, and queries. That is why the postmortem skill has something to work from. Our opinion: a postmortem writer with no access to the incident record is just a template generator. The value comes from the record already being in one place.

Manual vs agent: side by side

We are deliberately not putting hour counts in this table. We have no attributed benchmark for postmortem authoring time, and a made-up figure would be worse than none. Measure it on your own incidents. Time how long the last five postmortems took, then compare the agent's draft plus review time.

What still needs a human approval

An agent drafts from what was recorded. Anything outside the record is invisible to it: the decision made on a call that nobody noted, the reason a mitigation was chosen over another, the organizational pressure that shaped a deploy. A human reviewer has to check at least these:

• •The root-cause narrative: does it match what actually happened, including contributing factors the record does not show?
• •The timeline: are detection, response, and recovery times correct for the audience that will read them?
• •Blameless language: does anything read as fault in a person rather than a gap in a system or process?
• •Impact statement: have the real consumers of the affected data been accounted for?
• •Action items: are they specific, owned by a named person, and worth doing?

Our default is that nothing the agent drafts gets published without sign-off. In the open-source edition we ship read-only by default, and in Pro, writes sit behind approval workflows with audit trails. A postmortem is a record that other people will rely on, so approval is not a formality.

How to evaluate an agent for this job

Do not evaluate on a demo incident. Pick a real incident from the last quarter that your team already wrote up by hand, and run the agent against the same history. Then compare.

• •Timeline accuracy: every event in the agent's timeline should be traceable to the record. Mark anything that cannot be.
• •Root-cause fidelity: the document must reflect the confirmed cause and not introduce a different one.
• •Blamelessness: read it as an affected engineer would. No names attached to faults.
• •Omissions: list what your human-written version had that the draft lacks, and ask whether the record could have contained it.
• •Review cost: how long did your reviewer spend correcting it, compared with writing from scratch?
• •Fit with your template: can it follow the format your team and auditors already expect?

Run this on two or three incidents, including one small one and one messy one. If the draft needs a full rewrite on the messy one, that tells you your incident record is thin, which is useful to know regardless of the agent. We covered why detection alone leaves a gap before the fix in our earlier writing on incident resolution, and the same logic applies here: the postmortem is only as good as what was captured while the incident was live.

Frequently Asked Questions

Can an AI agent write a blameless postmortem on its own? It can draft one from incident history and a confirmed root cause, which is what our dw-postmortem-writing skill is described to do. We would not publish it without a human reading it. Review catches missing context and any wording that assigns fault to a person.

What input does the agent need to write a postmortem? Two things: the recorded history of the incident and the confirmed root cause. If the root cause is still disputed, finish that conversation first. A draft built on an unconfirmed cause will read confidently and be wrong.

Does using an agent make postmortems less blameless? Not by itself. Blamelessness is a property of the structure and the language, both of which the reviewer can check. The risk is the opposite one: a team that skips review will not notice a phrasing problem. The principles in the Google SRE book still apply to agent-drafted documents.

Which tools can I run it from? Every Data Workers agent is an MCP server, so you can invoke the skill from Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot, or any MCP-compatible client. The OSS edition is Apache 2.0 and runs locally.

Should we use an agent for every incident or only major ones? Our opinion is every incident that your team would otherwise skip. The main practical gain is coverage: small incidents rarely get a manual postmortem, yet they often show the pattern that precedes a large one.

If you want to try this on a past incident, start with the Incidents Agent at dataworkers.io, and compare its draft with the postmortem your team wrote by hand.