The Postmortem Field Nobody Can Fill In When an Agent Ships the Bug

Day 16: The Category Blameless Postmortems Never Had a Name For

Blameless postmortems were built on one bet: scared people lie, so remove the fear and you get the truth. Agents never had that fear to begin with — no self to protect, no story to shade. So the moment an agent's merge takes down prod, the ritual you've run for years walks straight into a wall, and nobody notices until the "root cause" field is sitting there empty.

The blank field in the postmortem doc

Here's the incident, and if you're running an agentic coding pipeline you've probably already lived a version of it: an agent — Claude Code, Copilot Workspace, some custom multi-agent merge bot, take your pick — opens a PR. Tests are green, the diff is small, the description reads like someone who knew what they were doing wrote it. An engineer buried under four other reviews glances at it and hits approve. Twenty minutes later it's paging in prod. Someone opens the postmortem doc, gets to "root cause / actor intent," and stalls. The agent didn't intend anything — there's no intent in there to interrogate. The engineer didn't write the bug — they clicked a button. The template has a slot built for a story that doesn't exist in this incident, so it either stays blank or gets filled with something that reads like an answer and isn't one.

The category error: blameless was built for fear, not for agents

Most teams know blameless postmortems through a few lineages that blur together in the retelling: Etsy's original 2012 writeup on blameless postmortems and "just culture," the chapter Google's SRE book later used to formalize the practice, and the incident-response playbooks PagerDuty built to run it on-call teams. Different sources, same mechanism, aimed at one very human failure mode: people under threat of blame hide things, shade the timeline, quietly patch a mess before anyone looks. Take the threat away and people tell you the truth about what they saw and why they made the call. That's it — that's the whole trick. It's a fear-removal device, built for a specific kind of lying: fear-driven concealment.

An LLM agent has no fear and nothing to protect, so it has no reason to misreport anything. Asking "why did the agent do X, was it hiding something" is pointing a fear-removal ritual at an entity that was never capable of the behavior the ritual exists to prevent. That's the category error — not that blamelessness is somehow wrong for agents, but that "what was the actor's intent" doesn't parse for a system with no intent to protect in the first place. Point the whole postmortem machine at the agent's "reasoning" and you've asked the wrong entity the wrong question — and let the one decision that actually mattered, the human clicking approve, slide right out of frame.

The missing category: approved but didn't understand

Classic incident taxonomies give a human near the failure exactly two buckets: they authored the bug — a bad commit, a bad config push — or they were an innocent bystander, paged in, no hand in the cause. Agentic approval opens a third state that fits neither. The engineer took an action — clicking approve — without which the failure never reaches prod. But they didn't, and often couldn't, verify the thing that actually broke. Not the author: the agent generated the logic. Not a bystander: their click was the gate.

• ▹Authored the bug — the engineer wrote or spec'd the faulty logic themselves. Classic case, root cause is a person.
• ▹Innocent bystander — no causal role at all. Paged, uninvolved, a name in the timeline and nothing more.
• ▹Approved but didn't understand — the approval was necessary for the failure to happen, but the engineer's grasp of what they were approving was incomplete, and the interface never forced or even enabled the full picture.

5-whys and blameless timelines force every causal link onto a person or a system component — there's no third slot. Faced with "approved but didn't understand," both formats quietly stuff it into one of the two buckets that already exist. Usually that's "human error, insufficient review" (blaming someone for a gate that never gave them a real shot) or "agent produced incorrect output" (treating the approval as a rubber stamp and erasing the fact that a human actually signed off). Both write-ups are technically true. Both are wrong. They erase the real mechanism — supervised but not comprehended — a category existing frameworks simply have no slot for.

What changes in postmortem mechanics

The fix isn't a new feeling to manage — nobody here needs to feel less blamed. It's a different central question. Stop asking the agent what it "intended." Stop asking the human why they "didn't catch it." Ask instead: who owned the approval gate, and what did that gate actually require them to verify before the approve button would even work? That question has a real, checkable answer no matter whether the actor on the other side is silicon or human — and it's the one lever a manager can actually pull. You can't audit an LLM's intent. You can absolutely audit whether your merge gate made someone read the diff, run it against staging data, or just click a green button next to a summary the agent wrote about its own work.

The concrete fix: add a comprehension checkpoint section

Make this a named section in the postmortem template — not a bullet buried three levels into the timeline. Put it right next to root cause and impact. Three fields:

• ▹What the approver could see — the full diff, a summarized diff, test output, the agent's own rationale in plain English, or nothing at all.
• ▹What the approver actually checked — which of those they opened and read, versus which they trusted on autopilot. This is the honest, blameless part: people will tell you this straight if the doc doesn't read like an accusation.
• ▹What the tool surfaced vs. what it hid — the gap between what was technically available and what was actually legible in the time the approver had. A 400-line diff sitting in a collapsed view is "shown" on paper and hidden in practice during a 90-second review window.

That third field is usually where the real finding lives. In most "approved but didn't understand" incidents, the tool didn't lie and the human didn't skip a step — the interface just made comprehension technically possible and practically unreasonable given the time the reviewer actually had. That's something you can fix: shrink the diff surface per PR, force a staging run before the approve button unlocks, make the agent flag its own uncertainty inline instead of burying it in a changelog-style summary nobody reads twice.

The stakes for engineering leaders

As agentic pipelines mature, "review the diff" is quietly turning into "approve the agent's output" — and that shift is becoming the dominant way humans touch shipped code. Blameless culture was built to protect people who might lie out of fear. Now it has to protect someone else: the person assigned to supervise a system, handed an interface that never actually gave them the means to do it. Call that gap a discipline failure — "you should have reviewed more carefully" — and you hand the fix to the wrong person, which guarantees the same incident again next sprint. Call it a design failure, and the fix lands where it belongs: with the manager who owns the approval gate, the review-time budget, and what the tool is required to show before anyone gets to click approve.

Extend your knowledge

• ▹Pull your last three agent-approved merges that caused an incident and try filling in a comprehension-checkpoint section after the fact — see how often the honest answer is "the diff was technically visible but nobody could review it in the time given."
• ▹Read Google's SRE postmortem chapter and Etsy's 2012 blameless postmortem writeup side by side. Notice both assume the actor being reasoned about is a human capable of fear-driven concealment — that's the seam this lesson is pulling on.
• ▹Audit your current merge/approval tooling — Claude Code review flows, GitHub Copilot Workspace, your own agent-merge bot — for what it actually forces a human to see before the approve action even lights up: diff size limits, mandatory staging runs, agent-confidence flags.
• ▹Draft the comprehension-checkpoint section for your team's postmortem template now, before the next agent-approved incident, so you're not writing it for the first time with a pager still buzzing.