ThinkingBox-Bench: 80% de los fallos en agentes son de tools

El agente que dice "listo" pero la base de datos no

Un agente recibe el caso de una clienta cuya cocina de US$745 lleva 15 días atrapada en una excepción de paquetería en Nashville. Hace nueve llamadas a herramientas, redacta una respuesta pulcra, cierra el ticket como resuelto. La base de datos nunca recibió la orden de mantenerlo en espera y la clienta nunca recibió la respuesta que había pedido. Ese desfase entre lo que el modelo afirma y lo que el backend terminó aceptando es exactamente lo que ThinkingBox-Bench, el nuevo benchmark conjunto de Microsoft y Hugging Face, se propuso cuantificar.

Según el paper publicado el 3 de octubre, la mayoría de los benchmarks de agentes evalúan si la respuesta final "suena bien" o si las llamadas a herramientas tienen la sintaxis correcta. ThinkingBox-Bench da un paso más: comprueba el estado terminal de la base de datos, los efectos secundarios no previstos y los efectos requeridos que faltaron. Si la respuesta del agente contradice lo que realmente cambió el registro, la tarea falla, por muy bien escrita que esté.

Qué midió exactamente

La prueba cubre 507 flujos de trabajo empresariales con estado (retail, seguros de auto, viajes, neobancos y consultoría), ejecutados 20 veces cada uno contra 12 modelos de lenguaje distintos. En total, se procesaron 121.680 trials válidos. De ellos, 79.853 intentos fallaron las verificaciones ejecutables sobre el estado del backend. Y el dato más incómodo: el 67,24% de esos fallos terminaron "limpios": el agente cerró la sesión sin error de herramienta, ejecutó una acción que modifica estado y reportó éxito. Es decir, el sistema, visto desde fuera, parecía haber funcionado.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Al desmenuzar los fallos, el benchmark encontró:

77,61% con valores de campo incorrectos en el estado final.
43,30% con efectos secundarios no intencionados (registros cambiados que no debían tocarse).
25,36% con efectos requeridos ausentes (el agente no hizo lo que debía).

Las tres señales se superponen, lo que hace aún más difícil diagnosticar a simple vista.

Por qué un solo intento no basta

ThinkingBox introduce tres métricas que conviene memorizar:

pass@1: porcentaje de intentos únicos exitosos. Es el número que casi todos los leaderboards publican.
pass@20: porcentaje de tareas que el modelo resolvió al menos una vez en 20 intentos. Mide capacidad bruta.
20/20 observado: tareas en las que el modelo acertó las 20 veces. Mide consistencia real, sin suavizados.

El salto entre una y otra es brutal. Claude Opus 5.5 lidera el pass@1 con 67,16%; Kimi-K3 resuelve el 93,89% de las tareas al menos una vez (476 de 507), el mejor del campo. Pero cuando se exige acierto en los 20 intentos, solo 241 tareas (el 47,53%) sobreviven para Opus 5.5 y apenas 68 (el 13,41%) para Kimi-K3. Es decir, el modelo más "capaz" en bruto es uno de los menos consistentes.

El paper documenta que solo GPT-6 Astra, Claude Opus 5.5 y Claude Opus 5 retienen más del 70% de su pass@1 tras 20 repeticiones (78%, 71% y 71% respectivamente). En el otro extremo, modelos como GLM-5.1, Kimi-K2.6 y DeepSeek-V4-Pro conservan apenas un 8%.

El 80% de los fallos no son del modelo, son del manejo de herramientas

Uno de los hallazgos más accionables del paper es el desglose de firmas de fallo:

Tool usage: 79,9% de los fallos.
Wrong state updates: 10,3%.
Incomplete user resolutions: 7,0%.
No state-changing action: 2,9%.

Que cuatro de cada cinco errores vengan del uso de herramientas cambia la conversación: el cuello de botella no está en la inteligencia del modelo, sino en cómo recupera errores de herramientas, precondiciones fallidas o lookups vacíos. Es un problema de reintentos y manejo de errores antes que de capacidad de razonamiento. NVIDIA llegó a una conclusión afín en su blog del 21 de septiembre de 2026 sobre evaluación de agentes, donde introduce la jerarquía trial → task → turn → step para distinguir entre la corrección de cada llamada y el resultado final.

