ThinkingBox: 67% de fallos de agentes pasan desapercibidos

El benchmark que pone a los agentes contra la base de datos, no contra el escenario

ThinkingBox es un benchmark publicado por Microsoft y Hugging Face que mide algo que la mayoría de los rankings de IA ignoran: si el agente deja la base de datos en el estado correcto, no si su respuesta parece correcta. Cubre 507 flujos de trabajo con estado en retail, seguros de auto, viajes, neobank y consultoría. Cada tarea se ejecuta 20 veces desde un backend recién inicializado dentro de sesiones MCP aisladas, así dos intentos de la misma tarea nunca comparten fila de tabla ni caché.

En una ablación con un conjunto común, se probaron 12 modelos en 121.680 intentos válidos. De esos, 79.853 fallaron las verificaciones ejecutables sobre el estado final — incluso cuando el agente reportó éxito.

El dato que importa: 67% de los fallos terminan "limpios"

El hallazgo más incómodo para quien pone agentes en producción: 67,24% de las fallas terminaron de forma limpia. El agente llamó a una herramienta que cambia estado, no reportó ningún error de tool, y siguió adelante. Pero las verificaciones ejecutables sobre la base de datos encontraron:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

77,61% con valores de campo equivocados
43,30% con efectos colaterales no deseados
25,36% con efectos obligatorios ausentes

Las categorías se superponen: el agente "terminó feliz" y la base de datos registró otra cosa. Tuhin Kundu, autor del post en Hugging Face y Microsoft, lo resume así: "Una trayectoria es una alegación. El estado de la base de datos es la evidencia. La repetición es el test de confianza".

Tres métricas, tres preguntas distintas

Como cada tarea corre 20 veces desde un backend limpio, ThinkingBox reporta tres números que responden preguntas diferentes y que los reportes tradicionales mezclan:

pass@1: ¿cómo se le da normalmente? Fracción de todas las tentativas que tuvieron éxito.
pass@20: ¿lo logra alguna vez? Fracción de tareas resueltas al menos una vez en 20 intentos.
20/20 observado: ¿es siempre correcto? Tareas que pasaron en las 20 tentativas registradas.

En pass@1 ponderado por tarea, Claude Opus 5.5 lidera con 67,16%, medio punto sobre Claude Opus 5 (66,50%) y GPT-5.4 (65,36%). Entre los modelos abiertos, Kimi-K3 manda con 57,37%. El dominio pesa tanto como el modelo: Claude Opus 4.6 marca 68,62% en retail y solo 8,30% en seguros de auto.

La brecha entre amplitud y consistencia

El pass@1 oculta la pregunta que importa en producción: ¿el mismo agente vuelve a acertar? Kimi-K3 resuelve 93,89% de las tareas al menos una vez (476 de 507), pero solo 13,41% (68 de 507) pasan las 20 tentativas. Claude Opus 5 invierte el cuadro: 79,09% de pass@20, pero 47,53% del benchmark pasa 20/20. Kimi-K3 resuelve 75 tareas más que Opus 5 al menos una vez; Opus 5 resuelve 173 tareas más de forma consistente que Kimi-K3.

El upgrade de versión tampoco compra confiabilidad. Claude Opus 5.5 supera a Opus 5 en pass@1 (67,16% vs 66,50%) y resuelve más tareas alguna vez, pero pasa exactamente el mismo número de tareas 20/20: 241. Medio punto de accuracy en el titular no compró confiabilidad adicional.

Cuánto cuesta ser confiable

El equipo calculó cada modelo con tarifas de lista de OpenRouter sobre la campaña completa (507 tareas × 20 rondas) y dividió el costo por intento exitoso. GPT-5.4 cuesta US$43,49 para 507 intentos y entrega 65,36% de pass@1, lo que da US$0,131 por intento exitoso. En la frontera de costo por éxito, solo tres modelos sobreviven sin ser dominados:

GPT-5.6 Sol: US$0,127 por éxito
GPT-5.4: US$0,135 por éxito (3,45 puntos de pass@1 extra por 0,4 centavo más)
Claude Opus 5.5: US$0,276 por éxito (1,80 punto extra a 0,276)

Claude Opus 5, a US$0,475 y 66,50% de pass@1, queda dominado: más caro y menos preciso que su sucesor.

