A principios de este año, realizamos experimentos para poner a prueba hasta dónde podían escalar los agentes al cooperar hacia un objetivo común. Nuestra hipótesis era que esto abriría un nuevo nivel de escala y complejidad en las tareas.

El proyecto principal fue un enjambre de larga duración para crear un navegador web desde cero. Funcionó como prueba de concepto, pero quedó muy lejos de convertirse en software pulido.

Ese trabajo fue deliberadamente empírico. Partimos de un lienzo en blanco y fuimos avanzando de forma iterativa hacia un sistema estable y eficaz. Desde entonces, nuestro objetivo ha sido entender lo bastante bien el enjambre de agentes como para diseñarlo de forma deliberada.

Para poner a prueba ese progreso, volvimos a una tarea con la que el antiguo enjambre había tenido dificultades: crear SQLite desde cero, en Rust, sin más base que su documentación.

Nuestros resultados iniciales han sido prometedores. Ejecutamos los enjambres antiguo y nuevo en la misma tarea, con los mismos modelos y el mismo presupuesto de tiempo, y medimos qué proporción de una suite de pruebas SQL de validación podía superar cada uno.

El nuevo enjambre obtuvo mejores resultados en todas las configuraciones de modelo. Con Grok 4.5, alcanzó el 80 % en cuatro horas, mientras que el antiguo enjambre se descontroló y tuvo que pausarse antes de cumplir dos horas.

También variamos qué modelos se encargaban de qué tareas. En algunas ejecuciones, un solo modelo se ocupó de todo, mientras que en otras, un modelo de vanguardia planificaba y un modelo rápido y económico ejecutaba el trabajo. Todas las combinaciones produjeron una calidad similar, pero los costos variaron enormemente.¹

#Árboles y hojas

Las descripciones de tareas grandes adoptan de forma natural la estructura de un árbol, con un objetivo en la raíz que se subdivide recursivamente en unidades básicas de trabajo. Nuestro enjambre tiene dos roles, ambos organizados en torno a esa misma descomposición en forma de árbol:

• Los agentes planificadores, impulsados por los modelos más inteligentes, dividen un objetivo en partes y las delegan.
• Los agentes worker, normalmente impulsados por modelos más rápidos y menos costosos, ejecutan esas partes.

El diseño amplía los sistemas de orquestación más rígidos. En lugar de imponer una topología fija al problema, la forma del enjambre crece para ajustarse a los contornos del problema, y los recursos de cómputo y el contexto escalan en proporción a la complejidad de la tarea.

Creemos que por eso este diseño funciona en tareas tan diversas como crear un navegador, resolver problemas matemáticos y optimizar kernels de GPU. También lo hemos usado internamente para encontrar y solucionar vulnerabilidades en software de código abierto, aumentar la cobertura de pruebas en nuestro propio código y generar miles de millones de tokens de datos de entrenamiento sintéticos.

#Qué aporta el árbol a la memoria

Cuando un solo agente asume una tarea completa, tiene que recorrer todo el árbol por sí mismo, descendiendo hasta cada hoja mientras mantiene presentes sus ancestros, su posición actual y el objetivo general en todo momento.

Creemos que esto explica por qué los agentes individuales que trabajan durante mucho tiempo acaban desviándose. O bien pueden centrarse en el trabajo que tienen delante y perder de vista el panorama general, o bien mantener el panorama general y hacer peor la parte que les toca.

En un enjambre, un planificador nunca implementa, así que su contexto nunca se llena de detalles de bajo nivel, y un worker nunca planifica, así que puede dedicar todo su contexto a una única parte concreta del trabajo.

Sospechamos que la capacidad de escalar el enjambre de agentes proviene de esta eficiencia en el uso del contexto, más que del paralelismo en sí. Esa eficiencia está presente en el enjambre a cualquier escala, por lo que esta descomposición mejora el rendimiento de los agentes incluso en tareas de tamaño moderado.

Hay ecos de esta estructura en otros ámbitos. El economista Ronald Coase, al preguntarse por qué existen las empresas, argumentó que los costos de coordinación crecen más rápido que el trabajo en sí, por lo que las organizaciones tienden a organizarse en niveles de unidades delimitadas, en lugar de dejar que todos hablen con todos.

#Un sistema de control de versiones para agentes

En una publicación anterior sobre el enjambre, señalamos que herramientas como Git y Cargo dependen de bloqueos de grano grueso para controlar la concurrencia. Esto funciona para un solo desarrollador, pero resulta inviable para el volumen de trabajo que producen cientos de agentes concurrentes.

El enjambre del navegador de principios de este año llegó a un pico de aproximadamente 1.000 commits por hora en Git. El nuevo sistema alcanza un pico de alrededor de 1.000 commits por segundo.

