ThinkingBox: el benchmark que mide a los agentes por lo que dejan en la base de datos, no por lo que dicen

Imagina un agente de IA que cierra un ticket de soporte tras nueve llamadas a herramientas perfectamente formadas, le dice al cliente que su problema está resuelto y, al mismo tiempo, deja la incidencia del transportista abierta y nunca devuelve la respuesta que el usuario buscaba. La conversación parece impecable, pero la base de datos —la única testigo fiable— dice otra cosa. Esa brecha entre lo que un agente narra y lo que realmente ejecuta es lo que Microsoft y Hugging Face han decidido medir en abierto con ThinkingBox, un nuevo benchmark que ya está disponible y que cambia la forma en que deberíamos evaluar a los agentes empresariales.

El trabajo se ha presentado esta semana en el blog de Hugging Face bajo un título que condensa el problema: «El agente dijo que había terminado. La base de datos no estaba de acuerdo». Está firmado por Microsoft Research y Hugging Face, y se apoya en un artículo en arXiv (2608.19741) con datos, código y un entorno abierto. La propuesta es directa y demoledora para la industria: una llamada a herramienta correcta no es un resultado, y un único éxito no es fiabilidad.

Qué es ThinkingBox, en una frase

ThinkingBox es un benchmark con 507 flujos de trabajo empresariales con estado que ejecuta cada tarea 20 veces contra el mismo backend limpio y, en lugar de mirar la respuesta del modelo o la traza de herramientas, examina el estado final de la base de datos y los efectos laterales que el agente ha dejado. Las tareas no son acertijos abstractos: son procesos reales de retail, seguros de auto, viajes, neobancos y consultoría, con datos, políticas y excepciones. Cada caso tiene un verificador ejecutable que consulta el backend y dice si el estado final coincide con el requerido.

El ejemplo que los autores usan como apertura lo deja muy claro. Una clienta reclama por un electrodoméstico de 745 dólares atrapado durante quince días en una excepción del transportista. El agente hace nueve llamadas correctas, lee la política dos veces, confirma que la cuenta no califica para compensación por retraso, abre un ticket, lo documenta y lo cierra como resuelto. Desde fuera, un grader que solo mire las tool calls ve un trabajo impecable. El grader que mira la base de datos descubre dos problemas: la excepción del transportista sigue abierta cuando el estado final exigido era «en espera, pendiente de resolución», y la clienta nunca recibe una respuesta de fondo.

Por qué importa para quien despliega agentes en producción

El benchmark introduce tres métricas que deberían obligar a releer cualquier tabla de ranking de agentes:

• pass@1: el porcentaje de intentos individuales que aprueban el verificador. Es la cifra que casi todos los leaderboards publican.
• pass@20: porcentaje de tareas que el agente resolvió al menos una vez en 20 intentos. Responde a «¿puede hacerlo alguna vez?»
• observed 20/20: tareas que el modelo aprobó las 20 veces seguidas. Responde a «¿puede hacerlo siempre?»

La diferencia entre las tres es enorme y es donde está la lectura incómoda. En la tabla global, Claude Opus 5.5 lidera con un pass@1 del 67,16 %, seguido muy de cerca por Claude Opus 5 (66,50 %), GPT-5.4 (65,36 %), GPT-5.6 Sol (61,91 %) y Claude Sonnet 4.6 (59,19 %). Si solo atendiéramos a pass@1, esto parece un ranking de capacidad más. La fotografía cambia cuando se observa 20/20: la mayoría de los modelos cae en picado, porque ser capaz de resolver una tarea una vez y otra vez, sin fallar, son cosas muy distintas.

La consecuencia operativa es directa: desplegar un agente en producción con una única ejecución por conversación es, según estos números, una apuesta. Un sistema que acierta 7 de cada 10 veces va a fallar 3 de cada 10, y esos 3 fallos pueden ser precisamente los casos donde el cliente tiene más presión (una excepción de transportista, un siniestro de auto, una disputa de cargo). En un centro de soporte, eso es ruido; en un flujo financiero o de seguridad, es un incidente.

Las firmas de fallo que el benchmark pone nombre

ThinkingBox no se queda en el porcentaje. Analiza qué tipo de fallo comete el agente cuando falla, y ahí aparece la cifra más llamativa del artículo. Sobre 121.680 intentos válidos repartidos entre 12 modelos, 79.853 fallaron el verificador ejecutable. De esos fallos, el 67,24 % terminó de forma limpia: invocó una herramienta que cambia estado, no reportó ningún error final de tool call y firmó la conversación con tono de éxito. Es decir, el sistema «creía» haber terminado bien.

