No início deste ano, executamos experimentos para testar até onde era possível ampliar a cooperação entre agentes em torno de um objetivo. Nossa hipótese era que isso abriria um novo patamar de escala e complexidade nas tarefas.

O projeto principal foi um enxame de longa duração desenvolvendo um Browser do zero. Ele funcionou como prova de conceito, mas ficou muito longe de resultar em um software refinado.

Esse trabalho foi deliberadamente empírico. Partimos de uma tela em branco e fomos iterando até chegar a um sistema estável e eficaz. Desde então, nosso objetivo tem sido entender o enxame de agentes bem o bastante para projetá-lo de forma deliberada.

Para testar esse progresso, voltamos a uma tarefa com a qual o enxame antigo havia tido dificuldade: desenvolver o SQLite do zero, em Rust, usando apenas sua documentação.

Nossos resultados iniciais foram promissores. Executamos os enxames antigo e novo na mesma tarefa, com os mesmos modelos e o mesmo orçamento de tempo, e medimos quanto de uma suíte de testes SQL separada cada um conseguia passar.

O novo enxame teve desempenho melhor em todas as configurações de modelo. Usando o Grok 4.5, ele chegou a 80% em quatro horas, enquanto o enxame antigo entrou em espiral e precisou ser pausado antes de completar a segunda hora.

Também variamos quais modelos faziam quais tarefas. Em algumas execuções, um modelo cuidava de tudo; em outras, um modelo de ponta planejava enquanto um modelo rápido e barato executava o trabalho. Todas as combinações produziram qualidade semelhante, mas os custos variaram enormemente.¹

#Árvores e folhas

As descrições de tarefas grandes naturalmente assumem a forma de árvores, com um objetivo na raiz que se subdivide recursivamente em unidades básicas de trabalho. Nosso enxame tem duas funções, ambas organizadas em torno dessa mesma decomposição em árvore:

• Agentes planejadores, impulsionados pelos modelos mais inteligentes, dividem um objetivo em partes e as delegam.
• Agentes executores, geralmente impulsionados por modelos mais rápidos e menos caros, executam essas partes.

A arquitetura é um superconjunto de sistemas de orquestração mais rígidos. Em vez de impor uma topologia fixa ao problema, a forma do enxame cresce para acompanhar os contornos do problema, e os recursos computacionais e o contexto escalam em proporção à complexidade da tarefa.

Acreditamos que é por isso que essa arquitetura se generaliza para tarefas tão diversas quanto desenvolver um Browser, resolver problemas matemáticos e otimizar kernels de GPU. Também a usamos internamente para encontrar e corrigir vulnerabilidades em software de código aberto, aumentar a cobertura de testes na nossa própria base de código e gerar bilhões de tokens de dados sintéticos de treinamento.

#O que a árvore faz pela memória

Quando um único agente assume uma tarefa completa, ele precisa percorrer toda a árvore sozinho, descendo até cada folha enquanto mantém seus ancestrais, sua posição atual e o objetivo mais amplo no contexto o tempo todo.

Achamos que isso explica por que agentes únicos de longa duração acabam se perdendo. Eles podem se concentrar no trabalho à sua frente e perder de vista o panorama geral, ou manter o panorama geral em mente e fazer um trabalho pior naquela parte específica.

Em um enxame, um planejador nunca implementa, então seu contexto nunca se enche de detalhes de baixo nível, e um executor nunca planeja, então pode dedicar todo o seu contexto a uma única parte restrita do trabalho.

Suspeitamos que a capacidade de escalar o enxame de agentes venha mais dessa eficiência no uso do contexto do que do próprio paralelismo. Essa eficiência está presente no enxame em qualquer escala, e é por isso que essa decomposição ajuda a performance dos agentes até mesmo em tarefas de tamanho moderado.

Há ecos dessa estrutura em outros lugares. O economista Ronald Coase, ao perguntar por que as empresas existem, afinal, argumentou que os custos de coordenação crescem mais rápido do que o próprio trabalho, então as organizações acabam se estruturando em níveis de unidades delimitadas, em vez de deixar todo mundo falar com todo mundo.

#Um sistema de controle de versão para agentes

Em uma postagem anterior sobre o enxame, observamos que ferramentas como Git e Cargo dependem de bloqueios amplos para o controle de concorrência. Isso funciona bem para um desenvolvedor, mas é inviável para o volume de trabalho produzido por centenas de agentes concorrentes.

O enxame no navegador do início deste ano chegou a cerca de 1.000 commits por hora no Git. O novo sistema chega a cerca de 1.000 commits por segundo.

