Qué propone ThinkingBox
La idea central de ThinkingBox es sencilla: si un agente trabaja sobre un backend real y al final se puede comprobar de forma ejecutable si la base de datos quedó en el estado esperado, ese veredicto puede usarse no solo para evaluar, sino también para entrenar. El proyecto parte de esa misma señal para detectar cuándo un agente afirma haber terminado, aunque en realidad no haya dejado el sistema como debía.
ThinkingBox-Bench incluye 507 tareas con un backend real, herramientas tipo MCP y un usuario simulado con contexto privado. Al terminar cada ejecución, el sistema no juzga si las llamadas a herramientas “parecen correctas”, sino si el registro final del backend coincide con lo que debía ocurrir. Esa diferencia desplaza el foco desde la secuencia de acciones hasta el resultado verificable.
Cómo convierten el grader en recompensa
La parte técnica más relevante está en el entrenamiento. El equipo construyó un conjunto de tareas fuera del benchmark y usó su resultado ejecutable como recompensa. Para evitar que el modelo entrenara con ejemplos demasiado fáciles o imposibles, aplicó lo que llama *offline policy-relative difficulty*: estimó la probabilidad de éxito de cada tarea con la política base antes del ajuste y fijó después el conjunto de entrenamiento.
En la ejecución de referencia, el equipo afinó Qwen3.8-27B con GRPO durante 50 pasos sobre 187 tareas seleccionadas. La publicación indica que el proceso usó 24 H100 y que el stack de entrenamiento se ha publicado para reproducir la selección de datos, los *rollouts*, la recompensa y la integración con Verl. También señala que el flujo se apoya en Linux, Python 3.12 y una configuración validada para Qwen3.8.
Qué mejoró y qué empeoró
Los resultados muestran una mejora clara en repetibilidad, pero no en cobertura total. Antes del ajuste, Qwen3.8-27B completaba 38 tareas de 507 en los 20 intentos de prueba; tras el entrenamiento, llegó a 107. En porcentaje, el indicador *Observed 20/20* pasó del 7,5% al 21,1%. La media de éxito, *pass@1*, también subió del 51,70% al 60,78%.
Esa ganancia vino con una ligera pérdida de cobertura. El número de tareas resueltas al menos una vez en 20 intentos bajó de 453 a 446, es decir, del 89,35% al 87,97%. La propia publicación interpreta el patrón como una mejora de la consistencia, no como una expansión de capacidades generales: el modelo aprende a fallar menos en los mismos escenarios, pero cubre un poco menos de terreno.
La comparación con otros modelos también matiza la lectura. En la tabla del benchmark, el modelo afinado queda por debajo de algunos sistemas cerrados en *pass@1*, pero supera a varios en el número de tareas que resuelve de forma consistente en los 20 intentos. La publicación subraya que el orden cambia mucho según se mire éxito medio o estabilidad operativa.
Qué implica para agentes que tocan sistemas reales
La utilidad práctica de ThinkingBox está en el tipo de trabajo al que apunta: agentes que actúan sobre registros de producción, flujos administrativos o procesos con estados persistentes. En ese contexto, la calidad no depende solo de que una respuesta suene bien, sino de que el backend termine exactamente donde debe. El ejemplo que ofrece la publicación es un caso de reservas: antes del ajuste, el agente cambiaba una reserva y emitía reembolsos sin la aprobación exigida; después del entrenamiento, preservó el estado correcto en las 20 ejecuciones.
El coste también forma parte de la evaluación. La publicación calcula que la campaña bajó de 925,80 a 855,58 dólares y que el coste por tarea fiable cayó de 24,36 a 8 dólares. Son cifras internas del experimento, no un precio comercial del sistema, pero ayudan a entender por qué el enfoque interesa: no solo mejora la consistencia, también abarata medirla y entrenarla.
Lo que queda por comprobar
Lo que está confirmado es el resultado de laboratorio y la disponibilidad del stack de trabajo. Lo que no está demostrado todavía es cómo se comportará este método en otros dominios, con otras políticas base o en entornos donde la comprobación final no pueda reducirse a un estado de base de datos tan claro. La propia publicación deja abierta esa siguiente fase: extender el enfoque a más tareas y evaluar hasta qué punto la recompensa derivada del estado final puede generalizar fuera de ThinkingBox.
