Los agentes de IA fallan al volver a intentar sin contexto
Un nuevo análisis muestra que los agentes de IA siguen intentando llamadas a herramientas sin evaluar si la falla es transitoria, generando ciclos de reintentos innecesarios y desperdicio de recursos.

¿Por qué siguen intentando?
El autor describe cómo, en un escenario típico de un agente de IA, se producen tres intentos consecutivos de llamar a una herramienta cuando se recibe un error 422. Cada intento termina con el mismo mensaje y el agente termina disculpándose. El problema no es el modelo, sino la falta de información que permita distinguir entre una falla transitoria y una permanente.
La falta de trazas útiles
Para que un agente aprenda a no reintentar de forma ciega, debe contar con un rastreo de fallos que incluya:
- Identidad: un ID estable que permita correlacionar instancias idénticas de error.
- Resultado: qué acción se intentó y si funcionó.
- Denominador: tasa de éxito frente a fallos, para contextualizar la severidad. El texto propone normalizar la cadena de error (eliminar URLs, UUIDs, timestamps y números largos) y generar un hash que sirva como identificador. Así dos incidentes con el mismo patrón se agrupan y se pueden contar.
Métrica de confianza
En lugar de confiar en el modelo para evaluar la confiabilidad, se sugiere usar la cota inferior del score de Wilson. Esta métrica incorpora el tamaño de la muestra: 5/5 puede parecer perfecto, pero su cota es de 0.57, mientras que 117/124 es 0.89. El agente puede devolver “no sé” cuando los datos son insuficientes.
¿Comparten los agentes el mismo problema?
El autor plantea la hipótesis de que los agentes de distintos usuarios podrían experimentar fallos idénticos al llamarse a los mismos servidores o APIs. Sin embargo, también es posible que las fallas sean locales (autenticación, límites de tasa). Esta cuestión aún no ha sido comprobada y plantea una línea de investigación.
Implicaciones para la práctica
- No escribir reglas genéricas como “no reintentar inmediatamente” sin proveer el contexto necesario.
- Implementar un sistema de trazas que normalice los mensajes de error y genere IDs reproducibles.
- Usar métricas de confianza basadas en la muestra real y no en la predicción del modelo.
- Considerar la posibilidad de que los fallos no sean compartidos y adaptar la lógica de reintento a la localidad del error.
Conclusión
El artículo subraya que la solución no está en el modelo de IA, sino en cómo se recopilan y utilizan los datos de error. Un agente bien informado puede evitar ciclos de reintentos costosos y mejorar la eficiencia operativa.