Para sostener este ritmo de actividad, creamos desde cero un nuevo sistema de control de versiones (VCS). El rendimiento no fue la única razón para controlar esta capa. Todos los cambios del sistema pasan por el VCS, así que es ahí donde los conflictos se hacen visibles por primera vez, y varios de los mecanismos de coordinación de la siguiente sección están implementados directamente en él.

#Modos de fallo a 1.000 commits por segundo

Los equipos humanos de ingeniería cuentan con mecanismos de coordinación estándar, como la revisión de código, la asignación de responsabilidades, las reuniones diarias y las colas de fusión. Estos sistemas funcionan a un ritmo humano, pero al ritmo de commits del enjambre vemos modos de fallo que los equipos humanos no suelen experimentar.

#Diseño split-brain

Dos planificadores, sin saber uno del otro, implementan el mismo concepto de formas distintas en diferentes partes de la base de código.

Solucionamos esto con prompts. Los planificadores toman las decisiones de diseño por sí mismos en lugar de delegarlas, y les exigimos que se aseguren de que no haya dos subárboles delegados que resuelvan la misma cuestión.

#Conflictos entre planificadores

Una forma más compleja de conflicto se da cuando dos planificadores saben de la existencia del otro y entran en una dinámica de cambios de ida y vuelta sobre los mismos archivos.

El problema es que hay dos versiones de la realidad, y las herramientas de fusión no pueden resolver un desacuerdo. En su lugar, hacemos que los agentes registren las decisiones en documentos de diseño compartidos. El código que depende de una decisión incluye una referencia verificada en compilación a su documento. Cuando los planificadores se contradicen sin saberlo, un reconciliador fusiona los documentos y las referencias propagan esa resolución aguas abajo.

#Conflictos de fusión

Dentro del enjambre, los agentes entran constantemente en conflicto sobre los mismos archivos. Para resolver una colisión, tendrían que detenerse, asimilar el contexto del otro agente e integrar sus cambios en torno a él. Los agentes worker no se manejan bien con esto y, en la práctica, o sobrescriben el cambio ajeno o abandonan el suyo.

Para solucionar esto, creamos un sistema en el que un agente neutral ajeno a las partes interviene en los conflictos de fusión y los resuelve en nombre de todos. Su único objetivo es ser imparcial y eficiente, de forma similar a cómo funcionan las colas de fusión en los equipos de ingeniería.

#Megaarchivos

Algunos archivos son puntos especialmente habituales de trabajo para los agentes. Cada agente puede agregar solo una pequeña cantidad de código, y ningún agente en particular es responsable de mantener esos archivos pequeños.

Estos “megaarchivos” lo atascan todo. Son costosos de transportar, comparar y fusionar, y se convierten en un foco de conflictos constantes.

Para solucionar esto, les dimos a los agentes de trabajo una forma de marcar los archivos sobredimensionados. Una vez marcados, bloqueamos nuevos commits y un agente externo descompone el archivo sobredimensionado en módulos más pequeños.

#Osificación

Los agentes han aprendido, al trabajar en bases de código existentes con humanos en el proceso, a no tocar el código base, incluso cuando necesita cambiar.

Para solucionar esto, permitimos la ruptura intencional. Un agente que considera que un cambio en el núcleo vale la pena puede hacer un parche puntual fuera de su ámbito y dejar un comentario explicando por qué lo hizo.

El compilador arrastra ese cambio al resto del sistema, y todo lo que depende del diseño anterior deja de compilar. Cada agente que se encuentra con uno de esos errores encuentra el comentario, lee la justificación y actualiza su propia parte del trabajo para ajustarse.

#Lentes de revisión

En un sistema que es a la vez de ejecución prolongada y multiagente, los errores se acumulan, y el enjambre necesita una forma de corregirse antes de que los pequeños fallos se conviertan en problemas estructurales.

Experimentamos con muchos tipos de lentes de revisión, como darle a un agente de revisión la transcripción completa del worker, o solo su resultado, o únicamente la base de código. También probamos revisores que se ejecutaban con distintos modelos, con distinto entrenamiento y distinta personalidad.

Ninguna lente detecta todo por sí sola, pero las lentes no correlacionadas se complementan, igual que los sistemas de conducción autónoma alcanzan una fiabilidad superior a la humana sin depender de un único componente perfecto. El cómputo dedicado a la revisión ofrece un alto retorno, ya que revisar es mucho más barato que el trabajo que se audita. Sospechamos que este sistema de revisión en capas fue uno de los principales responsables de la calidad sostenida de las ejecuciones.

#Permitir que los agentes moldeen el entorno

La estigmergia es el mecanismo por el que organismos de enjambre como las hormigas y las termitas se coordinan sin comunicación directa. Moldean el entorno, y el entorno moldea al siguiente organismo.

