Agent Incident Retros: How to Run a Postmortem When an LLM Made the Mistake

Why Standard Postmortems Fall Short

A traditional incident postmortem assumes the system is deterministic enough that you can identify the bug, fix it, and prevent recurrence. LLM-driven agents are not deterministic in that way. The same input on the same day produces different responses; "the LLM hallucinated" is not a fix.

The 2026 incident retro template adapts. This piece walks through the new sections and the patterns that work.

The Updated Retro Template

flowchart TB
    R[Retro Template] --> S1[1. Timeline]
    R --> S2[2. Impact]
    R --> S3[3. Trigger]
    R --> S4[4. LLM behavior analysis]
    R --> S5[5. System contribution]
    R --> S6[6. Detection delay]
    R --> S7[7. Action items]

Two sections are new or much-changed: LLM behavior analysis and system contribution.

LLM Behavior Analysis

When the LLM was the proximate cause, what specifically did it do? Three categories:

• Hallucination: the model generated information not present in the input or memory
• Misinterpretation: the model misread the input or instruction
• Tool misuse: the model called the wrong tool or the right tool with wrong arguments
• Refusal failure: the model failed to refuse a request that should have been refused
• Safety violation: the model generated content violating safety policies

For each, the retro asks: was this rare, or is it a class of failure we can characterize?

System Contribution

LLM-only retros miss that the system around the LLM almost always contributed. Sections:

• Context engineering: was the LLM given the right context to succeed?
• Tool design: did the tool surface make a wrong call easy to make?
• Guardrails: did the input or output guards catch this? Should they have?
• Eval coverage: did our eval suite test for this case? Why didn't it catch the regression?
• Monitoring: how long did it take to detect? Why?
• Permission scope: if the agent had less authority, would the impact be smaller?

The system contribution is usually the leverage point for action items. Fixing the LLM is hard; fixing the system around it is tractable.

A Sample Incident Walkthrough

A 2026 example: a customer-support voice agent told a caller their credit card had been refunded when in fact the refund had not been processed.

sequenceDiagram
    participant Caller
    participant Agent
    participant Refund as Refund Tool
    participant DB
    Caller->>Agent: refund my charge
    Agent->>Refund: refund(charge_id)
    Refund->>DB: insert pending refund
    Refund-->>Agent: status: pending
    Agent->>Caller: "Your refund has been processed"

LLM behavior: misinterpreted "pending" as "completed."

System contribution: the tool returned a status string the LLM had to interpret. The system did not enforce that the LLM's response match the tool's actual status.

Action items: change the tool to return structured status that the LLM cannot misread; add an eval case for this; add an output guard that flags responses claiming completion when status is pending.

The fix is structural, not LLM-tuning.

Action Item Categories

A 2026 retro typically produces actions in four categories:

• Eval: add test cases for the failure pattern
• Tooling: change tool surfaces to prevent misuse
• Guardrails: add input or output checks
• Process: change escalation, monitoring, or human review

Action items that are pure "improve the prompt" are usually inadequate. Prompts drift; structural fixes do not.

Severity Classification

The 2026 standard severity scale:

• Sev 1: customer-impacting, regulatory or financial, requires same-day response
• Sev 2: customer-impacting, contained, requires next-day response
• Sev 3: minor or contained, fixable in normal cycle
• Sev 4: near-miss; no customer impact, but worth analyzing

Most teams underuse Sev 4. Near-misses are the cheapest learning.

Retro Cadence

For mid-sized agent fleets:

• Sev 1 / 2: written retro within 5 business days; 30-min review meeting; action items tracked
• Sev 3: lightweight retro; tracked in tickets
• Sev 4: catalogued in a "near-miss log" that the operational governance committee reviews monthly

Patterns That Repeat

After running this template across CallSphere's six agent products, the patterns that repeat:

• Tool-output schemas that allow ambiguous interpretation
• System prompts that conflict with tool semantics
• Guardrails that catch the obvious cases but miss subtle variations
• Eval suites that under-test edge cases
• Permissions that are broader than needed

The remediations are durable; many tunings are not.

Communicating Retros

Internally, retros should be widely shared. Externally, customers care about Sev 1 and 2 events; transparency about how you handled the incident builds trust.

The 2026 best practice for external communication: a public-facing incident page with timeline, impact, root cause summary (without revealing exploitable details), and remediation summary. Many enterprise customers now expect this in their vendor SLA.

Sources

• Google SRE postmortem culture — https://sre.google/sre-book/postmortem-culture
• "Blameless postmortems" Etsy — https://www.etsy.com
• "AI incident reporting" NIST — https://www.nist.gov/aisi
• "Postmortems for AI agents" Hamel Husain — https://hamel.dev
• OECD AI Incidents Monitor — https://oecd.ai/en/incidents