El agente devuelve un 200, pasa los evals y el cliente recibe la respuesta equivocada
La observabilidad no cubre el fallo silencioso de los agentes de IA: respuestas verosímiles, trazas incompletas y un hueco que el CI no ve
Un diff no es una prueba, es una declaración de intenciones. El CI pasó, la revisión también, el cambio está en producción y entonces alguien avisa de que la aplicación va lenta o de que las respuestas están mal. En un servicio determinista eso se localiza. En un agente de IA, no.
El informe State of SRE and Platform Engineering 2026 de Dynatrace, con 919 responsables empresariales encuestados, apunta al hueco: el 77% de los equipos de platform engineering mete observabilidad en algunos servicios, pero solo el 40% la tiene integrada del todo en todos los despliegues. Con servicios deterministas ese margen se aguanta. Con agentes, se convierte en un problema.
Un fallo que devuelve 200
Un servicio convencional falla a gritos: un 500, un pico de latencia, una dependencia que deja de responder. Un agente falla en silencio. Devuelve un 200, supera las comprobaciones de fidelidad y el cliente recibe igualmente la respuesta equivocada. Sobre "mal" no se puede alertar.
El ejemplo que ilustra el problema: un agente de soporte sobre documentación de producto. Un cliente pregunta cómo configurar la exportación en la versión 2026.3. El asistente de código ayudó a reescribir la búsqueda de documentación, el CI pasó y los evals existentes también. Tras el despliegue, las respuestas tardan más y algunas describen versiones antiguas.
En la traza se ve la pista: tres búsquedas idénticas con product_version: null, que devuelven documentos de 2024.1 y 2023.9, y una generación de 8,1 segundos. Las respuestas son fieles a las fuentes recuperadas; la métrica de fidelidad pasa. Lo que falla es otra cosa.
Las tres búsquedas repetidas cuestan 2,6 segundos, pero entre la segunda y la tercera no hay ninguna llamada al modelo. Si el span model.choose_tool apareciera entre cada búsqueda, el problema estaría en el prompt o en la descripción de la herramienta. Al no estar, el reintento lo hace el harness, no el modelo: mismo síntoma, fichero distinto que abrir. Y si el harness pegó los tres conjuntos de resultados al contexto, el prompt creció y esos reintentos se pagaron dos veces, en latencia y en tokens.
Para eso sirve un trace distribuido: release, configuración de recuperación y estado de los feature flags como atributos fijados al arrancar el span raíz, no reconstruidos después desde un log de despliegue, y la trayectoria completa de llamadas a modelo y a herramientas, en orden, con argumentos y resultados.
Relevancia no es validez
Añadir un evaluador de recuperación tampoco lo caza. Esos miden si el contexto recuperado es relevante para la consulta, y las instrucciones de exportación de 2024.1 son relevantes para "configurar la exportación". Simplemente no valen para la versión que se preguntó. La fidelidad solo dice si la respuesta está sostenida por las fuentes que le diste; no dice si esas fuentes eran las correctas.
No es un fallo de generación, es una precondición de recuperación que nadie verificó, y el filtro a null la delata: la versión pedida nunca llegó a la búsqueda. Buena parte de esto se prueba con código corriente, con fixtures que lleven metadatos de versión y una aserción directa sobre el lookup, sin modelo en medio. Antes de tocar el prompt, reproduce eso.
El resto del contexto lo pone el informe de Dynatrace: la observabilidad se despliega a parches y los agentes son justo lo que no perdona un parche. Mientras la telemetría siga midiendo disponibilidad y latencia, los fallos que devuelven 200 seguirán llegando al cliente antes que al equipo de guardia.