En ejecuciones anteriores habíamos codificado reglas como “tomar notas” y “documentar decisiones” porque parecían obviamente buenas. Visto en retrospectiva, eso permitía que los agentes institucionalizaran conocimiento para sí mismos en el futuro y para sus compañeros de equipo.

Llevamos esto un paso más allá con un experimento de contexto compartido y redactado por los propios agentes al que llamamos la Guía de campo. Es una carpeta gestionada por completo por los agentes, cuyo index.md se inyecta automáticamente en cada agente al inicio. El trabajo de los agentes es decidir qué entra en la guía, y su única limitación es un límite de líneas.

La lógica subyacente de la guía es que los pesos del modelo están fijos, así que precisamente los hallazgos inesperados son los que merece la pena registrar para que la siguiente trayectoria del agente sea más corta.

La Guía de campo es un experimento temprano con resultados prometedores. Esperamos que los beneficios sean aún mayores en bases de código que los agentes no controlan por completo. Entrenar modelos para que escriban para sus sucesores, donde una mejor captura se traduce en mejores recompensas, es una línea interesante para futuras investigaciones.

#El experimento de SQLite

Indicamos a la nueva versión del enjambre, equipada con todas las mejoras descritas anteriormente, que implementara por completo el manual de SQLite de 835 páginas en Rust. Le quitamos el acceso al código fuente, a las suites de pruebas, al binario de SQLite y a internet.

Para medir el progreso, lo evaluamos con sqllogictest, una suite de pruebas del proyecto SQLite creada para comprobar que distintos motores de bases de datos devuelvan los mismos resultados para las mismas consultas. Contiene millones de consultas con respuestas correctas conocidas, y la puntuación es la fracción de aciertos de la base de datos del enjambre. El progreso aparece como una curva ascendente a lo largo de una ejecución.

Nunca se le dijo al enjambre que esa suite existía. Después de cada ejecución, revisamos manualmente el código y la propia ejecución para comprobar que no hubiera trampas ni atajos, y para confirmar que el sistema se hubiera desarrollado de forma equilibrada, en lugar de solo en las partes que cubren las pruebas.

Al leer las curvas, ten en cuenta que los agentes eligieron sus propias estrategias. Algunos construyeron bases amplias y obtuvieron puntuaciones bajas durante horas antes de un repunte final, mientras que otros profundizaron en un área, obtuvieron buenas puntuaciones pronto y luego se estancaron mientras completaban el resto. Las tendencias importan más que las puntuaciones exactas en momentos concretos.

#Resultados en distintas combinaciones de modelos

Probamos cuatro configuraciones que equilibran capacidad y costo:

1. GPT-5.5 como planificador y worker. Un sólido modelo de vanguardia de principio a fin.²
2. Grok 4.5 como planificador y worker. Nuestro modelo de vanguardia más rentable, como punto de comparación.
3. Opus 4.8 como planificador y Composer 2.5 como worker. Criterio de vanguardia combinado con una ejecución eficiente.
4. Fable 5 como planificador y Composer 2.5 como worker. Para ver si un planificador del siguiente nivel hace que el híbrido valga más o menos la pena.

El nuevo harness superó al anterior en todas las combinaciones.

El híbrido de Fable 5 aprobó aproximadamente dos tercios de la suite de pruebas en la primera hora. Al corte de cuatro horas, las ejecuciones nuevas se situaban entre el 73% y el 85%, mientras que las anteriores iban del 11% al 77%.

La ejecución anterior de Grok 4.5 se pausó antes de las dos horas (más abajo). Todas las configuraciones nuevas terminaron aprobando el 100% de la suite de pruebas.

En el futuro nos gustaría ejecutar la matriz N×N completa de combinaciones de planificador y worker. En este ciclo, la comparación importante es entre versiones del harness, y las diferencias de comportamiento resultaron ser mucho mayores de lo que sugieren las diferencias de puntuación.

#Análisis en profundidad de las ejecuciones

Si empezamos por la medida de actividad más simple, podemos ver cómo varió la tasa de commits de Grok 4.5 con el harness antiguo frente al nuevo. La ejecución antigua produjo 68.000 commits en sus primeras dos horas, aproximadamente 70 veces el ritmo de la nueva.

Una lectura es que fue más productiva. Otra, que la mayoría de esos commits eran trabajo improductivo (agitación, contención, cambios innecesarios).

Los datos de conflictos de fusión apuntan a esta segunda interpretación. La ejecución antigua acumuló más de 70.000 conflictos antes de que la pausáramos, y además siguieron acelerándose en vez de estabilizarse, mientras que la nueva registró menos de mil en sus cuatro horas completas.

