Agent-Caused Incidents: How to Run the Postmortem

When the agent caused the incident, the postmortem template needs new sections. The template, the questions to ask, and the typical contributing factors.

Template additions

Standard postmortem templates miss the agent-specific data the team needs to learn from an agent-caused incident. The four sections below are additive, not replacements for the human-incident template.

• Agent decision history. Full chain of decisions the agent made, with the inputs at each step. Reconstructable from the run log.
• Guardrail review. Which guardrails were active, which fired, which did not but should have. Each entry maps to a specific config knob.
• Prompt and model lineage. Prompt version and model version at the time of the run, plus when each was last changed.
• Eval coverage. Was the scenario in the eval suite? If yes, why did eval pass but production fail? If no, why was it missed?

Questions to ask

Four questions structure the analysis. Each isolates a different layer where the failure could have entered.

• Was the input correct? Garbage in, garbage out is the most common cause; check the data first.
• Was the reasoning correct given the input? Sometimes the inputs were right and the reasoning still went wrong.
• Was the action correct given the reasoning? Sometimes reasoning is right but the action implementation has a bug.
• Why did the guardrails not catch this? The most important question. The other three name layers; this one names the safety net.

Common contributing factors

Five factors recur across agent-caused incidents. Naming them on the standard template speeds the writeup and exposes patterns across runs.

• Stale context. The agent acted on data that was no longer accurate at decision time.
• Tool output mis-interpretation. The agent read the tool output incorrectly. Often a schema change the prompt did not catch up with.
• Eval gap. The scenario was not in the test suite; the agent had never seen anything like it.
• Guardrail mis-configuration plus prompt regression. Guardrail existed but allowed this case; or a recent prompt update changed behaviour the eval set missed.

Action items that actually help

Some action items are theatre; some change the next quarter. The four below carry their weight.

• Add to eval suite. Cheapest, highest-leverage action. The failure case becomes a regression guard for every future change.
• Tighten the specific guardrail. Specific to this failure mode, not a generic “more guardrails” ask.
• Add detection observability. The agent acted for too long without detection; a panel or alert that surfaces the same shape earlier next time.
• Document the pattern. Future agent designs benefit from the lesson; a write-up that survives the team turnover.

Blameless toward the agent

Blameless culture extends to the agent. Blaming the model or the prompt produces no actionable change; blaming the design that admitted the failure does.

• Agents are tools. The blame, if any, is on the design that allowed the failure. The agent is downstream of decisions humans made.
• Reframe the language. Avoid “the agent was wrong.” Prefer “the agent’s design did not handle this case.” Same fact, different action implications.
• Team ownership. The team built the agent. The team owns the failure. The team learns and improves the next iteration.
• Avoid model finger-pointing. “The model hallucinated” without further analysis is a non-answer; the question is why the system permitted the hallucination to act.