Pero el costo por éxito no es el costo por confiabilidad. Dividiendo por tareas que pasaron las 20 de 20 tentativas, el ranking cambia: GPT-5.4 es el más barato a US$6,80 por tarea dependible, pero solo 128 tareas (25,25%) llegan ahí. GPT-6 Astra cuesta US$7,45 para 231 tareas (45,56%) y Claude Opus 5.5 cuesta US$7,80 para 241 tareas (47,53%). Opus 5 también pasa 241 tareas, pero a US$13,30 cada una. Y GPT-5.6 Sol, el más barato por éxito aislado, sube a US$9,76 por tarea dependible.

El camino más barato hasta una respuesta correcta no es el camino más barato hasta una respuesta confiable.

Por qué fallan: 80% es manejo de herramienta, no razonamiento

Cada traza con falla recibe una firma diagnóstica determinística. El patrón es accionable:

79,9% uso de herramienta
10,3% actualizaciones de estado incorrectas
7,0% resoluciones incompletas para el usuario
2,9% ninguna acción que cambia estado

La dificultad varía por dominio: retail promedia 59,52% de pass@1 entre los modelos listados, contra 33,83% en seguros de auto. Esto es, ante todo, un problema de retry y recuperación de error, no un problema de modelo.

El contexto: la verificación de agentes es el cuello de botella de 2026

La preocupación de ThinkingBox no es exclusiva. Nvidia publicó en diciembre de 2026 su método Mid-Harness, que usa un modelo verificador para elegir la mejor acción antes de ejecutarla, y logró subir el pass@1 de 50,00% a 68,03% en TerminalBench-Lite, según reportó Crypto Briefing. La conclusión central del paper: la verificación por paso (action scaling) rinde más y cuesta menos que reejecutar toda la tarea (trajectory scaling).

En el plano arquitectónico, el consenso entre quienes ya operan agentes en producción — sintetizado por un artículo en HackerNoon — es poner una capa de confiabilidad entre el modelo y cada API que escribe estado: validación estricta, idempotencia, presupuestos de tiempo, errores normalizados y aprobación humana para acciones irreversibles. Un análisis publicado por Harvard Business ReviewSponsored en agosto de 2026 lo formula igual desde la empresa: la conversación sobre agentes pasó de "¿podemos construir uno?" a "¿podemos confiar en uno?" — y la respuesta depende de observabilidad, evaluaciones continuas y un loop de feedback disciplinado, no del modelo subyacente.

¿Qué significa esto para tu startup?

Si hoy vendes, refacturas o desplegas un agente que escribe en una base de datos — pedidos, reembolsos, pólizas, tickets, cambios de plan — ThinkingBox confirma lo que muchos ya sospechaban: el pass@1 no es la métrica correcta para producción.

Acciones concretas que puedes tomar esta semana:

Mide repetibilidad, no solo acierto. Si tu agente solo corre una vez por caso en CI, estás midiendo la métrica equivocada. Pídele al pipeline que ejecute cada flujo crítico 5–10 veces y reporte el porcentaje que pasa todas.
Verifica el estado terminal, no el resumen del modelo. El agente puede reportar "ticket cerrado" mientras la base sigue diciendo "abierto". Tu test debe leer directamente el campo de estado, no confiar en lo que el LLM afirma.
Clasifica errores antes de reintentar. Como el 80% de las fallas son de herramienta y no de razonamiento, un retry ciego solo amplifica el problema. Implementa un vocabulario corto de errores (DEPENDENCYTIMEOUT, CONFLICT, INVALIDINPUT) y reintenta solo los recuperables.
Separa lectura, borrador y commit. Un agente que abre un borrador de reembolso y otro que lo confirma deben ser herramientas distintas, con aprobaciones humanas atadas al payload exacto.
Reduzca la superficie de herramientas a lo que el flujo realmente necesita. Cada herramienta extra es una nueva fuente de fallo silencioso.
Evalúa por dominio, no en general. Tu agente en retail puede rendir muy distinto al de seguros o legal. Mide en los flujos que vas a tocar, no en benchmarks genéricos.

ThinkingBox no te dice qué modelo comprar. Te dice que pass@1 es la habilidad incorrecta para medir lo que va a escribir en tu base de datos — y que la repetición sobre estado real es la única prueba que importa cuando el agente ya dijo que terminó.