Postmortems Are About to Get a Non-Human Defendant

I keep running into the same gap in incident reviews, and it’s not one anyone’s named cleanly yet. Most engineering organizations that take reliability seriously run some version of a blameless postmortem after a significant incident: No punishment for whoever pushed the change, no name singled out in the write-up. It’s close to uncontroversial at this point, and for good reason. Blameless postmortems work because of a specific psychological mechanism. A person who fears blame will shade their account to protect themselves, and removing that threat produces a more complete picture of how a failure occurred. As platform teams adopt tiered autonomy for coding agents, auto-merging low-risk changes while routing higher-risk ones to human review (the current, sound consensus, not “agents run wild”), that mechanism is starting to fail in a specific, narrower way, and most incident-review processes have no answer for it yet.

This isn’t a bottleneck waiting for adoption to catch up. Tiered autonomy is exactly what lets a team say yes to agent-driven speed without saying yes to agent-driven risk, which is why it’s spreading through teams that would never grant an agent unrestricted production access. The volume moving through the low-risk, auto-merged lane only grows as agents take on more mechanical work, and postmortem practice hasn’t caught up with the one question that matters when something in that lane is misclassified: who decided it belonged there.

A platform team’s auto-merge policy treats schema migrations tagged “additive-only” as safe to merge without review, since additive changes rarely break existing consumers.

This is a reasonable, common policy, and I don’t think anyone would flag it in a design review. An agent handling a routine migration conflict resolves a type mismatch by widening a nullable column, an operation the policy correctly classifies as additive. Four days later, a downstream reconciliation job assuming a strict null constraint starts silently misprocessing a batch of invoices.

The postmortem writes itself the easy way: Root cause: The agent’s migration broke an undocumented downstream assumption. Action item: Add a dependency check before auto-merging schema changes. Case closed.

Except somebody wrote “additive-only” into that policy and decided it meant “safe,” and that person has the same reason to shade the story as anyone whose specific decision gets examined in a postmortem. Naming the classification in the abstract, the same way naming the agent does, lets the conversation stop one level above the person who’d actually have to explain why “additive” and “safe” got treated as the same word for this table. The fix addresses this specific migration pattern. It does nothing about the next classification with the same blind spot, because the person who owns that blind spot was never in the room as a suspect.

This is where the agent’s role actually earns the “non-human defendant” framing, rather than being interchangeable with any automated script. A hard-coded rule engine executes

a classification: the code either matches “additive-only” or it doesn’t, and you can read the rule to see exactly what it does. An agent resolving a migration conflict has to judge whether its own fix qualifies as additive, which is an inference about its own action, not a lookup. That’s a second place for the same blind spot to hide, layered on top of the first. The classification can be wrong, and separately, the agent’s judgment that its action fits that classification can be wrong, and a postmortem reviewing only the classification will still miss half of what happened.

The fix isn’t a blame framework for agents, and I want to be clear I’m not proposing one. It’s a mandatory postmortem section, for any incident where an agent’s action was auto-merged under a risk classification, that puts a name on who owns that classification, not just what it says. In the example above, “additive-only” was correct as a schema-level description and wrong as a safety judgment, because it never accounted for downstream consumers with stricter assumptions than the schema enforces. That gap is a decision someone made when the policy was written, reviewable by name, not an abstract property of the policy itself.

Concretely, this section should require three answers, not one. First, who owns this risk classification, and when was it last reviewed against the systems that currently depend on the changed component? Second, was the classification written against the schema in isolation, or against the full blast radius including consumers that don’t appear in the schema itself? Third, how many other classifications share this same blind spot, since one that missed a downstream dependency was likely written without a process for discovering dependencies at all.

This maps onto a practice most platform teams already run for access control: periodic entitlement review. Nobody assumes a permission granted two years ago is still correctly scoped without checking. Risk classifications for auto-merge policies accumulate the same staleness, usually faster, since downstream systems change more often than the policy describing what’s safe to touch does. A quarterly audit of what each classification actually covers, cross-referenced against current dependencies, would have caught the billing gap before an agent, correctly following the policy as written, found it for you.

Blameless culture was never really about sparing feelings. It was a mechanism for making sure a postmortem couldn’t stop at a name when the real answer was a specific person’s decision. Naming an agent, or naming a policy in the abstract, hits that same stopping point without anyone noticing, because neither has a reason to push back. The postmortem that stops there hasn’t found a blameless explanation. It’s found the first available stopping point, one name short of the person who deserved the scrutiny.