Para viabilizar esse ritmo de atividade, desenvolvemos um novo sistema de controle de versão (VCS) do zero. A vazão não foi o único motivo para termos controle sobre essa camada. Toda alteração no sistema passa pelo VCS, então é nele que os conflitos se tornam visíveis pela primeira vez, e vários dos mecanismos de coordenação da próxima seção são implementados diretamente nele.

#Modos de falha a 1.000 commits por segundo

Equipes de engenharia humanas têm mecanismos padrão de coordenação, como revisão de código, definição de responsáveis, reuniões de alinhamento e filas de merge. Esses sistemas funcionam em ritmo humano, mas, no ritmo de commits do enxame, vemos modos de falha que equipes humanas normalmente não enfrentam.

#Divergência de design

Dois planejadores, sem ter conhecimento um do outro, implementam o mesmo conceito de formas diferentes em partes distintas da base de código.

Corrigimos isso por meio de prompting. Os planejadores tomam as decisões de design por conta própria, em vez de delegá-las, e exigimos que garantam que não haja duas subárvores delegadas decidindo a mesma questão.

#Contenção entre planejadores

Uma forma mais complexa de contenção acontece quando dois planejadores sabem da existência um do outro e entram em conflito com alterações de ida e volta nos mesmos arquivos.

O problema é haver duas visões da realidade, e a ferramenta de merge não consegue resolver essa divergência. Em vez disso, fazemos com que os agentes registrem decisões em documentos de design compartilhados. O código que depende de uma decisão mantém uma referência ao respectivo documento, verificada em tempo de compilação. Quando planejadores se contradizem sem perceber, um reconciliador faz o merge dos documentos, e as referências propagam a resolução para as etapas seguintes.

#Conflitos de merge

Dentro do enxame, os agentes acabam constantemente esbarrando nos mesmos arquivos. Para resolver uma colisão, eles teriam que parar, absorver o contexto do outro agente e fazer o merge com base nele. Os agentes executores não lidam bem com isso e, na prática, ou sobrescrevem a alteração do outro ou abandonam a própria.

Para corrigir isso, criamos um sistema em que um agente neutro e independente intervém nos conflitos de merge e os resolve em nome de todas as partes. Seu único objetivo é ser imparcial e eficiente, de forma semelhante a como as filas de merge funcionam em equipes de engenharia.

#Megaarquivos

Alguns arquivos são pontos particularmente populares para os agentes trabalharem. Cada agente pode adicionar apenas uma pequena quantidade de código, e nenhum agente, isoladamente, é responsável por manter os arquivos pequenos.

Esses “megaarquivos” travam tudo. Eles são custosos de transportar, comparar e mesclar, e acabam se tornando palco de colisões constantes.

Para corrigir isso, demos aos agentes executores uma forma de sinalizar arquivos inchados. Depois de sinalizados, bloqueamos novos commits, e um agente externo decompõe o arquivo que cresceu demais em módulos menores.

#Ossificação

Os agentes aprenderam, ao trabalhar em bases de código existentes com humanos no processo, a não mexer no código principal, mesmo quando ele precisa ser alterado.

Para corrigir isso, permitimos quebras intencionais. Um agente que julgue que uma mudança no código principal vale a pena pode fazer um patch pontual fora do seu escopo e deixar um comentário explicando por que fez isso.

O compilador propaga a alteração pelo restante do sistema, e tudo o que depende do design antigo deixa de compilar. Cada agente que encontra um desses erros vê o comentário, lê a justificativa e atualiza sua própria parte do trabalho para se alinhar a isso.

#Lentes de revisão

Em um sistema que é ao mesmo tempo de longa duração e multiagente, os erros se acumulam, e o enxame precisa de uma forma de se corrigir antes que pequenos erros se tornem estruturais.

Experimentamos muitos tipos de lentes de revisão, como dar a um agente de revisão o histórico completo do executor, ou apenas sua saída, ou nada além da base de código. Também testamos revisores executando em modelos diferentes, com treinamentos e personalidades distintos.

Nenhuma lente isolada identifica tudo, mas lentes descorrelacionadas se somam, da mesma forma que sistemas de direção autônoma atingem confiabilidade acima da humana sem depender de um único componente perfeito. Os recursos computacionais gastos com revisão têm alto retorno, já que revisar é muito mais barato do que o trabalho que está sendo auditado. Suspeitamos que esse sistema de revisão em camadas tenha sido um contribuinte importante para a qualidade sustentada das execuções.

#Deixando os agentes moldarem o ambiente

