ThinkingBox: medir agentes por lo que dejan en la base de datos, no por lo que dicen

Introducción

En escenarios de negocio, lo que realmente importa no es la frase bonita que devuelve un agente de IA, sino el registro que escribe en sus sistemas: la venta actualizada, el ticket cerrado o la devolución procesada. ThinkingBox, una herramienta desarrollada por Microsoft y publicada a través de Hugging Face, pone el foco precisamente ahí: evalúa agentes por el estado final y los efectos secundarios que producen en backends reales, y pregunta si pueden hacerlo veinte veces seguidas.

Este enfoque es especialmente relevante para empresas y tomadores de decisiones en América Latina, donde los procesos operativos y las integraciones con sistemas legados suelen ser críticos y costosos de rectificar cuando ocurren errores silenciosos.

Qué mide ThinkingBox

ThinkingBox no cuenta solamente cuántas llamadas a herramientas hizo un agente ni si la respuesta textual parece correcta. Ejecuta agentes contra sesiones de herramientas aisladas (MCP tool sessions) y al final analiza el estado del backend: campos en bases de datos, tickets, devoluciones y cualquier efecto secundario registrado.

Además, cada tarea se repite 20 veces desde un backend limpio e independiente, lo que permite evaluar no solo si un agente puede completar una tarea alguna vez, sino si lo hace de forma consistente.

Ejemplo ilustrativo: la promesa incumplida

Un caso extraído del benchmark muestra una compra de un electrodoméstico de USD 745 atascada en una excepción de mensajería en Nashville, quince días después de la fecha estimada. El agente realizó nueve llamadas a herramientas: consultó el pedido, revisó el rastreo, verificó el perfil del cliente, buscó la política de reembolsos dos veces, confirmó que no existía ticket, abrió uno, documentó la línea de tiempo y leyó la política correctamente. Conclusión textual del agente: el ticket fue resuelto.

Pero la base de datos dijo otra cosa: la excepción del transportista seguía abierta y el estado requerido era “on hold” (en espera), no “solved”. En la práctica, el cliente no recibió la solución que buscaba. Este ejemplo evidencia la diferencia entre buenas llamadas a herramientas y el resultado operativo real.

Métricas de consistencia: pass@1, pass@20 y observed 20/20

ThinkingBox reporta tres números clave por tarea:

• pass@1: la fracción de intentos individuales que tuvieron éxito. Responde “¿cómo se comporta usualmente?”. Esta es la métrica que suelen publicar muchos leaderboards.
• pass@20: la fracción de tareas que se resolvieron al menos una vez en 20 ejecuciones. Responde “¿puede hacerlo alguna vez?” (alcance).
• observed 20/20: cuántas tareas pasaron las 20 ejecuciones registradas. Responde “¿puede hacerlo siempre?”. En este blog se usa el conteo literal observado de tareas que aprobaron 20 de 20, sin estimadores ni suavizados.

Repetir 20 veces es la prueba de confianza: una sola ejecución correcta no garantiza que el agente sea fiable en producción.

Hallazgos clave del benchmark

Algunos resultados relevantes extraídos del estudio:

• El benchmark cubre 507 flujos de trabajo stateful ejecutados 20 veces cada uno.
• En una ablation con 121,680 intentos válidos sobre 12 modelos LLM, 79,853 intentos fallaron las comprobaciones ejecutables (executable checks).
• De esos fallos, el 67.24% terminó aparentemente sin errores, invocó una herramienta que cambia estado y no reportó error final de herramienta. Aun así, las comprobaciones encontraron:
  • valores de campo incorrectos en 77.61% de esos casos,
  • efectos extra no deseados en 43.30%,
  • efectos requeridos faltantes en 25.36%.

Es decir: en muchos casos el agente “parece” haber hecho bien su trabajo, pero los registros del sistema prueban lo contrario.

En términos de rendimiento por modelo y dominio, ThinkingBox reporta pass@1 por dominio. Algunos puntos destacados:

• Claude Opus 5.5 lidera el ranking general con 67.16% en pass@1.
• Entre modelos de peso abierto, Kimi-K3 fue el más fuerte con 57.37% en pass@1.
• Hay fuertes variaciones por dominio: por ejemplo, Claude Opus 4.6 obtiene 68.62% en retail, pero solo 8.30% en auto insurance, lo que muestra que el contexto del flujo de trabajo afecta mucho la efectividad.

Costos de buscar consistencia

Lograr que un agente sea consistente (es decir, que pase observed 20/20) implica costos técnicos y operativos: más pruebas, pipelines de validación en preproducción, monitorización de efectos en base de datos y posiblemente restricciones en la autonomía del agente (por ejemplo, pasos de confirmación humana o validaciones programáticas adicionales).

El benchmark deja claro que mejorar el pass@1 no basta: las organizaciones deben invertir en pruebas repetitivas y en comprobaciones ejecutables que verifiquen el estado final del sistema.

Firmas de fallo

ThinkingBox clasifica tipos de fallos que aparecen en producción:

• Valores incorrectos: el agente actualiza un campo con un valor equivocado (por ejemplo, marcar un ticket resuelto cuando el carrier aún tiene una excepción).
• Efectos extra: el agente crea registros innecesarios o modifica otras entidades no previstas.
• Efectos faltantes: el agente no produce cambios que la tarea exige.

Reconocer estas firmas ayuda a diseñar reglas de verificación y alertas en su propia arquitectura.

Cómo funciona y cómo ejecutarlo

ThinkingBox ejecuta agentes dentro de sesiones de herramientas aisladas y luego ejecuta comprobaciones programáticas (executable checks) sobre el backend para validar el estado. Cada tarea tiene una especificación de estado final esperada y una batería de verificaciones automáticas.

El benchmark ya está disponible a través de Hugging Face y se puede ejecutar usando OpenEnv. En la publicación original hay ejemplos reproducibles; por ejemplo, la tarea del ticket resuelto figura como sandbox_external_retail_group1.py:test_case_ST003_006, cuyo chequeo ejecutable falla en un campo (estado del ticket) que quedó en “solved” en lugar de “hold”. El rastro completo del caso se documenta en el apéndice del paper.

Implicaciones para América Latina

Para empresas latinoamericanas —bancos digitales, retail omnicanal, aseguradoras y operadores logísticos— la lección es clara: no basta con medir buenas respuestas textuales ni contar llamadas exitosas a herramientas. Deben instrumentar verificaciones del estado final, repetir pruebas y medir consistencia antes de delegar acciones críticas a agentes autónomos.

Invertir en entornos de prueba que simulen integraciones con ERPs, CRMs y sistemas de mensajería, y en pipelines que validen los efectos en bases de datos, reduce riesgos legales, financieros y reputacionales.

Conclusión

ThinkingBox cambia el estándar: pasar de evaluar agentes por lo que dicen a medirlos por lo que dejan en su backend. Sus resultados muestran que los agentes pueden parecer correctos y aun así producir resultados equivocados en la operación real. Para confiar en agentes en producción se necesita repetir, verificar el estado final y preparar controles que detecten firmas de fallo.

Si están evaluando la adopción de agentes autónomos en su empresa, considerar benchmarks como ThinkingBox y ejecutar pruebas locales con OpenEnv y Hugging Face puede ahorrar errores costosos y aumentar la confianza operacional.