INCIDENT RESPONSE FOR AGENTS

BLAMELESS POSTMORTEMS A postmortem is a written review of an incident done after it is resolved. A blameless postmortem is a learning review without finger-pointing. Blameless does not mean there is no accountability or that facts are hidden. It means that the analysis assumes people acted reasonably with the information they had, and it asks what about the system allowed the failure to occur. This matters because blame teaches people to hide mistakes. If engineers fear punishment, they will stay quiet about near-misses, and the organization loses the information it needs to prevent future problems. When the focus is on the system, people share openly, and real fixes follow. For example, instead of writing "Alex deployed a bad prompt," a blameless review writes "The release process allowed a prompt change to reach production without running the evaluation suite." The first sentence leads to punishing Alex, and the second leads to fixing the process, which protects against every future Alex. A good postmortem has the following sections. Summary: a short plain description of what happened. Timeline: key events with times, from first sign to resolution. Root cause: the underlying reason the incident happened, found by repeatedly asking why. A technique called the five whys asks "why" again and again until reaching a systemic cause. Impact: who and what was affected, for how long, with numbers where possible. Contributing factors: conditions that made the incident possible or worse, such as missing alerts or unclear ownership. What went well: things that helped, such as the speed of the alert. Action items: specific improvements, each with an owner and a due date.