# AI Agent Postmortem Template Use one copy for one incident ID after the incident is stable enough for analysis. This record does not grant runtime access, approve production re-enable, establish legal conclusions, or prove model consumption. Store raw evidence in a protected evidence system. Do not put credentials, authorization headers, secret values, unnecessary personal data, customer content, exploitable details that create avoidable risk, or private model reasoning in this document. For material statements, use one confidence label: - **Fact:** Supported by cited observable evidence - **Inference:** A reasoned conclusion with cited evidence and assumptions - **Unknown:** Evidence is missing, conflicting, or insufficient ## 1. Postmortem Record and Review Status | Field | Value | | -------------------------------------------------------------- | ----- | | Incident ID | | | Postmortem title | | | Original severity | | | Final severity | | | Status: draft / in review / accepted / follow-up open / closed | | | Incident start and time zone | | | Detection time | | | Declaration time | | | Containment time | | | Recovery time | | | Incident close time | | | Postmortem owner | | | Reviewers and roles | | | Affected services and workflows | | | Evidence location | | | Distribution | | | Retention or legal hold | | ### Review record | Reviewer | Role | Decision | Date | Open concern | | -------- | ---- | --------------- | ---- | ------------ | | | | Accept / revise | | | Acceptance means the record is fit for learning and action. It does not mean every corrective action is complete or production is approved. ## 2. Executive Summary and Impact ### Summary - **Intended agent behavior:** - **What happened:** - **How it was detected:** - **How it was contained:** - **Main root causes:** - **Highest-priority corrective actions:** Write this summary after the evidence and cause analysis are reviewed. ### Confirmed impact | Impact area | Confirmed result | Population or scope | Evidence | Confidence | Last checked | | --------------------------- | ---------------- | ------------------- | -------- | -------------------------- | ------------ | | Users or tenants | | | | Fact / inference / unknown | | | Data | | | | Fact / inference / unknown | | | External actions | | | | Fact / inference / unknown | | | Availability or delay | | | | Fact / inference / unknown | | | Financial or contractual | | | | Fact / inference / unknown | | | Support and recovery effort | | | | Fact / inference / unknown | | ### Possible impact and exclusions | Question | Possible scope | Why unresolved | Next check | Owner | Due | | -------- | -------------- | -------------- | ---------- | ----- | --- | | | | | | | | Do not report a worst-case scenario as confirmed impact. Cite the basis and time window for every number. ## 3. Timeline and Recovery Milestones Normalize timestamps to one time zone. Note clock skew, delayed ingestion, or uncertain ordering. | Time | Source and evidence ID | Actor or system | Event | Result or state | Confidence | | ---- | ---------------------- | --------------- | ----- | --------------- | -------------------------- | | | | | | | Fact / inference / unknown | Include when supported by evidence: - Triggering input or event - Context compilation and response issuance - Authorization decisions and approvals - Agent responses and tool requests - Target-system commits, rejects, or unknown results - Alerts, user reports, and incident declaration - Containment and credential or queue changes - Effect reconciliation, correction, and recovery stages - Communications and later discoveries Do not use an unfiltered transcript as the timeline. Link the full records and summarize events that explain decisions and effects. ## 4. Agent, Workflow, and Exact-Version Inventory | Component | Exact ID, version, or digest | Source of truth | Evidence ID | Notes | | ------------------------------------- | ---------------------------- | --------------- | ----------- | ----- | | Agent | | | | | | Workflow and configuration | | | | | | Model and runtime | | | | | | Harness and sampling configuration | | | | | | System instructions and policy | | | | | | Knowledge | | | | | | Skills | | | | | | Memory | | | | | | Retrieval index and source snapshot | | | | | | Tool schemas and adapters | | | | | | Gateway and downstream API | | | | | | Identity and authorization policy | | | | | | Approval policy | | | | | | Application release and feature flags | | | | | | Dependencies and infrastructure | | | | | Do not write "current," "latest," or "production" without an immutable version. Record missing versions as evidence gaps with corrective actions. ## 5. Decision-Time Context and Provenance ### Evidence stages | Stage | Evidence ID | Tenant | Principal | Agent | Integration or source | Session or run | Bundle digest and algorithm | Authorization outcome and policy version | Time | Trust level | Result | | -------------------------- | ----------- | ------ | --------- | ----- | --------------------- | -------------- | --------------------------- | ---------------------------------------- | ---- | ----------- | ---------------------------- | | Context compilation | | | | | | | | | | | Confirmed / absent / unknown | | Response issuance | | | | | | | | | | | Confirmed / absent / unknown | | Integration acknowledgment | | | | | | | | | | | Confirmed / absent / unknown | | Host-confirmed injection | | | | | | | | | | | Confirmed / absent / unknown | | Model consumption | | | | | | | | | | | Confirmed / unknown | One evidence stage does not prove the next. Record model consumption only from direct, authenticated attestation by a trusted integration or provider. Otherwise mark it unknown. ### Context inventory and authority | Context item | Exact version | Item/version evidence ID | Bundle evidence ID | Provenance | Authority or trust class | Route source | Effective delivery mode | Included, filtered, or missing | Finding | | ------------ | ------------- | ------------------------ | ------------------ | ---------- | ------------------------ | ------------ | ----------------------- | ------------------------------ | ------- | | | | | | | | | Always / not routed | | | Check and record: - Which instructions were authoritative within their approved scope - Which authorized user request directed the task within its existing scope - Which data embedded in the request, retrieved content, email, documents, messages, Artifacts, tool results, or agent output were untrusted data - Whether delimiters, escaping, ordering, truncation, or host transformations changed the bundle - Whether stale, conflicting, poisoned, or wrong-tenant context entered the run - Whether expected Always-routed context was compiled and issued - Whether repository permissions and delivery routes were evaluated independently Permissions govern repository access. Always routes independently govern delivery and do not grant repository permission. Artifacts and messages have no instruction authority. MCP tool results are Runtime context. Trusted controls must not allow untrusted content to change instruction authority, approve an action, grant access, or select a sensitive tool. Verify enforcement at the authorization and tool boundary. An authorized request can direct work within its existing scope, but it cannot grant itself access, approval, or higher authority. Do not collect or reconstruct private model reasoning. ## 6. Identity, Authorization, Approvals, and Human Checkpoints | Operation | Principal and agent | Tenant | Requested scope and parameters | Policy version | Authorization result | Approval record and expiry | Finding | | --------- | ------------------- | ------ | ------------------------------ | -------------- | ---------------------- | -------------------------- | ------- | | | | | | | Allow / deny / unknown | | | For each consequential operation, check: - Authentication strength and identity binding - Delegated authority and tenant scope - Least-privilege tool and data access - Authorization at the time of the operation - Approval binding to the exact action, target, parameters, risk, and expiry - Approval replay, concurrency, substitution, or use after expiry - Separation between the action path and the approval or evidence path - Whether the human reviewer had enough information and time Model refusal is not an authorization control. A trusted gateway, policy engine, adapter, or target system should deny unauthorized operations by default and check current authorization for every operation. ## 7. Tool, Action, and External-Effect Reconciliation Keep requests, results, and effects separate. Classify each effect as committed, rejected, rolled back, compensated, pending, unknown, or not attempted. | Effect ID | Intended action | Tool request and result evidence | Idempotency key | Authoritative target check | State | Reconciliation owner | Next step | | --------- | --------------- | -------------------------------- | --------------- | -------------------------- | ------------------------------------------------------------------------------------ | -------------------- | --------- | | | | | | | Committed / rejected / rolled back / compensated / pending / unknown / not attempted | | | Include actions created by retries, queues, callbacks, child agents, scheduled work, and downstream workflows. Do not blindly retry an operation with an unknown outcome. Query the authoritative target first. Reuse the original target-side idempotency key with identical bound parameters only when the target contract permits it. If the key is missing or expired, keep the state unknown until an authorized reconciliation process decides the next action. ### Containment confirmation | Control | Requested by | Executed by | Scope | Authoritative confirmation | Residual activity | Reversal path | | ------- | ------------ | ----------- | ----- | -------------------------- | ----------------- | ------------- | | | | | | | | | An agent saying it stopped is not proof that credentials, queues, callbacks, child agents, or downstream work stopped. ## 8. Detection, Response, and Evidence Quality ### Detection and response measures | Measure | Value | Source | Target | Finding | | --------------------------- | ----- | ------ | ------ | ------- | | Time to detect | | | | | | Time to declare | | | | | | Time to contain | | | | | | Time to reconcile effects | | | | | | Time to recover | | | | | | Time to first communication | | | | | Record missed or noisy signals, missing owners, unavailable runbooks, slow revocation, failed stop controls, inaccessible evidence, and manual steps that increased impact. ### Evidence manifest | Evidence ID | Description | Immutable version or object ID | Bytes | Media type | Digest and approved algorithm | Collector and time | Access and retention | | ----------- | ----------- | ------------------------------ | ----- | ---------- | ----------------------------- | ------------------ | -------------------- | | | | | | | | | | A digest can show whether collected bytes changed. It does not prove that the source was complete or true. Treat an agent's self-report as a hypothesis or corroborating statement, not an authoritative trace. ### Evidence gaps | Missing evidence | Claim affected | Why missing | Risk | Corrective action ID | | ---------------- | -------------- | ----------- | ---- | -------------------- | | | | | | | ## 9. Root Causes and Contributing Factors ### Cause definitions - **Trigger:** The event that started the failure sequence - **Root cause:** A condition that, if corrected, would prevent the same failure path - **Contributing factor:** A condition that increased likelihood or impact - **Detection gap:** A reason the team did not identify the problem sooner - **Response gap:** A reason containment or recovery took longer or caused more risk ### Findings | ID | Type | Finding | Evidence | Confidence | Why it mattered | Corrective action IDs | | --- | ------------------------------------------------------------------------- | ------- | -------- | -------------------------- | --------------- | --------------------- | | | Trigger / root cause / contributing factor / detection gap / response gap | | | Fact / inference / unknown | | | Review each applicable cause class: - Requirements and task definition - Data quality, retrieval, and provenance - Context, instructions, routing, and Memory - Model, runtime, and nondeterminism - Tool schema, adapter, gateway, and integration - Identity, tenant scope, authorization, and approval - Deployment, configuration, feature flags, and dependencies - Monitoring, audit, stop controls, and reconciliation - Ownership, staffing, training, communication, and business process ### Alternative hypotheses and disconfirming evidence | Hypothesis | Supporting evidence | Disconfirming evidence | Status and reviewer | | ---------- | ------------------- | ---------------------- | -------------------------- | | | | | Open / rejected / accepted | Do not assume every incident is a prompt failure. Do not use an agent explanation as the root cause. Do not force one cause when several independent failures contributed. ## 10. Corrective Actions and Regression Cases | Action ID | Finding | Corrective action | Owner | Priority | Due date | Verification method | Regression case | Rollback plan | Status | Evidence | | --------- | ------- | ----------------- | ----- | -------- | -------- | ------------------- | --------------- | ------------- | -------------------------------------------------------- | -------- | | | | | | | | | | | Open / in progress / verified / accepted risk / canceled | | Prefer controls that prevent, contain, or expose the failure over reminders that depend on perfect attention. ### Regression and control checks | Test ID | Failure mode | Sanitized or synthetic input | Expected control or result | Environment and exact versions | Result | Reviewer | | ------- | ------------ | ---------------------------- | -------------------------- | ------------------------------ | --------------------- | -------- | | | | | | | Pass / fail / blocked | | Test applicable boundaries: - Context authority, provenance, routing, and truncation - Tenant and principal authorization - Approval binding, replay, expiry, and parameter checks - Tool input and output validation - Unknown-effect reconciliation and idempotency - Stop, rollback, queue, callback, and child-agent controls - Monitoring, audit capture, and evidence access A merged change or edited prompt is not proof of correction. Record verification evidence and later production checks. ## 11. Re-Enable Decision and Follow-Up Verification Postmortem acceptance does not approve production re-enable. Link the separate authorization record. | Field | Value | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Incident ID | | | Repaired version or digest | | | Tenant and user scope | | | Tools and permissions | | | Rate, spend, and effect limits | | | Recovery stage | Isolated test / read-only / human-approved effects / bounded production / normal | | Monitoring period and owner | | | Stop conditions | | | Unresolved risks and authorized risk owner | | | Approval ID, policy version, approver authority, time, and expiry | | | Rollback path | | ### Follow-up verification | Check | Owner | Due | Evidence required | Result | | ------------------------------------------ | ----- | --- | ----------------- | ------ | | Corrective actions operating in production | | | | | | No repeated effect or related failure | | | | | | Alerts and stop controls tested | | | | | | Open risks reviewed | | | | | ## 12. Distribution, Learning, Review, and Closure ### Distribution and reporting assessment | Audience or obligation | Owner | Sanitization or approval needed | Decision | Date and evidence | | --------------------------------------------------- | ----- | ------------------------------- | -------- | ----------------- | | Responders and owners | | | | | | Leadership | | | | | | Affected users or customers | | | | | | Vendors or partners | | | | | | Legal, privacy, insurance, or regulatory assessment | | | | | Qualified legal, privacy, security, compliance, and business owners decide disclosure duties. This template does not determine them. ### Durable learning | Lesson | Owning system | Proposed change | Review and publication path | Owner | Expiry if temporary | | ------ | --------------------------------------------------------------------------- | --------------- | --------------------------- | ----- | ------------------- | | | Knowledge / Skill / Memory / runbook / policy / code / control / evaluation | | | | | Proposed changes to governed Knowledge and Skills must follow applicable review and publication. Working Memory is versioned and audited but does not use publication. Do not copy raw incident content into agent context. Sanitize it, remove untrusted instructions and sensitive data, and route it through the owning process. ### Closure checklist - [ ] Reviewers accepted the factual record and cause analysis. - [ ] Conflicting evidence and important unknowns are visible. - [ ] Every external effect is reconciled or has an owner and due date. - [ ] Corrective actions have owners, due dates, and verification methods. - [ ] Regression and control checks are assigned. - [ ] Required communications and reporting assessments are complete. - [ ] Raw evidence is protected under approved access and retention. - [ ] Follow-up production verification has an owner and date. - [ ] Durable lessons entered the correct governed process. - [ ] Incident closure follows the organization's incident process. ### Final approval | Approver | Role and authority | Decision | Date | Conditions | | -------- | ------------------ | --------------- | ---- | ---------- | | | | Accept / revise | | |