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, parametros, retry, alucinacion, timeout, validacion o en una accion externa que parecio exitosa pero no lo fue.
Si no hay metodo de investigacion, 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 taxonomia de fallos propia y una linea temporal que conecte intencion, contexto, decision, herramienta y efecto.
El objetivo no es culpar al modelo. Es encontrar que capa fallo y que control faltaba.
Framework
Un incidente agentico debe reconstruirse en siete capas:
- Intent: que tarea recibio el agente.
- Context: que informacion recupero o no recupero.
- Policy: que reglas y permisos aplicaban.
- Plan: que ruta eligio.
- 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 aprobacion humana, herramienta sin validacion o verificacion ausente. Sin timeline, el equipo discute opiniones. Con timeline, corrige sistema.
Senal medible: porcentaje de incidentes agenticos 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 metricas relacionadas con modelos, agentes y herramientas. OpenAI recomienda salvaguardas por capas y validacion de outputs en agentes. MCP documenta amenazas como tool poisoning, confused deputy y riesgos de autorizacion.
La infraestructura existe para empezar. Lo que falta en muchas empresas es la practica: runbooks, etiquetas, owners y retroalimentacion hacia evaluaciones.
Anti-ejemplo
“El modelo se equivoco.”
Es una explicacion perezosa. Puede ser cierta, pero no es accionable. Un incidente serio debe decir donde se rompio la cadena: contexto, instruccion, herramienta, permiso, verificacion o supervision.
Protocolo (3 pasos)
- Crea una taxonomia de fallos. Modelo, contexto, herramienta, permiso, integracion, criterio, supervision, verificacion.
- 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 | Accion correctiva |
|---|---|---|
| contexto | que sabia | mejorar retrieval |
| herramienta | que invoco | validar argumentos |
| permiso | que podia 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 produccion
- Agent Reliability Score: como saber si un agente merece autonomia
Fuentes consultadas
- OpenTelemetry: Semantic conventions for generative AI systems
- OpenAI: A practical guide to building agents
- MCP Security Best Practices
Proximo paso
Reabre el ultimo fallo de IA que tuviste. No lo clasifiques como “alucinacion” hasta mapear intent, contexto, policy, tool, outcome y verificacion.