AOS-Bench pone a prueba a los agentes de IA: el rendimiento cae entre 13 y 23 puntos con tareas en paralelo

La pregunta práctica detrás de AOS-Bench

Un equipo de investigadores se planteó una pregunta práctica: ¿qué tan preparados están los agentes de IA que escriben código y controlan una computadora para trabajar no con una tarea a la vez, sino con un flujo de tareas, como ocurre en la vida real, cuando mientras se compila un proyecto llega una solicitud para procesar datos y después otra para corregir un error? Todos los benchmarks existentes para este tipo de agentes (como Terminal-Bench u OSWorld) evalúan las tareas de forma aislada, por lo que nadie había medido antes si un agente es capaz de manejar varios asuntos a la vez con recursos limitados. Para eso se creó AOS-Bench, un benchmark que simula el funcionamiento del agente como una especie de "sistema operativo en lenguaje natural" que debe decidir por sí mismo cuándo tomar una nueva tarea, cómo repartir el trabajo entre subtareas y cómo no exceder la CPU y memoria disponibles.

Cómo se diseñó el experimento

Se probaron cinco combinaciones de "modelo + entorno de agente": Claude Opus 5, GPT-5.6-sol, DeepSeek-V4-Pro, GLM-5.3 y Kimi-K3. A cada sistema se le asignó un límite de 4 núcleos de CPU y 8 gigabytes de memoria. En un caso, las tareas llegaban estrictamente de una en una (esto sirvió de referencia del rendimiento "individual"); en el otro, varias tareas llegaban una tras otra a intervalos, como en un entorno de trabajo real ("flujo"). Se usaron dos niveles de dificultad: medio (10 tareas por ejecución) y alto (20 tareas).

Lo que muestran las cifras

Bajo carga alta, cada uno de los cinco sistemas perdió entre 13 y 23 puntos porcentuales de soluciones exitosas en comparación con lo que ese mismo sistema logra con las mismas tareas resueltas de una en una. Claude Opus 5 fue el que mejor se desempeñó: su tasa de éxito cayó de 75,5% en tareas individuales a 62,5% en modo de flujo, es decir, conservó aproximadamente el 83% de su capacidad base. Los otros cuatro sistemas conservaron solo entre el 61% y el 75% de su nivel base.

Con carga media, los resultados fueron aún más revelidores: lo bien que un sistema resuelve tareas individuales prácticamente no predice qué tan bien se desempeñará con un flujo de tareas. GPT-5.6-sol obtuvo el resultado más alto en tareas individuales, 85,3%, pero pierde 14,5 puntos en modo de flujo. Kimi-K3, con un resultado base 11 puntos más bajo, pierde apenas 6,3 puntos en flujo. El ejemplo más llamativo: dos sistemas cuyo éxito en tareas individuales difiere apenas 0,6 puntos (74,9% frente a 74,3%) terminan en 68,1% y 53,9% en modo de flujo, una brecha de casi 15 puntos que no debería existir.

Por qué sucede esto

La causa principal no es que los agentes resuelvan peor las tareas en sí. Los autores desglosaron cada punto de pérdida por causa y descubrieron que la mayor parte de la brecha bajo carga alta —entre 16 y 26 de los 16-23 puntos perdidos por cuatro de los sistemas— corresponde a tareas que el agente nunca llegó a tomar, que no terminó antes de agotarse el tiempo, o que terminó después de que la memoria ya se había saturado. Los errores propiamente dichos al ejecutar las tareas que sí tomó representan una pérdida de no más de 1,3 puntos.

Dicho de forma simple: estos sistemas no tropiezan al resolver las tareas, sino al no ponerse a trabajar en ellas a tiempo.

GLM-5.3 y DeepSeek-V4-Pro resultan especialmente ilustrativos: en algunas ejecuciones, simplemente dejaron de aceptar tareas nuevas y volvieron a procesarlas de una en una, dejando sin atender el 25% y el 48% de las tareas recibidas respectivamente (frente al 0% de Claude Opus 5). Además, cuando las mismas tareas se entregaban todas a la vez de forma forzada (sin cola secuencial), los sistemas tomaban tres cuartas partes de ellas, lo que indica que el problema no está en la dificultad de las tareas, sino específicamente en la lógica para aceptar trabajo nuevo.

El hallazgo inesperado sobre la gestión "inteligente"

Parecería lógico pensar que la solución es enseñar al agente a planificar la concurrencia de forma más inteligente. Pero el experimento mostró lo contrario: la regla más simple posible —"ejecutar exactamente dos tareas a la vez sin ningún análisis"— queda a solo 4 puntos de las mejores estrategias en las que el propio agente decide qué ejecutar y cuándo. Además, sin importar la estrategia de gestión usada, mientras las tareas esperan su turno la CPU se usa por debajo del 30% de los cuatro núcleos asignados: los recursos quedan ociosos incluso cuando hay trabajo de sobra.

Para los equipos que planean construir agentes de IA persistentes para trabajo real con múltiples tareas simultáneas, la conclusión es pragmática: no conviene invertir de entrada en una lógica compleja de planificación de tareas dentro del agente, ya que una simple limitación de la concurrencia da resultados casi igual de buenos. Lo que realmente hay que arreglar primero es el mecanismo de aceptación y confirmación de nuevas tareas, que es donde se pierde la mayor parte de la eficiencia.