Un agente de atención al cliente recibe la consulta de una compra de 745 dólares atascada quince días en un centro de reparto. Ejecuta nueve llamadas a herramientas: consulta el pedido, revisa el seguimiento, busca el perfil de la clienta, lee dos veces la política de reembolsos, comprueba que no hay ticket, lo abre, documenta la cronología y concluye que la clienta no cumple los requisitos de compensación. Después cierra el ticket como resuelto y responde: «Como su consulta está resuelta, ¿puedo ayudarle en algo más?».
Hay dos errores. La incidencia con el transportista sigue abierta, así que el estado final exigido era «en espera», no «resuelto». Y la clienta nunca recibió respuesta a lo que preguntó. Un evaluador que revise las llamadas a herramientas vería nueve correctas. El que revise si el agente escribió en la base de datos, también. La base de datos es la que discrepa.
Ese desfase es lo que mide ThinkingBox, un banco de pruebas que Microsoft y Hugging Face han publicado conjuntamente y que ya está disponible a través de Hugging Face. El caso descrito procede de una de sus tareas de referencia.
Una llamada a herramienta no es un resultado
Según el anuncio de Microsoft y Hugging Face, las respuestas finales y las llamadas válidas a herramientas son solo aproximaciones. Un agente puede sonar correcto y dejar el valor equivocado, modificar el registro que no tocaba o generar un efecto adicional no previsto. Solo los registros que deja atrás resuelven la pregunta.
En un análisis sobre 121.680 intentos válidos con 12 modelos, 79.853 fallaron las comprobaciones ejecutables. De esos fallos, el 67,24% terminó de forma limpia, invocó una herramienta que cambia estado y no reportó error final. Las comprobaciones encontraron valores de campo incorrectos en el 77,61% de ellos, efectos adicionales no previstos en el 43,30% y efectos obligatorios ausentes en el 25,36%. Son categorías que se solapan.
Un acierto no es fiabilidad
Cada tarea se ejecuta 20 veces desde un estado inicial idéntico. El banco publica tres métricas: pass@1 (proporción de intentos correctos), pass@20 (tareas resueltas al menos una vez en 20 intentos) y tareas que pasan las 20 veces. La tercera es la que mide si el agente es fiable.
Los resultados separan dos cosas que suelen confundirse. Kimi-K3 resuelve 476 de 507 tareas al menos una vez, la mayor cobertura del conjunto, pero solo 68 tareas (13,41%) pasan los 20 intentos. Claude Opus 5 resuelve menos tareas al menos una vez (79,09%), pero completa el 47,53% del banco en todos los intentos. Claude Opus 5.5 mejora ligeramente la media por intento respecto a Opus 5, pero pasa exactamente las mismas 241 tareas en los 20 intentos: medio punto de precisión no aportó fiabilidad adicional.
El dominio pesa tanto como el modelo. Claude Opus 4.6 obtiene un 68,62% en comercio minorista y un 8,30% en seguros de automóvil. La media de comercio minorista entre los modelos de la tabla es del 59,52%; la de seguros, del 33,83%.
El coste de la consistencia
El anuncio calcula también un coste por tarea fiable: el coste estimado de las 20 ejecuciones dividido entre las tareas que pasan las 20. Según esos cálculos, GPT-5.4 es el más barato con 6,80 dólares por tarea fiable, aunque solo 128 tareas alcanzan el listón; GPT-6 Astra llega a 231 con 7,45 dólares, y Claude Opus 5.5 a 241 con 7,80 dólares. El modelo más barato por acierto individual no es el más barato por acierto fiable. Son estimaciones comparativas, no facturas.
Dónde fallan
Los autores asignan a cada traza fallida una firma diagnóstica. El dato principal: cerca de cuatro de cada cinco fallos son de manejo de herramientas, no de razonamiento. El 79,9% de los fallos corresponden a uso de herramientas, el 10,3% a actualizaciones de estado incorrectas, el 7,0% a resoluciones incompletas para el usuario y el 2,9% a ausencia de acción que cambie estado. El patrón práctico: los agentes suelen llegar a intentar el flujo y fallan al recuperarse de errores de herramienta, precondiciones no cumplidas o búsquedas vacías.
Los propios autores señalan que no han medido la mejora que aportarían sus recomendaciones. Entre ellas: comprobar el estado final antes de confirmar, no el resumen que hace el modelo; clasificar los errores de herramienta y sistema para dirigir los reintentos; reducir la superficie de herramientas a lo que el flujo necesita; y exigir aprobación humana en los cambios que no se pueden revertir sin coste.
Para un negocio que ya use agentes sobre pedidos, facturas o incidencias, la lectura útil es concreta: la respuesta del agente no es la prueba de que el proceso terminó. La prueba está en el sistema de destino. Merece la pena revisar qué comprobación de estado final existe hoy antes de dar por cerrada una tarea automatizada.
Pon tus procesos a prueba antes de confiar en el agente
Si ya usas agentes o automatizaciones que tocan pedidos, facturas o incidencias, el problema que reconoces es este: la tarea parece hecha, pero el registro no lo confirma. En Wemvy diseñamos integraciones entre tus herramientas y automatizaciones que verifican el estado real en el sistema de destino antes de dar un proceso por cerrado, y conectamos las consultas con tu CRM o tu sistema de gestión para que los pendientes lleguen listos al equipo.
Cuéntanos qué proceso quieres automatizar y qué comprobación necesitas para darlo por bueno, y te proponemos un primer paso con alcance acordado.
Fuente: huggingface.co
