When a service goes down, someone still has to write the postmortem afterward. Multi-agent pipelines are starting to draft it before the incident channel even goes quiet.
See the pattern in action, tap through the tabs below:
The blank page shows up right when the team has the least energy for it. The incident resolves, the channel goes quiet, and now someone (usually the person who was paged at 2am) has to reconstruct a timeline from Slack scrollback, PagerDuty events, and three dashboards that have already rolled off retention. Most teams write postmortems days later, from memory, which is exactly why root cause fields so often read “network blip, self-resolved.”
Automated Postmortem Drafting flips the order: a coordinator agent starts pulling evidence the moment the incident opens, not after it closes.
postmortem_pipeline:
trigger:
source: pagerduty
event: incident.triggered
min_severity: sev2
coordinator_agent:
model: claude-sonnet
role: "Investigation coordinator"
spawns:
- metrics_agent:
reads: [datadog, grafana]
task: "Pull anomalies in the 30min window before trigger"
- trace_agent:
reads: [honeycomb]
task: "Trace the failing request path end to end"
- deploy_agent:
reads: [github, argo_cd]
task: "List deploys/config changes in the last 4 hours"
- comms_agent:
reads: [slack]
task: "Timestamp key messages in #incidents thread"
synthesis_agent:
model: claude-sonnet
inputs: [metrics_agent, trace_agent, deploy_agent, comms_agent]
output: postmortem_draft
sections:
- summary
- timeline
- root_cause_hypotheses
- impact
- action_items
delivery:
on_incident_resolved:
- post_draft_to: slack_thread
- create_doc: confluence
- tag_owner: incident_commander
- require_human_approval: true
[14:02:11] INCIDENT sev2 triggered: checkout-api p99 latency [14:02:13] coordinator_agent: spawning 4 sub-agents... [14:02:19] metrics_agent: found latency spike starting 13:41:02 [14:02:24] deploy_agent: flagged deploy a41f9c2 at 13:38:00 (config change: connection pool size 100 to 40) [14:02:31] trace_agent: 92% of slow requests blocked on db pool checkout [14:02:36] comms_agent: on-call first message at 13:52, escalated 13:58 [14:04:02] synthesis_agent: draft complete, confidence: high [14:04:03] synthesis_agent: root cause hypothesis ranked #1: pool size regression [14:11:47] INCIDENT resolved (pool size reverted) [14:11:52] delivery: draft posted to #incidents, tagged @jordan (IC) [14:11:52] delivery: Confluence doc created, pending human approval [08:14:20] jordan: reviewed, edited impact section, approved [08:14:21] delivery: postmortem published, action items synced to Jira
Start here, in order:
1. Pick one sev2+ incident type to pilot on. Don’t wire this into every alert on day one.
2. Give the coordinator agent read-only access to logs, traces, and deploy history. No write access, no remediation actions, at least for the first quarter.
3. Force a human-approval gate before anything gets published or emailed to stakeholders. The draft is a first draft, not a final report.
4. Track one metric: time from incident-resolved to postmortem-published. That’s the number that tells you if this is actually working.
The 2am problem nobody automates
Every team with an on-call rotation knows the sequence. Page fires, someone scrambles, the fire gets put out, and everyone goes back to what they were doing. Then, three to five days later, an incident commander sits down with a blank document and tries to reconstruct exactly what happened from memory, Slack scrollback, and whatever dashboards haven't rolled off retention yet.
The result is predictable: postmortems that are late, thin, or both. Root cause fields fill up with "transient network issue, self-resolved." Action items get logged and never closed because nobody remembers why they mattered three weeks later. The teams that do write good postmortems tend to have one person who's simply better at documentation, which is a bus-factor problem dressed up as a process.
This is the actual bottleneck: not a lack of monitoring data, but a lack of anyone with the time and working memory to synthesize it while it's still fresh.
What Automated Postmortem Drafting actually means
The workflow is simple to describe and genuinely useful once it's running: a coordinator agent starts collecting evidence the moment an incident opens, not after it closes. Instead of one person paging through six tools after the fact, a small fleet of specialized agents each own one source, metrics, traces, deploy history, chat, and hand their findings to a synthesis agent that assembles a structured first draft.
By the time the incident is marked resolved, there's already a timeline, a ranked list of root-cause hypotheses, and a list of affected systems sitting in a draft doc, tagged to the incident commander for review. Nobody is starting from a blank page. They're editing.
- Faster: drafts exist within minutes of resolution instead of days.
- More accurate: evidence is pulled while logs and traces are still live, not after retention windows expire.
- More consistent: every postmortem follows the same structure regardless of who was on call.
How it's built
You don't need to build this from scratch. Platforms like incident.io already run a multi-agent investigation layer that searches pull requests, Slack, logs, metrics, and traces in parallel to build root-cause hypotheses within a couple of minutes of an incident opening. PagerDuty has shipped a comparable SRE Agent for enterprise accounts, and Kubernetes-heavy shops are using Komodor's Klaudia, which is trained specifically on cluster telemetry.
If you'd rather build your own (and plenty of platform teams do, since it's cheaper at scale and easier to tune to your own runbooks), the pattern is a coordinator/sub-agent design: one orchestrating agent that fans work out to narrow, single-purpose agents, then a synthesis step that merges their findings into the draft. n8n or a lightweight CrewAI setup both work fine as the orchestration layer; the model doing the actual reasoning matters less than the discipline of keeping each sub-agent's job narrow and its data access read-only.
That last point is the one teams skip and regret. Give the investigation pipeline read access to logs, metrics, traces, and deploy history. Do not give it write access to production, and do not let it auto-publish anything without a human approval step. The draft is there to save someone an afternoon of reconstruction, not to replace their judgment about what actually happened.
Where this breaks
Root-cause hypotheses from an agent are still hypotheses. They're ranked by confidence, not certainty, and they'll occasionally anchor on the most recent deploy when the real cause is upstream. The fix isn't more automation, it's keeping a human in the loop at the approval gate, and training your team to treat the draft as a strong first pass rather than a verdict. Teams that skip the review step end up with postmortems that are fast, consistent, and occasionally wrong in the same way every time.
FAQ
Does this replace the incident commander?
No. It removes the reconstruction work, not the judgment call. The IC still owns the final narrative and the action items.
What's the minimum viable version of this?
A webhook from your paging tool that fires a script pulling recent deploys, a metrics snapshot, and the Slack thread into a single doc. No agents required to get 60% of the value; agents help you get the rest.
How do we avoid the agent hallucinating a root cause?
Rank hypotheses by confidence, always show the underlying evidence next to each claim, and require sign-off before anything ships externally or gets treated as final.
If your team wants this wired into an actual on-call and incident response workflow instead of piecing it together from blog posts, tha-shed's DevOps Boot Camp covers the practical side of building and operating pipelines like this one.
