Incident Post-Mortem — by an AI council
Run a blameless post-mortem that finds the real systemic cause. Four rival AIs debate it and hand back: A blameless post-mortem with root causes and concrete preventions.
A blameless post-mortem with root causes and concrete preventions.
Signed off by an independent Final QA audit — with a “verify before you rely on this” list, never a black box.
Why this team
Post-mortems fail in two directions: they find a scapegoat, or they produce a wall of action items nobody does. The Reliability Engineer reconstructs the timeline as systems saw it, the Systems Thinker pushes past the trigger to the conditions that made the trigger matter, and the Pre-Mortem Analyst asks which near-misses foreshadowed this. The Data Skeptic separates real prevention from theatre, the Software Architect owns the blast-radius question, and the People Lead keeps it blameless — because the moment blame enters, information stops.
Each seat runs on a different frontier model — GPT, Claude, Gemini, Grok — so it’s a genuine cross-model review, not one AI in costumes. How a run works →
What the debate sounds like
An illustrative excerpt — A payments service was down for three hours after a routine database migration locked a critical table during peak traffic; the engineer who ran it had followed the documented runbook.
Timeline first, blame never: the migration ran at 14:00 — peak traffic — because the runbook does not specify a window. Lock contention cascaded in four minutes, but the page fired at 14:22, which means eighteen minutes of the outage were a detection gap, not a migration problem. Two separate findings already, and neither is a person.
The five-whys bottoms out in an incentive, as usual: migrations are the only change class that skips staging because the staging database is a fraction of production size, so lock behaviour is invisible before production. The runbook is a symptom. The system made this failure eventual — this engineer merely collected it.
On the proposed fixes: “add a migration checklist item” is theatre — the runbook was followed perfectly, so more runbook changes nothing. Production-scale lock testing on a database clone and an automatic migration window guard are mechanical preventions; those two would each have stopped this outage. Fund the mechanical ones, skip the ceremonial ones.
Questions
What should I paste in — how detailed must the timeline be?
What happened in order with rough timestamps, the user impact, how it was detected and resolved, and your current theory of the cause. Gaps are fine and are themselves findings — “we don’t know when it started” is a monitoring gap the synthesis will flag with the rest.
How does this stay blameless when someone clearly made a mistake?
The method assumes a competent person acting reasonably inside the system as it exists — then asks what about the system made the mistake possible, invisible or damaging. In the example above, the engineer followed the runbook exactly; the findings are all structural. That reframe is the entire value of the format.
We already do post-mortems — why put one through a council?
Internal post-mortems inherit internal politics: the infrastructure team writes infrastructure findings, and the first plausible root cause ends the digging. Independent personas have no turf, so the five-whys goes past the comfortable stopping point — and the Data Skeptic culls the action items that exist to look thorough rather than to prevent recurrence.
Your material is used only to run your review — never to train public models. Encrypted in transit and at rest. Security & privacy →
Want full control — pick your own minds, set the depth? Open the full council →