Microsoft y Hugging Face presentaron conjuntamente el marco de evaluación de agentes ThinkingBox y su benchmark asociado, ThinkingBox-Bench. El criterio de puntuación no se basa en que el agente informe por sí mismo que ha «terminado», sino en el estado real de la base de datos del backend una vez que el agente ha acabado su trabajo.
El benchmark incluye 507 tareas de procesos de negocio con estado, distribuidas en cinco sectores: retail (98), seguros de auto (100), viajes (104), banca digital (104) y consultoría (101). Cada tarea se ejecuta de forma independiente 20 veces sobre un backend limpio, y se usan scripts de verificación ejecutables para comprobar el estado final de la base de datos y los efectos secundarios, por ejemplo si el campo que debía cambiar cambió correctamente o si se tocó por error un registro que no debía modificarse.
“The Agent Said It Was Done. The Database Disagreed.”
(El agente dijo que había terminado. La base de datos no estuvo de acuerdo.)
Los resultados de los 18 modelos
En la evaluación participaron 18 modelos, tanto de código cerrado como de pesos abiertos. Según el criterio de «acertar las 20 de 20 ejecuciones», Claude Opus 5.5 y Claude Opus 5 empataron en primer lugar, resolviendo de forma estable 241 tareas cada uno, un 47,53%; GPT-6 Astra quedó tercero con 231 tareas, un 45,56%. Es decir, incluso el mejor modelo no logra ser perfectamente consistente en más de la mitad de las tareas.
El modelo con mayor cobertura fue Kimi-K3: de las 507 tareas, resolvió correctamente al menos una vez 476, un 93,89%. Pero solo acertó las 20 ejecuciones completas en 68 tareas. El mismo modelo parece casi omnipotente según pass@20, pero queda muy atrás en estabilidad: las dos cifras difieren siete veces.
Los datos sobre las causas de los fallos son más concretos. De los 79.853 intentos que «terminaron con normalidad pero con un resultado incorrecto», el 77,61% tuvo valores de campo mal escritos y el 43,30% provocó efectos secundarios no deseados (ambas categorías pueden darse a la vez). El equipo calcula que alrededor del 80% de los fallos se producen en la etapa de llamada a herramientas, por ejemplo con parámetros mal pasados o un orden de llamadas incorrecto, mientras que los errores de razonamiento propiamente dicho son menos frecuentes.
El equipo también presentó el «costo por tarea confiable», es decir, cuánto cuesta en promedio completar una tarea de forma estable en 20 ejecuciones: 6,80 dólares para GPT-5.4, 7,45 dólares para GPT-6 Astra y 7,80 dólares para Claude Opus 5.5. La generación anterior, GPT-5.4, queda por delante de los modelos más nuevos en este indicador.
Comparación con los benchmarks de agentes existentes
Medir la estabilidad con múltiples ejecuciones no es una idea original de ThinkingBox. El τ-bench, publicado por Sierra en 2024, ya proponía la métrica pass^k, que exige que el modelo tenga éxito k veces consecutivas en la misma tarea, y entonces solo cubría los sectores de retail y aerolíneas. La diferencia de ThinkingBox está en la escala y en el criterio de evaluación: el número de tareas sube a 507, el número de sectores sube a cinco, y los efectos secundarios se consideran una condición de fallo independiente. Con el criterio de τ-bench, un agente que modifica además un registro no relacionado no necesariamente pierde puntos.
Este sitio ya informó sobre el benchmark Vero, de Berkeley, en el que los agentes debían completar 43 proyectos de software, y el mejor resultado fue de 27 proyectos terminados, lo que mide «cuánto puede hacer de una sola vez». ThinkingBox va en la dirección contraria: la tarea en sí no es difícil, lo que importa es si, al repetir lo mismo 20 veces, alguna vez sale mal. En los procesos empresariales, este segundo tipo de error suele ser más grave: modificar mal el monto de una póliza o un campo de transferencia una sola vez cuesta mucho más corregirlo que dejar una tarea sin terminar.
Cómo usarlo
El código es de código abierto bajo licencia MIT, los datos del benchmark usan CDLA-Permissive-2.0 y el entorno OpenEnv usa BSD-3-Clause, y se puede ejecutar directamente a través de la interfaz OpenEnv en Hugging Face. El despliegue local requiere Docker y Typesense para gestionar el estado, las herramientas se ofrecen a través de un servidor MCP, y además hay que configurar tres endpoints de modelo: el agente evaluado, el usuario simulado y el modelo juez.
Tanto el usuario simulado como el juez los interpretan modelos, lo que de por sí puede introducir errores. El blog no reveló por separado la tasa de concordancia entre el modelo juez y la anotación humana; hasta que aparezcan esos datos, las diferencias de uno o dos puntos porcentuales entre modelos no deberían sobreinterpretarse. En el proyecto también participaron becarios de la Universidad de Pittsburgh, la UC Irvine, la Universidad Northwestern y la Universidad de Columbia.
Fuentes: blog de Hugging Face, Microsoft Research, CocoLoop, artículo del τ-bench de Sierra; el número de tareas resueltas por cada modelo, la proporción de tipos de fallo y el costo por tarea siguen las cifras publicadas por el equipo de ThinkingBox.