AOS-Bench muestra que agentes con 0,6 puntos de diferencia entregan el 54% y el 68% de las tareas

Los agentes de programación están pasando de ejecutar peticiones puntuales a convertirse en asistentes permanentes a los que se les lanza un flujo de trabajo: compilación, procesamiento de datos y corrección de errores a la vez, todo en una sola máquina. Un equipo de cinco autores, liderado por Erle Zhu, ha publicado AOS-Bench, un benchmark que evalúa el sistema agéntico precisamente como gestor de ese tipo de carga. El resultado principal: el éxito en aislamiento predice mal el éxito en flujo continuo. En cargas pesadas, cada uno de los cinco sistemas probados pierde entre 13 y 23 puntos.

Por qué las pruebas habituales no ven la cola

Los benchmarks existentes ejecutan cada tarea por separado, en un entorno limpio y con todos los recursos disponibles. El trabajo real es distinto. Las tareas llegan a lo largo del tiempo, y es el propio agente quien decide cuándo tomar una nueva, cómo delegarla y qué tareas lanzar en paralelo. Además, debe respetar los límites de procesador y memoria. Si lanza demasiadas, la máquina se satura. Si lanza muy pocas, parte de las tareas nunca llega a tocarse.

AOS-Bench está diseñado para que las tareas verificadas lleguen a lo largo del tiempo y deban entregarse bajo límites compartidos de CPU y memoria. Esas mismas tareas, ejecutadas una a una, sirven de referencia para cada sistema concreto. La diferencia entre el resultado aislado y el de flujo continuo indica cuánta capacidad del agente se pierde en la gestión.

Dónde se pierden los puntos

Los autores probaron cinco pares «modelo–harness». El panorama resultó desigual:

• en cargas pesadas, cada sistema pierde entre 13 y 23 puntos respecto a su éxito en aislamiento;
• en cargas medias, los sistemas difieren en 11 puntos en éxito aislado, pero ya en 26 puntos en flujo continuo;
• dos sistemas con 0,6 puntos de diferencia en aislamiento entregan el 54% y el 68% de las mismas tareas;
• con despacho secuencial, el 73% de las tareas de la carga pesada queda sin ponerse en marcha;
• una concurrencia fija igual a dos se queda, como máximo, 4 puntos por debajo de la mejor política con gestión por parte del agente, tanto en cargas medias como en pesadas;
• con cualquier política, la carga mediana de CPU permanece por debajo del 30% de los núcleos asignados mientras las tareas esperan su turno.

Las intervenciones sobre la política de ejecución mostraron que buena parte de la brecha se explica por la admisión de tareas. Simplemente, el agente no llega a tomar —o no decide tomar— el trabajo que espera en la cola. La calidad de la solución en sí es aquí secundaria.

Una cola simple frente a un gestor inteligente

La conclusión más incómoda tiene que ver con la complejidad. Cabía esperar que un agente que planifica por sí mismo el solapamiento de tareas y reparte los recursos superase con claridad a un esquema primitivo. En la práctica, un límite fijo de dos tareas simultáneas se acerca a cuatro puntos de la mejor gestión agéntica. Mientras tanto, la máquina permanece mayormente ociosa: los núcleos están ocupados menos del 30% en mediana, aunque hay trabajo pendiente en la cola.

Es decir, el cuello de botella está en la decisión de «tomar o esperar», y no en la falta de hardware. Los agentes son demasiado cautelosos o estiman mal qué se puede ejecutar a la vez, y dejan recursos sin usar.

Los autores concluyen que la gestión de la carga debe considerarse una capacidad independiente de los agentes, que hay que medir por separado de la habilidad para resolver tareas. Dos sistemas con un resultado casi idéntico en aislamiento se comportan de forma completamente distinta en flujo continuo, y las clasificaciones habituales no lo muestran.

La conclusión práctica para los equipos que despliegan agentes de programación permanentes: elegir un sistema a partir de benchmarks de tareas individuales no basta. Conviene comprobar cómo se comporta con varias tareas en paralelo en una máquina real. Hay que observar la proporción de tareas que llegaron a ponerse en marcha y la carga de CPU durante la espera. Antes de construir una orquestación compleja, resulta útil compararla con una cola rígida de dos slots: según AOS-Bench, esa línea base resulta sorprendentemente fuerte. Para los desarrolladores de harnesses, la prueba señala un punto concreto de mejora: la política de admisión de tareas, donde se pierde hasta el 73% del trabajo potencial.

El preprint se publicó en arXiv el 23 de octubre de 2026, y la segunda versión apareció el 27 de octubre.