Estigmergia é o mecanismo pelo qual organismos que vivem em enxames, como formigas e cupins, se coordenam sem comunicação direta. Eles moldam o ambiente, e o ambiente molda o próximo organismo.

Havíamos codificado regras como “manter notas” e “documentar decisões” em execuções anteriores porque pareciam obviamente boas. Em retrospecto, elas permitiam que os agentes institucionalizassem conhecimento para si mesmos no futuro e para seus colegas de equipe.

Levamos isso adiante com um experimento de contexto compartilhado e escrito pelos próprios agentes, que chamamos de Field Guide. É uma pasta que pertence inteiramente aos agentes, cujo index.md é injetado automaticamente em cada agente ao iniciar. Cabe aos agentes decidir o que entra no guia, e a única restrição é um limite de linhas.

A lógica por trás do guia é que os pesos do modelo são fixos, então são justamente os encontros inesperados que vale a pena registrar para encurtar a próxima trajetória do agente.

O Field Guide é um experimento inicial com resultados promissores. Esperamos que os benefícios sejam ainda maiores em bases de código que os agentes não controlam por completo. Treinar modelos para escrever para seus sucessores, em que um registro melhor leva a recompensas melhores, é uma área interessante para pesquisas futuras.

#O experimento com SQLite

Instruímos a nova versão do enxame, equipada com todas as melhorias descritas acima, a implementar todo o manual de 835 páginas do SQLite em Rust. Não demos acesso ao código-fonte, às suítes de testes, ao binário do SQLite nem à internet.

Para medir o progresso, avaliamos com base no sqllogictest, uma suíte de testes do projeto SQLite desenvolvida para verificar se diferentes motores de banco de dados retornam os mesmos resultados para as mesmas consultas. Ela contém milhões de consultas com respostas corretas já conhecidas, e a nota corresponde à fração que o banco de dados do enxame acerta. O progresso aparece como uma curva ascendente ao longo de uma execução.

O enxame nunca foi informado de que a suíte existia. Após cada execução, revisamos manualmente o código e a própria execução, verificando se houve trapaça e atalhos, e confirmando que o sistema foi desenvolvido de forma equilibrada, em vez de apenas nas partes que os testes cobrem.

Ao ler as curvas, tenha em mente que os agentes escolheram suas próprias estratégias. Alguns construíram bases amplas e ficaram com pontuações baixas por horas antes de um pico tardio, enquanto outros se aprofundaram em uma área, pontuaram cedo e depois entraram em platô enquanto completavam o restante. As tendências importam mais do que as pontuações exatas em momentos exatos.

#Resultados em diferentes combinações de modelos

Testamos quatro configurações que equilibram capacidade e custo:

1. GPT-5.5 como planejador e executor. Um modelo de ponta robusto do início ao fim.²
2. Grok 4.5 como planejador e executor. Nosso modelo de ponta com bom custo-benefício, como referência de comparação.
3. Opus 4.8 como planejador e Composer 2.5 como executor. Julgamento de ponta combinado com execução eficiente.
4. Fable 5 como planejador e Composer 2.5 como executor. Para ver se um planejador de uma categoria abaixo torna o híbrido mais ou menos vantajoso.

O novo harness superou o antigo em todas as combinações.

O híbrido com Fable 5 passou em cerca de dois terços da suíte na primeira hora. Ao fim do limite de quatro horas, as novas execuções ficaram entre 73% e 85%, enquanto as antigas variaram de 11% a 77%.

A execução antiga com Grok 4.5 foi pausada antes de completar duas horas (mais detalhes abaixo). Todas as novas configurações acabaram atingindo 100% da suíte.

No futuro, gostaríamos de executar a matriz N×N completa de combinações entre planejador e executor. Neste ciclo, a comparação que importa é entre as versões do harness, e as diferenças de comportamento acabaram sendo muito maiores do que as diferenças de pontuação sugerem.

#Uma análise detalhada das execuções

Começando pela medida mais simples de atividade, podemos ver como a taxa de commits variou para o Grok 4.5 no harness antigo em comparação com o novo. A execução antiga produziu 68.000 commits nas duas primeiras horas — cerca de 70 vezes o ritmo da nova execução.

Uma interpretação é que ela foi mais produtiva. Outra é que a maior parte desses commits foi trabalho improdutivo (thrash, contenção, churn).

Os dados de conflitos de merge apontam para a segunda interpretação. A execução antiga acumulou mais de 70.000 conflitos antes de ser pausada, acelerando em vez de se estabilizar, enquanto a nova execução registrou menos de mil ao longo de suas quatro horas completas.

