Problema
Un agente falla y el postmortem empieza con una pregunta incomoda: que hizo exactamente.
La respuesta rara vez cabe en un log de prompt y output. El fallo puede estar en retrieval, permisos, tool selection, parámetros, retry, alucinación, timeout, validación o en una acción externa que parecio exitosa pero no lo fue.
Si no hay método de investigación, cada incidente se convierte en arqueologia.
Tesis
Agent Incident Response debe convertirse en disciplina operativa.
No basta con tener observabilidad generica. Los agentes necesitan una taxonomía de fallos propia y una línea temporal que conecte intención, contexto, decisión, herramienta y efecto.
El objetivo no es culpar al modelo. Es encontrar que capa fallo y que control faltaba.
Framework
Un incidente agéntico debe reconstruirse en siete capas:
- Intent: que tarea recibió el agente.
- Context: que información recupero o no recupero.
- Policy: que reglas y permisos aplicaban.
- Plan: que ruta eligió.
- Tools: que llamadas hizo y con que argumentos.
- Outcome: que cambio en el sistema externo.
- Verification: como se comprobo el resultado.
Mini-caso: un agente envia un email incorrecto a un cliente. El problema puede ser prompt, CRM desactualizado, plantilla equivocada, falta de aprobación humana, herramienta sin validación o verificación ausente. Sin timeline, el equipo discute opiniones. Con timeline, corrige sistema.
Señal medible: porcentaje de incidentes agénticos con causa raiz asignada a una capa concreta.
Postura: no automatices lo que no puedes investigar.
Por que importa ahora
OpenTelemetry ya define convenciones para sistemas GenAI, incluyendo spans, eventos, excepciones y métricas relacionadas con modelos, agentes y herramientas. OpenAI recomienda salvaguardas por capas y validación de outputs en agentes. MCP documenta amenazas como tool poisoning, confused deputy y riesgos de autorización.
La infraestructura existe para empezar. Lo que falta en muchas empresas es la práctica: runbooks, etiquetas, owners y retroalimentación hacia evaluaciones.
Anti-ejemplo
“El modelo se equivoco.”
Es una explicación perezosa. Puede ser cierta, pero no es accionable. Un incidente serio debe decir donde se rompio la cadena: contexto, instrucción, herramienta, permiso, verificación o supervisión.
Protocolo (3 pasos)
- Crea una taxonomía de fallos. Modelo, contexto, herramienta, permiso, integración, criterio, supervisión, verificación.
- Exige timeline. Cada incidente debe tener secuencia de eventos y tool calls.
- Convierte causas en evals. Cada fallo importante debe acabar como caso de prueba permanente.
| Capa | Pregunta | Acción correctiva |
|---|---|---|
| contexto | que sabia | mejorar retrieval |
| herramienta | que invoco | validar argumentos |
| permiso | que podía hacer | reducir scope |
| outcome | que cambio | verificar estado |
| eval | volveria a pasar | crear test |
Relacionado
- AI Traces: la capa que convierte agentes en sistemas auditables
- Output Verification Layer: el seguro invisible de los agentes en producción
- Agent Reliability Score: como saber si un agente merece autonomía
Fuentes consultadas
- OpenTelemetry: Semantic conventions for generative AI systems
- OpenAI: A practical guide to building agents
- MCP Security Best Practices
Próximo paso
Reabre el último fallo de IA que tuviste. No lo clasifiques como “alucinación” hasta mapear intent, contexto, policy, tool, outcome y verificación.