Cuando los autores abren esos fallos silenciosos, las categorías se reparten así:

• 77,61 %: valores de campo incorrectos. El ticket se cerró como «resuelto» cuando debía ser «en espera»; el campo de estado de envío se actualizó con el código que no era; el campo de importe quedó con el número anterior a la corrección.
• 43,30 %: efectos laterales no deseados. Acciones extra que el verificador no esperaba: un correo enviado a un equipo equivocado, un log escrito en otro sistema, una línea duplicada en una tabla de auditoría.
• 25,36 %: efectos requeridos que faltan. La acción que el flujo exigía nunca llegó a ejecutarse: el reembolso no se marcó como initiated, la alerta no se disparó, la política no se aplicó al caso.

Las tres firmas se solapan, lo que significa que muchos agentes fallan en más de una dimensión a la vez. Para alguien que esté pensando en desplegar un agente que toca una base de datos regulada o un sistema de tickets, estas tres cifras deberían pesar más que el último benchmark de razonamiento.

Qué enseña esto a quien mira los agentes desde la seguridad

En este blog hemos cubierto a lo largo de las últimas semanas varios casos en los que los agentes salen del sandbox, filtran secretos o votan su próximo movimiento con un consejo de IAs. La conversación suele girar en torno al riesgo «externo»: el prompt injection, el jailbreak, el contenido que el modelo no debería generar. ThinkingBox pone el foco en el riesgo «interno», que es el que termina importando en producción: lo que el agente hace bien visto desde fuera, pero mal visto desde el log de la base de datos.

Tres implicaciones prácticas para equipos de seguridad y platform engineering:

• Una política de «tool call correcta = acción correcta» ya no se sostiene. Hay que exigir verificaciones ejecutables sobre el estado final, no sobre la traza.
• Los agentes en producción deberían diseñarse para fallar ruidosamente: preferir un error visible a un cierre de ticket silencioso. Si el veredicto lo da el backend y no el propio agente, mejor.
• La repetibilidad es una métrica de seguridad tanto como de calidad. Un agente que pasa un test una vez y falla cuatro es, en términos operativos, un agente inseguro.

El propio artículo incluye un recordatorio incómodo para el sector: «Una trayectoria es una afirmación. El estado de la base de datos es la evidencia. La repetición es la prueba de confianza». Es una frase que merece la pena enmarcar al lado de cualquier diagrama de arquitectura de un agente.

Cómo ejecutarlo en local

El benchmark se libera con su entorno y sus datos a través de OpenEnv en Hugging Face. Los autores han publicado la librería, las pruebas y el harness necesario para correr ThinkingBox contra cualquier modelo compatible, incluidos los puntos de referencia abiertos como Qwen 3.8 o la familia Holo4 de H Company, que hemos visto recientemente.

Los datos y el artículo están en abierto: https://huggingface.co/blog/microsoft/thinkingbox y https://arxiv.org/abs/2608.19741. El entorno ejecutable está en https://github.com/huggingface/OpenEnv/tree/main/envs/thinkingbox_env y el conjunto de datos completo en https://github.com/microsoft/thinkingbox-data.

Reproducir el benchmark es razonablemente directo. La idea de fondo es: levantar el entorno, conectar el modelo bajo prueba, dejar que el agente itere sus 20 ejecuciones por tarea, y comparar lo que escribe en la base de datos contra los checks ejecutables. Si el modelo tiene una API tipo tool-use, la integración es de horas, no de semanas.

Por qué este lanzamiento pesa en octubre de 2026

El contexto importa. En las últimas semanas hemos visto cómo los agentes pasan de ser prototipos a componentes críticos: OpenAI ha presentado informes técnicos de incidentes con Hugging Face por escapes de sandbox, el Pentágono reorganiza su dirección de misión para incluir IA al nivel de ciberseguridad y los modelos abiertos como Xiaomi MiMo v2.6 empiezan a aparecer en flujos de seguridad. ThinkingBox llega en el momento exacto en que la conversación debería dejar de girar solo sobre qué puede hacer un agente y empezar a girar sobre qué hace realmente cuando nadie mira.

Para los equipos que ya están desplegando agentes o que están a punto de hacerlo, la recomendación es clara: antes de añadir una nueva capacidad, pídele al agente que la ejecute veinte veces seguidas y mira la base de datos al final de cada una. Si la columna «éxito» no se mantiene estable, esa capacidad no está lista para producción, por muy bien que se vea en la demo.

En seguridad, como en casi todo lo demás, lo que cuenta no es lo que el sistema dice que ha hecho, sino lo que la base de datos confirma que ha hecho.