La dificultad también cambia drásticamente por dominio: retail promedia 59,52% de pass@1; seguros de auto, apenas 33,83%. Modelos que arrasan en retail, como Claude Opus 4.6 (68,62%), se desploman a 8,30% en seguros.

Cuánto cuesta cada respuesta confiable

ThinkingBox no mide solo capacidad, también coste. Calcula el coste por tarea exitosa (precio de los tokens dividido por intentos acertados, con tarifas listadas en OpenRouter) y el coste por tarea dependable (campaña completa de 20 corridas dividida por las tareas que pasaron 20/20).

El frente de Pareto en coste por éxito lo lideran GPT-5.6 Sol (US$0,127), GPT-5.4 (US$0,131) y Claude Opus 5.5 (US$0,276). Cuando se exige consistencia, el ranking cambia: GPT-5.4 cuesta US$6,80 por tarea dependable, GPT-6 Astra US$7,45 y Claude Opus 5.5 US$7,80. Claude Opus 5, con idénticas 241 tareas 20/20, cuesta US$13,30, lo que lo deja dominado por su sucesor.

La conclusión para quien despliega agentes: el camino más barato a "acertar una vez" no es el más barato a "acertar siempre".

El benchmark llega vía OpenEnv

ThinkingBox no se queda en un paper. El sandbox y el dataset ya están en Hugging Face bajo la interfaz OpenEnv, lo que permite ejecutar episodios completos y recibir una recompensa binaria pass/fail. La licencia del código es MIT y la del dataset CDLA-Permissive 2.0, con el entorno OpenEnv en BSD-3-Clause.

Cada tarea define un estado inicial del backend, el objetivo del usuario, las herramientas MCP disponibles, la política del dominio y las verificaciones ejecutables. Un usuario simulado guarda contexto privado (referencias de reserva, fechas de nacimiento, preferencias) y solo lo libera si el agente pregunta correctamente. Cada intento corre en una sesión MCP aislada con estado recién inicializado, por lo que dos ejecuciones de la misma tarea nunca comparten filas de base de datos ni caché de herramientas, justo lo que hace significativas las 20 repeticiones.

Qué significa esto para tu startup

Tres conclusiones operativas si estás construyendo o desplegando agentes que tocan datos reales:

Deja de mirar la respuesta final del modelo y empieza a mirar el estado del backend. El 67% de los fallos del benchmark ocurrieron en trayectorias que parecían exitosas. Tu logger debe registrar qué cambió en la base de datos, no solo qué dijo el LLM.
Construye sobre un repeat metric, no sobre un único intento. Un modelo que acierta 1 de cada 5 puede pasar tu eval. Reporting 1/5, 5/5 o 20/20 importa más que el promedio, y debes declarar explícitamente cuál usas.
Trata los errores de herramientas como ciudadanos de primera clase. Clasifícalos, permite reintentos solo sobre los recuperables, recorta la superficie de herramientas a lo que el workflow realmente necesita y exige aprobación humana en los cambios que no puedes revertir barato.

El contexto macro ayuda a dimensionar la urgencia: según IDC, el 77% de las empresas ya ejecutan agentes de IA en producción, y Gartner proyecta que el mercado de servicios de IA alcance US$515.000 millones en 2029. En ese escenario, evaluar agentes por lo que su salida dice, y no por lo que su backend registra, es el equivalente a confiar en un CFO porque presenta diapositivas pulidas: la cifra termina en otro sitio.

Si quieres probarlo con tu propio modelo, el repositorio microsoft/thinkingbox-data (release thinkingbox-bench-v1.0) y la imagen Docker de Typesense 30.1 dejan el entorno reproducible en local con uv, Python 3.11+ y Docker en Linux o WSL. El paper completo está en arXiv:2608.19741.