65 % una vez, 25 % siempre: Microsoft ejecutó 507 tareas de agente veinte veces cada una
By Surya Pratap
27 de agosto de 2026
12 min de lectura
IA y tecnología
27 de agosto de 2026
12 min de lectura
La cifra de la demo y la cifra del productoHover to exploreMicrosoft publicó la semana pasada un benchmark con el título menos ambiguo que se recuerda: «One Success Isn't Reliability», es decir, un acierto no es fiabilidad.
El artículo (arXiv 2608.19741, 20 de agosto de 2026) presenta Thinkingbox, un sandbox de código abierto para agentes que trabajan en flujos de negocio con estado, más un benchmark de 507 tareas que lo acompaña. Ambos están en GitHub.
El resultado de titular son dos cifras del mismo modelo sobre las mismas tareas:
65,36 % pass@1. 25,25 % pass^20.
Acierta al primer intento unas dos de cada tres veces. Acierta en los veinte intentos aproximadamente una de cada cuatro veces. Si alguna vez ha enseñado un agente con éxito y luego lo ha visto descarrilar delante de un cliente, esa distancia es la explicación completa, y por fin alguien la ha medido.
Casi todos los benchmarks de agentes evalúan la transcripción. ¿Llamó el agente a las herramientas correctas? ¿Dijo que había terminado? ¿Parecía correcto el mensaje final?
Thinkingbox evalúa la base de datos.
Cómo se ejecuta realmente una tarea de Thinkingbox
Cinco elementos combinados que suelen probarse por separado
Y después repite todo el proceso veinte veces, reiniciando el backend entre ejecuciones.
Ese diseño es la aportación. Todo lo interesante de los resultados se deriva de esas dos decisiones: comprobar el estado y repetir.
Las 507 tareas abarcan cinco dominios: retail y comercio electrónico (98 tareas), viajes y hostelería (104), seguros de automóvil (100), TI interna de un neobanco (104) y soporte de TI y RR. HH. en consultoría (101).
Se ejecutaron más de una docena de modelos, propietarios y de pesos abiertos. El reparto publicado:
Lo que hay que mirar es la proporción, no el ranking. En toda la tabla, el pass^20 se sitúa entre un tercio y una décima parte del pass@1. Sea cual sea la cifra de precisión que haya visto citada para un agente, la que experimentan sus usuarios con el uso repetido es sensiblemente menor, y este es el primer benchmark que he visto que cuantifica ese descuento.
Este es el hallazgo que yo pondría en una diapositiva.
El mejor modelo acertó al menos una vez en unas nueve de cada diez tareas. Acertó en las veinte ejecuciones en aproximadamente una de cada cuatro.
Es decir, la población interesante no son ni las tareas fiables ni las imposibles. Son las 334 tareas —dos tercios del benchmark— cuyo resultado oscilaba entre intentos.
Por qué esa franja es donde muere la credibilidad
Una tarea que siempre funciona es una funcionalidad. Una tarea que nunca funciona es una limitación conocida que se puede rodear con el diseño. Una tarea que funciona casi siempre es la que enseñará con éxito, lanzará con confianza y después tendrá que explicarle a un cliente. Dos tercios de los flujos de negocio realistas caen en esa franja para el mejor modelo disponible, lo que significa que el resultado por defecto de construir una demo es una demo que funciona y que no le dice casi nada.
Si alguna vez se ha preguntado por qué los pilotos de agentes convierten tan mal a producción, esta es una respuesta mecánica. Los pilotos son cortos, supervisados y de muestra pequeña. Muestrean las buenas ejecuciones.
Vamos con la parte de consecuencias de ingeniería más directas.
El 80,88 % de los intentos fallidos terminó limpiamente. La conversación acabó con normalidad. Las llamadas a herramientas que cambian el estado se ejecutaron y devolvieron éxito. No saltó nada. El estado final era, sencillamente, incorrecto.
La conclusión del propio artículo es tajante: las señales a nivel de respuesta y de llamada a herramienta no son buenos indicadores de la finalización de la tarea de extremo a extremo.
Desglosado, los modos de fallo dominantes fueron:
Lea esos dos juntos y se cae una suposición muy extendida. La observabilidad de agentes de la mayoría de los equipos consiste en trazar llamadas a herramientas e inspeccionar transcripciones. Frente a esta distribución de fallos, eso captura aproximadamente uno de cada cinco. Los otros cuatro son idénticos a los aciertos —mismo cierre limpio, mismas llamadas válidas— y lo único que los distingue es el estado de la base de datos al terminar.
Esta es además la respuesta honesta a la encuesta que tratamos ayer, en la que el 85,5 % de los ingenieros declaraba confiar en lo que produce el agente. Por supuesto que confían. Cuatro de cada cinco fallos son invisibles desde donde están.
El éxito varió muchísimo según el dominio: en torno a un 52 % de éxito medio en retail frente a alrededor de un 23 % en seguros de automóvil.
Eso es más del doble de diferencia con los mismos modelos y el mismo arnés, y conviene entenderlo en lugar de promediarlo. Los flujos de retail tienden a ser más cortos, más indulgentes y menos sujetos a política. Los de seguros son largos, están condicionados por reglas y llenos de pasos en los que un valor equivocado al principio envenena en silencio todo lo que viene después.
La traducción práctica para un fundador: la cifra de su dominio no es la cifra del titular. Si lo que automatiza se parece a un proceso de siniestros —de varios pasos, con puertas de política, cargado de estado—, el mensaje del benchmark es que espere la parte baja del rango, y que le conviene descubrirlo antes de que lo haga su cliente.
Tres salvedades, porque un benchmark llamativo invita a leer de más.
Los modelos probados no son la frontera actual. La tabla está construida sobre GPT-5.4 y la generación Claude 4.6. La frontera se ha movido desde entonces: GPT-5.6 y Claude Opus 5 llegaron después de este trabajo. Las cifras absolutas ya son históricas. Si la proporción entre pass@1 y pass^20 mejora con modelos más nuevos es la pregunta realmente abierta, y aquí no hay nada que la responda.
La posición en el benchmark no es un ranking de capacidad. Claude Opus 4.6 puntúa por debajo de Claude Sonnet 4.6 (37,91 % frente a 58,45 % pass@1), lo que debería hacer que cualquiera se tome esto con cautela como tabla clasificatoria. El encaje con el arnés, el formato del prompt y las convenciones de llamada a herramientas mueven estas cifras. Tome la forma del hallazgo como sólida y el orden como propio de este montaje.
Es una simulación. Los backends aislados y un usuario simulado son enormemente mejores que unos casos de prueba estáticos, y siguen sin ser su sistema de producción con sus datos y sus usuarios. La dirección del error es desconocida: los flujos reales podrían ser más fáciles porque los usuarios aclaran, o más difíciles porque la realidad es más sucia que un simulador.
La tercera tarjeta es la de mejor retorno. No es un problema de modelo y no necesita un prompt mejor. Si una llamada a herramienta falla y su orquestación deja que el agente siga, ha construido una máquina de producir respuestas equivocadas con seguridad, y el benchmark dice que eso explica tres cuartas partes de lo que sale mal.
Microsoft ha construido el benchmark de agentes que evalúa lo que importa —lo que cambió en el sistema— y después lo ha ejecutado todo veinte veces para ver si se sostiene. Ambas decisiones parecen obvias vistas de lejos y ninguna era lo habitual.
Los resultados: el mejor modelo disponible entonces acertó a la primera el 65,36 % de las veces y acertó siempre el 25,25 % de las veces. Dos tercios de las tareas parpadearon entre ejecuciones. Cuatro de cada cinco fallos terminaron limpiamente, con llamadas válidas, y parecerían aciertos en cualquier monitorización basada en transcripciones que tenga desplegada.
Nada de eso significa que los agentes no funcionen. Significa que una demo no es evidencia, que la precisión a un solo intento era la métrica equivocada que se venía citando y que la observabilidad que ha construido la mayoría de los equipos no puede ver los fallos que de verdad ocurren.
El arreglo no es exótico. Ejecútelo veinte veces. Compruebe la base de datos. Detenga al agente cuando una herramienta diga que no.
Fuentes: arXiv 2608.19741, «One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows» · microsoft/thinkingbox en GitHub · Las notas por modelo, el desglose de las 507 tareas, la cifra del 80,88 % de terminación limpia y las medias por dominio son las publicadas en el artículo y su análisis acompañante; las salvedades de la sección 6 son mías.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
