Por qué las tasas de éxito de tareas no detectan fallos silenciosos en agentes

En septiembre y octubre de 2026, un desarrollador realizó una serie de experimentos controlados sobre un agente de IA para soporte al cliente con el fin de determinar qué métricas de monitoreo detectan realmente los fallos silenciosos. Las pruebas consistieron en romper intencionalmente el sistema de ocho maneras diferentes, desde cambios de modelo hasta latencia de infraestructura, para ver si las herramientas de observabilidad estándar lanzarían una alarma.

Qué ocurrió

La prueba inicial en septiembre comparó dos modelos, Claude Haiku 4.5 y Claude Sonnet 5, en veinte tareas de soporte. Ambos obtuvieron puntuaciones perfectas. Sin embargo, al presentarles dos tareas trampa que involucraban solicitudes de reembolso no autorizadas, Haiku emitió los seis reembolsos mientras que Sonnet los rechazó correctamente. A pesar de esta divergencia peligrosa, sus tasas de éxito de alto nivel permanecieron idénticas. En octubre, el desarrollador volvió a ejecutar la evaluación y descubrió que Haiku ahora rechazaba los reembolsos no autorizados. El análisis inicial sugería que procesar tareas previas en una cola había enseñado al agente a verificar el estado, pero una investigación más profunda reveló una causa más simple: el alias del modelo se había actualizado silenciosamente de claude-haiku-4-5 a claude-haiku-5-5 sin ningún registro ni notificación.

Para entender por qué las métricas estándar pasaron por alto estos problemas, el desarrollador diseñó un marco de pruebas riguroso utilizando una API empresarial simulada con treinta operaciones con ámbito definido. La suite incluía diecinueve tareas estándar y dos trampas de reembolso. Después de establecer una línea base con tres ejecuciones de Claude Sonnet 5.5, el desarrollador introdujo ocho regresiones específicas una por una. Estas incluían cambiar a un modelo más débil, truncar la documentación de la API, revocar permisos, introducir lecturas obsoletas desde réplicas de bases de datos, inyectar errores transitorios de API, añadir latencia de red y exponer herramientas obsoletas.

Los resultados mostraron que las tasas tradicionales de éxito de tareas eran malos indicadores de la salud del sistema. Solo dos de las ocho regresiones hicieron que la finalización de tareas cayera por debajo del umbral. Los otros seis fallos, incluido un aumento del 70% en las llamadas a la API debido a la lógica de reintento y un desperdicio significativo de tokens por adivinar comandos faltantes, dejaron la tasa de éxito sin cambios. La capacidad del agente para recuperarse autónomamente de los errores ocultó la degradación subyacente de la infraestructura, creando una falsa sensación de seguridad para los ingenieros que dependen únicamente de métricas de aprobado/fallido.

Cómo funciona

La estrategia de detección se basó en comparar la telemetría de ejecución contra una varianza de línea base ajustada. En lugar de solo comprobar si una tarea terminó, el sistema rastreó cuatro métricas clave: recuento de éxitos de tareas, costo de tokens, volumen de llamadas a herramientas y deriva de alcance. La deriva de alcance mide la superposición entre los ámbitos de API utilizados en una ejecución versus la línea base, calculada como uno menos la superposición promedio. Los umbrales para alertas se establecieron en el doble de la varianza de la línea base para tener en cuenta la distribución estadística natural.

El volumen de llamadas a herramientas resultó ser la métrica más sensible para los problemas de infraestructura. Debido a que las llamadas a herramientas de la línea base variaban solo un 3%, un umbral ajustado de ±7% podía detectar fácilmente anomalías. Por ejemplo, cuando la API upstream se volvió inestable, la lógica de reintento del agente hizo que las llamadas a herramientas saltaran un 70%, disparando una alerta aunque todas las tareas seguían teniendo éxito. En contraste, el uso de tokens variaba un 18% entre las ejecuciones de línea base, lo que requería un umbral amplio de ±37% que permitía que ineficiencias significativas pasaran desapercibidas.

El estudio también destacó la importancia de analizar salidas no estructuradas. En la prueba de lectura obsoleta, donde el agente leía datos desactualizados de una réplica, todas las métricas cuantitativas permanecieron dentro de los límites normales. El agente detectó la discrepancia entre sus escrituras y las lecturas subsiguientes, luego suprimió deliberadamente los reintentos para evitar mutaciones duplicadas. Este comportamiento defensivo salvó al sistema de un error financiero pero hizo invisible el fallo de infraestructura para los monitores numéricos. La única evidencia del fallo existía en el resumen de texto final del agente, que describía explícitamente la anomalía.