Los conflictos se concentraron en los archivos que más crecieron. En la ejecución antigua, los archivos más grandes siguieron creciendo durante toda la ejecución y el archivo con más conflictos acumuló 7.771, tocado por 1.173 agentes distintos. En la nueva, el archivo más disputado de toda la base de código tuvo 47.

El mayor fallo de coordinación del enjambre antiguo —split-brain, es decir, planificadores duplicando el trabajo de otros— apareció en la estructura de paquetes. El código Rust se organiza en paquetes llamados crates, y en un proyecto como este, cada crate equivale aproximadamente a un componente principal.

La ejecución antigua llegó a abarcar 54 crates, incluidos tres paquetes SQL distintos. La nueva se quedó con nueve crates desde el principio y no añadió ninguno más.

Todo esto se ve reflejado en la base de código final. En la combinación Fable 5, tanto el enjambre antiguo como el nuevo acabaron superando la suite completa, pero el antiguo necesitó 64.305 líneas de código del motor y el nuevo lo consiguió con 9.908. La combinación Opus muestra el mismo patrón: 19.013 líneas y una puntuación del 97 % con el harness antiguo, frente a 4.645 líneas y un 100 % con el nuevo.

#Economía de los modelos

Dijimos al principio que cada combinación de modelos producía una calidad similar, mientras que los costos variaban enormemente, desde $1,339paraelh\acute{ı}bridoOpus4.8hasta$10,565 para GPT-5.5 por sí solo. Los datos de tokens muestran de dónde proviene esa diferencia.

La estructura del gasto fue consistente en todas las ejecuciones, con los workers concentrando al menos el 69% de los tokens, y más del 90% en la mayoría de los casos.

Pero el reparto en dólares fue distinto al de los tokens, porque los tokens del planificador cuestan más. En la combinación de Opus 4.8 y Composer 2.5, Opus como planificador generó una pequeña fracción de los tokens, pero aproximadamente dos tercios del costo, mientras que Composer como worker gestionó la gran mayoría de los tokens por el tercio restante del costo.

Hay pocos momentos en una tarea grande que realmente requieran inteligencia de vanguardia, como la descomposición inicial, las decisiones de diseño y ciertas concesiones. Una vez que un planificador de vanguardia ha convertido la ambigüedad en una instrucción detallada y explícita, los modelos menos costosos simplemente tienen que seguirla. Esta es una enorme fuente potencial de ahorro. En la ejecución que usó GPT-5.5 tanto para planificadores como para workers, solo los workers costaron $9,373.Enlaejecuci\acute{o}nenlaqueOpus4.8hizolaplanificaci\acute{o}nyComposer2.5hizoeltrabajo,todalaflotadeworkerscost\acute{o}$411.

Un detalle que vale la pena señalar surge al comparar las dos ejecuciones híbridas. El planificador Fable 5 generó una factura ligeramente menor que el planificador Opus 4.8, a pesar de tener un precio por token aproximadamente el doble de alto, porque usó muchos menos tokens de planificación. Pero los workers de la ejecución con Fable consumieron varias veces más tokens, y la ejecución en su conjunto resultó sustancialmente más cara.

#Especificaciones como prompts

Cada salto en la capacidad de la IA ha elevado el nivel de abstracción en el que puede trabajar un ingeniero.

El autocompletado permitió a los ingenieros trabajar una línea de código a la vez. Los primeros modelos elevaron eso a un bloque de código, y los agentes lo llevaron a un archivo o una funcionalidad.

Con los enjambres, la unidad de trabajo pasa a ser la especificación.

Para que eso funcione, el enjambre tiene que seguir de verdad la especificación, y de eso trata gran parte de este artículo. Le dimos al enjambre 835 páginas de prosa y nos devolvió una base de datos. Lo que escaseó en este experimento, y lo que esperamos que siga escaseando en la ingeniería de software de aquí en adelante, es la descripción correcta de la intención.

Visto así, el enjambre empieza a parecerse a un compilador. Un compilador traduce el código fuente a código máquina mediante una serie de pasos intermedios. El enjambre hace algo parecido con la intención. Los planificadores descomponen un objetivo en árboles de tareas y luego lo van reduciendo paso a paso hasta convertirlo en trabajo ejecutable. La diferencia es que un compilador preserva el significado en cada paso, mientras que el enjambre es probabilístico en todos ellos. Todo lo que se describe en este artículo existe para cerrar esa brecha.

Te invitamos a explorar el resultado del enjambre. La base de código de la ejecución en solitario con Opus 4.8 es pública en github.com/cursor/minisqlite. Según nuestro primer vistazo, tiene muy buena pinta, pero no hemos hecho un análisis manual más profundo. Échale un vistazo tú mismo y cuéntanos qué encuentras.