The Scribe — the postmortem drafts itself twenty minutes after resolution; you verify, not excavate
The Scribe flips the labor of postmortems: an agent assembles the timeline from your chat export, alert history, and deploy log the moment the incident closes, and drafts a blameless record where every single claim carries a verbatim source quote. Your job shrinks to verifying the claims.
Every team agrees postmortems matter, and every team has a backlog of unwritten ones — because assembling a record from three hours of channel scrollback is miserable work that lands on whoever is most exhausted.
The scenario — before and after
Two weeks late
- 14:02
Alert fires. Tuesday, July 8: p99 latency on
checkout-api. Priya, the on-call SRE, spends 75 minutes in#inc-checkout-latencywith four colleagues, chasing a Redis red herring for ten minutes before someone spots the 13:47 deploy that shrank the database connection pool from 100 to 20 per replica. - 15:09
Rollback. Resolved at 15:17, twenty-three support tickets, nice work all. Then the EM types the sentence every channel dreads: "postmortem doc... who wants it," and everyone looks at their shoes.
- +11 days
The doc is still a title and an empty template. The review meeting has been rescheduled twice.
- The archaeology
Priya finally blocks a Friday afternoon: scrolling four hundred messages interleaved with samosa jokes, reconstructing whether the rollback finished at 15:09 or 15:12 — it matters, because the error-rate alert resolved at 15:14 and the sequence determines whether the rollback actually fixed it — and trying to remember why the Redis theory felt so convincing at 14:16.
- +3 hours
A timeline she half-trusts, a contributing-factors section written from memory, and action items vague enough to survive any review ("improve deploy safety").
The postmortem ships two weeks late, the review meeting is a formality because nobody remembers the details either, and the config-review gap that let a staging value reach production is still open when the next incident arrives. This is postmortem debt: the organization pays interest in repeated incidents on lessons it technically already learned.
Twenty-five minutes of verification
Same 15:17 resolution — but the incident tool's "resolved" webhook now triggers the Scribe. It pulls three sources it can only read: the channel export, the alert history from PagerDuty, and the deploy log.
checkout-api → postmortem draft
- Every timeline entry and contributing factor carries a verbatim quote — "the perf PR changed db pool max_connections from 100 to 20 per replica" sits right under the claim it supports, and Priya can grep for it
- Blameless by construction: the draft says "the on-call engineer" and "a service developer," never names
- The Redis theory appears nowhere as a factor — it was investigated and ruled out in the sources, so the Scribe leaves it out
- Exactly how many customers were affected sits in Unknowns, rather than as a confident invented number
Each claim in the draft ends with a
VERIFY:checkbox.
Priya's job is now a twenty-five-minute verification pass, not a three-hour excavation. She ticks the claims the quotes support, edits one timeline entry where the agent's phrasing overstated certainty, strikes an action item that duplicates existing work, and publishes the next morning. The review meeting three days later argues about the fixes, because nobody has to argue about the facts.
Client-safe by design — the drafting step runs against an approved tenancy (Claude on AWS Bedrock, Azure OpenAI) or fully local via Ollama, with hostnames, account IDs, and customer names replaced by stable placeholders before the export reaches a model so quotes stay greppable after redaction. Full setup is in the build guide below.
The flow — where AI plugs in, where value lands
Blue = AI-added step · Amber = human control point · Gray = your existing tools.
Value at each step
| Step | Who acts | What changes | Why it matters |
|---|---|---|---|
| Incident closes | Your incident tooling | The "resolved" event triggers the Scribe automatically | Drafting starts while memory is fresh; nobody has to volunteer |
| Evidence gathering | Agent (read-only) | Chat export, alert history, and deploy log are pulled into one context | Three hours of channel archaeology drops to zero human minutes |
| Timeline assembly | Agent | Sources are interleaved into one timestamped sequence, each entry quoting its source | "When did the rollback actually finish" stops being a memory contest |
| Draft postmortem | Agent | Summary, contributing factors, action items — and an explicit Unknowns list | The blank page is gone; gaps are declared instead of papered over |
| Claim-by-claim verification | Human | Reviewer ticks, edits, or strikes each VERIFY: checkbox against the quotes | Human judgment is spent where it matters — on truth, not typing |
| Publication | Human | Verified record ships to the wiki or incident tool | Postmortems land in days, not weeks; review meetings discuss fixes, not facts |
| Audit | Your existing tools | Draft, edits, and approver identity are all retained | Trust is inspectable, and drafts become a corpus for spotting repeat patterns |
The six components in your stack
| Component | In this lesson's build | In your stack |
|---|---|---|
| Event source | You run scribe.py by hand | Incident-resolved webhook from PagerDuty, incident.io, Opsgenie, or your status tooling |
| Context stores (read) | Three local mock files: chat export, alerts.json, deploys.log | Slack/Teams export APIs, PagerDuty/Alertmanager alert history, deploy records from any CI (GitHub deployments, GitLab, Argo CD) |
| Action interface (allowlisted writes) | Writes postmortem-draft.md and nothing else | Create a draft page in Confluence, Notion, or incident.io — the agent never gets the publish permission |
| Approval channel | The VERIFY: checkboxes inside the draft | Doc review workflow, or a PR against a postmortems repo — the merge is the approval |
| Verification | You grep each quote against the source files | Claim-by-claim human check; quotes link out to the original message, alert, or deploy record |
| Audit sink + identity | Draft and sources committed to git | Agent runs under its own service account; draft history, edits, and approver retained in git or the incident tool |
The Scribe's safety model is one asymmetry: the agent may draft anything and publish nothing. The draft-with-evidence is the product; the human verification pass is the gate; the publish button never belongs to the agent.
Autonomy tier — start here, promote deliberately
Advise — drafts on request
The agent produces drafts, humans publish. This pattern is unusual among the eight in that the ceiling is low by design.
Auto-post the draft
Sensible promotion is about delivery: let the agent post the draft into the incident channel automatically instead of waiting to be run.
Publication
A postmortem is an organizational truth claim, and truth claims get a human signature.
Review the drafts-vs-published diff monthly; if reviewers are rubber-stamping without checking quotes, that is a verification failure even when the drafts happen to be right.
A confident message in the incident channel is a claim, not a fact. "Pretty sure it was DNS" must never become a contributing factor just because someone typed it with conviction — the Scribe's rules send uncorroborated claims to Unknowns, and your verification pass is what keeps that rule honest.