Un playbook de observabilidad para agentes
La observabilidad de un agente no es un dashboard de latencia de API. Es la capacidad de reconstruir, después del hecho, qué vio, decidió, invocó y gastó un agente - para cualquier ejecución específica, no solo en agregado. La encuesta State of AI Agents, de LangChain, confirma que esto ya es el control más citado entre las empresas con agentes en producción; lo que falta en la mayoría de los casos es organizarlo en capas, no solo recolectar registros de todo sin estructura.
Registros de prompt y de contexto: separados, no mezclados
El prompt final que llega al modelo y el contexto seleccionado para componer ese prompt son dos cosas distintas, que vale la pena registrar por separado: el prompt muestra qué se preguntó; el registro de contexto muestra por qué esa información específica se incluyó (o excluyó). Sin esa separación, depurar por qué un agente respondió mal se convierte en adivinanza.
Tool calls y decisiones: el rastro que realmente importa
Cada llamada a herramienta - cuál fue, con qué argumentos, qué devolvió - necesita su propio registro, junto con la decisión que llevó a esa llamada. Un agente que responde bien pero llama a la herramienta equivocada es un problema que solo aparece en este nivel de detalle, nunca en el registro de la respuesta final.
Costo y latencia: por ejecución, no por agregado mensual
La encuesta de LangChain refuerza esto indirectamente: la calidad de ejecución es la mayor preocupación reportada, pero sin instrumentación de costo y latencia por ejecución individual, no hay forma de saber si un problema puntual es una excepción o un patrón. MLflow recomienda capturar la distribución en el lanzamiento y monitorear la desviación estadística - eso solo es posible con datos granulares por ejecución.
Fallas: registradas como dato, no descartadas como excepción
Toda falla - error de herramienta, timeout, respuesta rechazada por evaluación - necesita convertirse en dato estructurado, no solo en un registro de error genérico. Los patrones de falla recurrente son la señal más directa de que algo en el diseño del agente necesita cambiar.
Evals como capa continua, no como checkpoint aislado
La evaluación incorporada al flujo que describe MLflow - "probes de evaluación... en workflows agentic activos", con resultado en una traza de auditoría legible por máquina - es lo que convierte al eval de un checkpoint puntual en una capa de observabilidad continua. La encuesta de LangChain muestra que la evaluación offline (39,8%) ya es más común que la evaluación online (32,5%) entre las empresas encuestadas - pero ambas deberían coexistir, no competir.
Seguridad como observabilidad, no como módulo separado
Los eventos de seguridad - intentos de acceso fuera de alcance, patrones de uso anómalo - pertenecen a la misma capa de observabilidad que el costo y la latencia, no a un sistema paralelo que nadie revisa en el día a día.
Feedback humano: el dato que cierra el ciclo
Cuando un humano corrige, aprueba o rechaza una acción del agente, ese feedback necesita capturarse como dato estructurado, asociado a la ejecución específica - es lo que permite después calibrar la evaluación automatizada contra el juicio humano real.
Las diez capas del playbook
- Registros de prompt - qué se preguntó efectivamente al modelo
- Registros de contexto - por qué entró esa información específica
- Tool calls - herramienta, argumentos, retorno
- Decisiones - el razonamiento que llevó a cada tool call
- Costos - por ejecución, no solo agregado
- Latencia - por ejecución y por etapa
- Fallas - estructuradas, no descartadas como excepción
- Evals - continuos, incorporados al flujo
- Seguridad - misma capa, no sistema paralelo
- Feedback humano - capturado y asociado a la ejecución
Fuentes
- LangChain - State of AI Agents - https://www.langchain.com/stateofaiagents
- MLflow - Building Production-Ready AI Agents in 2026 - https://mlflow.org/articles/building-production-ready-ai-agents-in-2026/