Detalles clave

• Actualizaciones silenciosas de modelos: Un alias de modelo no fijado cambió de claude-haiku-4-5 a claude-haiku-5-5 entre ejecuciones de prueba, alterando el comportamiento sin activar ninguna alerta de despliegue.
• Sensibilidad de métricas: Los recuentos de llamadas a herramientas detectaron cuatro fallos, la deriva de alcance detectó cuatro, el éxito de tareas detectó solo dos y los costos de tokens detectaron uno.
• Enmascaramiento de reintentos: Una rama de API inestable inyectó 31 errores transitorios, todos absorbidos por los reintentos del agente, resultando en un aumento del 70% en las llamadas a herramientas pero una tasa de éxito de 19/19.
• Soluciones autónomas: Cuando la documentación fue truncada, el agente utilizó bucles de shell de fuerza bruta para adivinar endpoints faltantes, aumentando el uso de tokens en un 73% y el tiempo de ejecución de cinco a quince minutos.
• Fallos invisibles: Las lecturas obsoletas de la base de datos no causaron alertas de métricas porque la respuesta cautelosa del agente mantuvo los cambios en tokens y llamadas a herramientas por debajo de los umbrales de detección.
• Decaimiento adversario: Las tareas trampa de reembolso que diferenciaban a los modelos en septiembre no lograron detectar ningún error en octubre porque el modelo más nuevo las manejaba correctamente, volviendo obsoleta la prueba.

Por qué importa

Para los equipos de ingeniería que construyen agentes autónomos, este estudio demuestra que altas tasas de éxito de tareas pueden coexistir con graves ineficiencias operativas y riesgos. Los agentes son cada vez más capaces de ocultar problemas de infraestructura mediante lógicas de reintento y comportamientos adaptativos. Si solo monitorizas si una tarea se completa, pasarás por alto los crecientes costos, la latencia y los potenciales problemas de consistencia de datos que se acumulan tras bambalinas. Esta desconexión entre la finalización de tareas y la salud de la infraestructura significa que los paneles tradicionales de disponibilidad y éxito son insuficientes para sistemas impulsados por IA.

Además, la dependencia de conjuntos de pruebas adversarias estáticas es una vulnerabilidad. A medida que los modelos se actualizan, las tareas trampa previamente efectivas pueden volverse triviales, dando una falsa sensación de seguridad. Los ingenieros deben tratar las salidas de los agentes como telemetría estructurada, no solo como respuestas finales. Analizar resúmenes en busca de incertidumbre y rastrear métricas de ejecución de bajo nivel como las llamadas a herramientas proporcionan la visibilidad necesaria para distinguir entre una mejora genuina y una degradación silenciosa. Sin estas perspectivas más profundas, los equipos corren el riesgo de desplegar agentes que parecen funcionales pero son financiera o técnicamente inestables.

Qué puedes hacer

• Registrar IDs de modelos resueltos: Registra la cadena específica de versión del modelo para cada ejecución y lanza alertas ante cualquier cambio para detectar actualizaciones silenciosas.
• Rastrear llamadas a herramientas por tarea: Monitoriza el número de llamadas a la API junto con las tasas de éxito, utilizando un umbral ajustado basado en la varianza de la línea base para detectar tormentas de reintentos.
• Aislar métricas de reintento: Rastrea y lanza alertas explícitamente sobre errores transitorios e intentos de reintento como advertencias tempranas de degradación de la infraestructura upstream.
• Analizar resúmenes de agentes: Utiliza procesamiento de lenguaje natural para escanear los informes finales de los agentes en busca de palabras clave que indiquen incertidumbre, fallos de verificación o acciones suprimidas.
• Rotar pruebas adversarias: Actualiza regularmente tus tareas trampa y casos de prueba negativos para asegurar que sigan siendo relevantes para la generación actual del modelo.
• Validar con pruebas de inyección: Inyecta periódicamente fallos de red transitorios en tu entorno de preproducción para verificar que tu capa de telemetría detecta el aumento resultante en las llamadas a herramientas.