01What it isQué es
Agent incident response is the rehearsed protocol to detect that an agent is deciding badly, pause it and switch to a manual backup, find the root cause and bring it back under closer watch.
La respuesta a incidentes de agentes es el protocolo ensayado para detectar que un agente está decidiendo mal, pausarlo y pasar a un respaldo manual, encontrar la causa raíz y reactivarlo bajo una vigilancia más estrecha.
02Why it mattersPor qué importa
Agent failures are often silent: the agent keeps running while a changed input, such as a new supplier status code, makes every decision slightly wrong. Automation erodes the manual skills that operators need precisely when the automated system fails (Bainbridge, 1983 — Automatica), which is why the backup process must be documented and practiced. Mature incident handling follows preparation, detection and analysis, containment and recovery, and post-incident learning (Cichonski, Millar, Grance and Scarfone, 2012 — NIST SP 800-61 Rev. 2).
Las fallas de los agentes suelen ser silenciosas: el agente sigue operando mientras un insumo que cambió, como un nuevo código de estatus del proveedor, vuelve cada decisión ligeramente incorrecta. La automatización erosiona las habilidades manuales que los operadores necesitan justo cuando el sistema automatizado falla (Bainbridge, 1983 — Automatica), y por eso el proceso de respaldo debe documentarse y practicarse. La gestión madura de incidentes sigue las fases de preparación, detección y análisis, contención y recuperación, y aprendizaje posterior al incidente (Cichonski, Millar, Grance and Scarfone, 2012 — NIST SP 800-61 Rev. 2).
03How it is doneCómo se hace
1
Monitor agent-specific signals. Alert on override rate, duplicate actions and decisions outside the historical pattern, not only on OTIF.
2
Pause, never delete. Stop the agent with one action and switch to a manual backup the team has rehearsed in the last quarter.
3
Turn root cause into design. Classify the failure — in the Mr. Supply Chain AVC framework, as Autonomy, Veracity or Coordination — and fix the design, not just the case.
1
Monitorea señales del agente. Alerta por tasa de override, acciones duplicadas y decisiones fuera del patrón histórico, no solo por OTIF.
2
Pausa, nunca elimines. Detén el agente con una sola acción y pasa a un respaldo manual que el equipo haya ensayado en el último trimestre.
3
Convierte la causa en diseño. Clasifica la falla —en el marco AVC de Mr. Supply Chain, como de Autonomía, Veracidad o Coordinación— y corrige el diseño, no solo el caso.
04The concept in depthEl concepto a fondo
Agent incident response: how to respond when the agent fails›
AI agent incident response is the structured protocol defining how the team detects that an agent is failing, contains the impact before it propagates, and recovers the system to normal operation. Unlike traditional IT incidents, AI agent incidents can be silent — the agent operates but takes systematically incorrect decisions.
The agent incident response protocol: 4 phases›
(1) Detection: automated monitoring detects the anomaly — override rate exceeds threshold, conflict rate increases, or audit trail shows decisions outside historical pattern. Detection speed is the highest-impact variable on damage containment. (2) Containment: the agent is paused (not deleted) and the manual backup process is activated. Manual backup documentation is the prerequisite of effective containment. (3) Root cause analysis: team identifies root cause under the AVC framework (Veracity, Coordination, or Autonomy failure) and designs corrective action. (4) Recovery: agent is corrected, re-validated with standard evaluation protocol (red-teaming + shadow mode), and reactivated with intensified monitoring for the first 2 weeks.
The agent runbook: the operations and incident response manual›
The agent runbook describes: how it operates normally, how to detect anomalous behavior, how to emergency-pause the agent, how to activate the manual backup process, and how to escalate the incident to the correct team. Without the runbook, incident response depends on individual team memory — which may not be available when the incident occurs.
Intermediate vs. Advanced›
Intermediate: follows the agent runbook for detection and containment; escalates incidents to the design team.
Advanced: designs the incident response protocol for the agent portfolio; leads root cause analysis under the AVC framework; manages the recovery and reactivation process.
Advanced: designs the incident response protocol for the agent portfolio; leads root cause analysis under the AVC framework; manages the recovery and reactivation process.
Respuesta a incidentes de agentes: cómo responder cuando el agente falla›
La respuesta a incidentes de agentes de IA es el protocolo estructurado que define cómo el equipo detecta que un agente está fallando, contiene el impacto antes de que se propague y recupera el sistema a su operación normal. A diferencia de los incidentes de TI tradicionales, los incidentes de agentes de IA pueden ser silenciosos: el agente opera, pero toma decisiones sistemáticamente incorrectas.
El protocolo de respuesta a incidentes del agente: 4 fases›
(1) Detección: el monitoreo automático detecta la anomalía: la tasa de override supera el umbral, aumenta la tasa de conflictos o la pista de auditoría muestra decisiones fuera del patrón histórico. La velocidad de detección es la variable de mayor impacto en la contención del daño. (2) Contención: el agente se pausa (no se elimina) y se activa el proceso manual de respaldo. La documentación del respaldo manual es el prerrequisito de una contención efectiva. (3) Análisis de causa raíz: el equipo identifica la causa raíz bajo el marco AVC (falla de Veracidad, Coordinación o Autonomía) y diseña la acción correctiva. (4) Recuperación: el agente se corrige, se revalida con el protocolo de evaluación estándar (red-teaming + modo sombra) y se reactiva con monitoreo intensificado durante las primeras 2 semanas.
El runbook del agente: el manual de operación y respuesta a incidentes›
El runbook del agente describe: cómo opera normalmente, cómo detectar comportamiento anómalo, cómo pausarlo de emergencia, cómo activar el proceso manual de respaldo y cómo escalar el incidente al equipo correcto. Sin el runbook, la respuesta a incidentes depende de la memoria individual del equipo, que puede no estar disponible cuando ocurre el incidente.
Intermedio vs. Avanzado›
Intermedio: sigue el runbook del agente para la detección y la contención; escala los incidentes al equipo de diseño.
Avanzado: diseña el protocolo de respuesta a incidentes para el portafolio de agentes; lidera el análisis de causa raíz bajo el marco AVC; gestiona el proceso de recuperación y reactivación.
Avanzado: diseña el protocolo de respuesta a incidentes para el portafolio de agentes; lidera el análisis de causa raíz bajo el marco AVC; gestiona el proceso de recuperación y reactivación.
05In practiceEn la práctica
The agent manual backup process must be documented and tested before deploying the agent in production›
The backup process only works when the team has practiced it. A backup process that no one has executed in 6 months may fail at the moment of the incident.
The agent runbook must include the specific alert signals of the agent — not just general monitoring metrics›
The override rate rising from 12% to 38% in 3 days is a specific alert signal. The general operations dashboard showing OTIF will not detect this silent failure.
Root cause analysis under the AVC framework converts the incident into a design lesson — it is the most valuable part of incident response›
The post-mortem under the AVC that identifies the root cause as Veracity failure due to Information Incorrectness generates the design lesson to implement the supplier confirmation status verifier.
Share the agent incident post-mortem with all teams that have similar agents in production›
The post-mortem of the reorder agent that failed due to the supplier status change is relevant for all other agents that use ERP status as input for their decisions.
El proceso manual de respaldo del agente debe documentarse y probarse antes de desplegar el agente en producción›
El proceso de respaldo solo funciona cuando el equipo lo ha practicado. Un proceso de respaldo que nadie ha ejecutado en 6 meses puede fallar en el momento del incidente.
El runbook del agente debe incluir las señales de alerta específicas del agente, no solo métricas generales de monitoreo›
Que la tasa de override suba de 12% a 38% en 3 días es una señal de alerta específica. El dashboard general de operaciones que muestra el OTIF no detectará esta falla silenciosa.
El análisis de causa raíz bajo el marco AVC convierte el incidente en una lección de diseño: es la parte más valiosa de la respuesta a incidentes›
El post-mortem bajo el AVC que identifica como causa raíz una falla de Veracidad por información incorrecta genera la lección de diseño para implementar el verificador del estatus de confirmación del proveedor.
Comparte el post-mortem del incidente con todos los equipos que tienen agentes similares en producción›
El post-mortem del agente de reorden que falló por el cambio de estatus del proveedor es relevante para todos los demás agentes que usan el estatus del ERP como insumo de sus decisiones.
06Illustrative caseCaso ilustrativo
Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Illustrative case: Reorder agent incident response — distribution company, silent failure detected in week 3 of operation
The reorder agent begins systematically generating under-dimensioned POs without triggering any obvious failure alert.
The reorder agent begins systematically generating under-dimensioned POs without triggering any obvious failure alert.
| Incident response phase | Time since failure started | Actions taken |
|---|---|---|
| Detection: the automated monitoring detects that the agent override rate rose from 12% to 38% in 3 days | Week 3, Day 2 · The monitoring alert activates when override rate exceeds 25% | The monitoring dashboard alerts the Agent Owner at 8:23am · The Agent Owner confirms the incident and activates the runbook |
| Containment: the agent is paused and the manual backup process is activated | Week 3, Day 2 · 47 minutes after detection | The reorder agent is paused in the ERP · The buyer team activates the manual ROP review process for the 1,800 SKUs · The manual process takes 8 hours vs. 15 minutes for the agent |
| Root cause analysis under the AVC framework | Week 3, Days 3–4 | The AVC analysis identifies a Veracity failure: the primary supplier changed its PO confirmation process — POs now appear in the ERP as in process instead of confirmed · The agent interpreted in process as unconfirmed and generated additional duplicate POs |
Result: Root cause: Veracity failure due to Information Incorrectness. Corrective action: status mapping update in the agent. Recovery time: 4 days. Failure impact: $280K MXN in duplicate POs issued (all cancelled before being sent to the supplier by the buyer override process).
Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Caso ilustrativo: respuesta a incidente del agente de reorden — empresa distribuidora, falla silenciosa detectada en la semana 3 de operación
El agente de reorden empieza a generar sistemáticamente OC subdimensionadas sin disparar ninguna alerta de falla evidente.
El agente de reorden empieza a generar sistemáticamente OC subdimensionadas sin disparar ninguna alerta de falla evidente.
| Fase de respuesta al incidente | Tiempo desde el inicio de la falla | Acciones tomadas |
|---|---|---|
| Detección: el monitoreo automático detecta que la tasa de override del agente subió de 12% a 38% en 3 días | Semana 3, día 2 · La alerta de monitoreo se activa cuando la tasa de override supera 25% | El dashboard de monitoreo alerta al Agent Owner a las 8:23 am · El Agent Owner confirma el incidente y activa el runbook |
| Contención: el agente se pausa y se activa el proceso manual de respaldo | Semana 3, día 2 · 47 minutos después de la detección | El agente de reorden se pausa en el ERP · El equipo de compradores activa el proceso manual de revisión del ROP para los 1,800 SKU · El proceso manual toma 8 horas vs. 15 minutos del agente |
| Análisis de causa raíz bajo el marco AVC | Semana 3, días 3–4 | El análisis AVC identifica una falla de Veracidad: el proveedor principal cambió su proceso de confirmación de OC; ahora las OC aparecen en el ERP como "en proceso" en lugar de "confirmadas" · El agente interpretó "en proceso" como no confirmada y generó OC adicionales duplicadas |
Resultado: Causa raíz: falla de Veracidad por información incorrecta. Acción correctiva: actualización del mapeo de estatus en el agente. Tiempo de recuperación: 4 días. Impacto de la falla: $280K MXN en OC duplicadas emitidas (todas canceladas por el proceso de override de los compradores antes de enviarse al proveedor).
07How it is measuredCómo se mide
Agent Incident Detection Time›
Agent Incident Detection Time
Average time from when the agent starts operating outside normal parameters until the monitoring system generates an alert
Benchmark: <24 hours for critical agents with real-time override rate monitoring
⚠️ An agent that fails for 3 weeks before being detected can generate significant operational or financial damage during that period.
Agent Incident Containment Time›
Agent Incident Containment Time
Time from incident detection until the agent is paused and the manual backup process is operational
Benchmark: <2 hours for critical agents with a documented runbook and pre-defined manual backup process
🔑 Containment speed depends directly on the existence of the runbook and the pre-defined manual backup process.
Agent Incident Detection Time (tiempo de detección de incidentes)›
Agent Incident Detection Time (tiempo de detección de incidentes)
Tiempo promedio desde que el agente empieza a operar fuera de los parámetros normales hasta que el sistema de monitoreo genera una alerta
Benchmark: <24 horas para agentes críticos con monitoreo en tiempo real de la tasa de override
⚠️ Un agente que falla durante 3 semanas antes de ser detectado puede generar un daño operativo o financiero significativo en ese periodo.
Agent Incident Containment Time (tiempo de contención de incidentes)›
Agent Incident Containment Time (tiempo de contención de incidentes)
Tiempo desde la detección del incidente hasta que el agente queda pausado y el proceso manual de respaldo está operando
Benchmark: <2 horas para agentes críticos con runbook documentado y proceso manual de respaldo predefinido
🔑 La velocidad de contención depende directamente de que existan el runbook y el proceso manual de respaldo predefinido.
08What you would useQué se usa
📌 Agent Incident Response
LangSmith / Arize AI›
Module: Agent Monitoring + Anomaly Detection + Incident Alerting
LangSmith and Arize AI for real-time monitoring of agent behavior and automatic alert generation.
LangSmith and Arize AI for real-time monitoring of agent behavior and automatic alert generation.
Runbook Template (ITIL-based for AI Agents)›
Module: Agent Runbook Documentation Standard
ITIL-based runbook template adapted for AI agents — with sections for anomaly detection, containment, manual backup process, root cause analysis, and recovery.
ITIL-based runbook template adapted for AI agents — with sections for anomaly detection, containment, manual backup process, root cause analysis, and recovery.
📌 Respuesta a incidentes de agentes
LangSmith / Arize AI›
Módulo: Monitoreo del agente + detección de anomalías + alertas de incidentes
LangSmith y Arize AI para el monitoreo en tiempo real del comportamiento del agente y la generación automática de alertas.
LangSmith y Arize AI para el monitoreo en tiempo real del comportamiento del agente y la generación automática de alertas.
Runbook Template (ITIL-based for AI Agents)›
Módulo: Estándar de documentación del runbook del agente
Plantilla de runbook basada en ITIL adaptada para agentes de IA, con secciones de detección de anomalías, contención, proceso manual de respaldo, análisis de causa raíz y recuperación.
Plantilla de runbook basada en ITIL adaptada para agentes de IA, con secciones de detección de anomalías, contención, proceso manual de respaldo, análisis de causa raíz y recuperación.
The bottom lineEn corto
Every agent needs an off switch and a manual plan B that people have actually practiced.
Todo agente necesita un botón de apagado y un plan B manual que el equipo realmente haya practicado.
← PreviousAnteriorRegulatory landscape for autonomous supply chain AI: EU AI Act & NIST RMFPanorama regulatorio para IA autónoma en SC: EU AI Act y NISTNextSiguiente →Agent performance KPIs: measuring value, accuracy & safety in productionKPIs de desempeño de agentes: midiendo valor, exactitud y seguridad en producción
All D13 componentsTodos los componentes de D13D13 artifactsArtifacts de D13SCRA