Os conflitos se concentraram onde os arquivos mais cresceram. Na execução antiga, os maiores arquivos continuaram crescendo durante toda a execução, e o arquivo mais disputado acumulou sozinho 7.771 conflitos, com alterações de 1.173 agentes diferentes. Na nova execução, o arquivo mais disputado de toda a base de código teve 47.

A maior falha de coordenação do enxame antigo — divergência de design, ou planners duplicando o trabalho uns dos outros — apareceu na estrutura de pacotes. O código Rust é organizado em pacotes chamados crates e, em um projeto como este, cada crate corresponde mais ou menos a um componente principal.

A execução antiga chegou a 54 crates, incluindo três pacotes SQL separados. A nova execução convergiu para nove crates logo no início e nunca acrescentou outro.

Tudo isso aparece na base de código final. No mix Fable 5, tanto o enxame antigo quanto o novo acabaram passando na suíte completa, mas o antigo precisou de 64.305 linhas de código do mecanismo, enquanto o novo fez isso com 9.908. O mix Opus mostra o mesmo padrão, com 19.013 linhas e nota de 97% no harness antigo, e 4.645 linhas e 100% no novo harness.

#Economia dos modelos

Dissemos no início que toda combinação de modelos produziu qualidade semelhante, enquanto os custos variaram enormemente: de $1,339noh\acute{ı}bridocomOpus4.8a$10,565 usando apenas GPT-5.5. Os dados de tokens mostram de onde vem essa diferença.

A estrutura dos gastos foi consistente em todas as execuções, com os executores respondendo por pelo menos 69% dos tokens e, na maioria dos casos, por mais de 90%.

Mas a divisão em dólares foi diferente da divisão em tokens, porque os tokens do planejador custam mais. Na combinação de Opus 4.8 e Composer 2.5, o Opus como planejador gerou uma pequena fração dos tokens, mas cerca de dois terços do custo, enquanto o Composer como executor ficou com a grande maioria dos tokens pelo terço restante do custo.

Poucos momentos em uma tarefa grande realmente exigem inteligência de ponta, como a decomposição inicial, as decisões de design e certos trade-offs. Depois que um planejador de ponta transforma a ambiguidade em uma instrução detalhada e explícita, modelos mais baratos simplesmente precisam segui-la. Essa é uma enorme fonte potencial de economia. Na execução que usou GPT-5.5 tanto para planejadores quanto para executores, só os executores custaram $9,373.Naexecu\stackrel{\backslash c}{c}\tilde{a}oemqueoOpus4.8fezoplanejamentoeoComposer2.5fezotrabalho,todaafrotadeexecutorescustou$411.

Um detalhe que vale destacar surge da comparação entre as duas execuções híbridas. O planejador Fable 5 gerou uma conta um pouco menor que o planejador Opus 4.8, apesar de o preço por token ser aproximadamente o dobro, porque usou muito menos tokens de planejamento. Mas os executores da execução com Fable consumiram várias vezes mais tokens, e a execução como um todo acabou sendo substancialmente mais cara.

#Especificações como prompts

Cada salto na capacidade da IA elevou o nível de abstração em que um engenheiro pode trabalhar.

O autocompletar permitiu que engenheiros trabalhassem uma linha de código por vez. Os primeiros modelos elevaram isso para um bloco de código, e os agentes elevaram isso para um arquivo ou um recurso.

Com enxames, a unidade de trabalho passa a ser a especificação.

Para que isso funcione, o enxame precisa realmente seguir a especificação, e é disso que trata boa parte desta postagem. Demos ao enxame 835 páginas de texto e ele voltou com um banco de dados. O que era escasso neste experimento, e o que esperamos que seja escasso na engenharia de software daqui para frente, é a forma certa de descrever a intenção.

Visto dessa forma, o enxame começa a se parecer com um compilador. Um compilador traduz código-fonte em código de máquina por meio de uma série de etapas intermediárias. O enxame faz algo semelhante com a intenção. Planejadores analisam um objetivo em árvores de tarefas e depois o transformam, passo a passo, em trabalho executável. A diferença é que um compilador preserva o significado em cada etapa, enquanto o enxame é probabilístico em todas elas. Tudo o que é descrito nesta postagem existe para fechar essa lacuna.

Convidamos você a explorar a saída do enxame. A base de código da execução solo do Opus 4.8 está pública em github.com/cursor/minisqlite. Com base na nossa primeira impressão, ela parece ótima, mas não fizemos uma análise manual mais aprofundada. Dê uma olhada você mesmo e nos diga o que encontrar.