Swarm de agentes: novo paradigma de engenharia com planner + workers

Arquitetura planner + workers

A Cursor publicou os resultados de uma nova geração do seu sistema de enxame de agentes, testado na tarefa de reimplementar o SQLite do zero em Rust a partir de 835 páginas de documentação. A arquitetura separa duas funções: agentes planejadores, movidos por modelos de ponta, decompõem o objetivo em árvores de tarefas; agentes executores, movidos por modelos rápidos e baratos, implementam cada folha. A separação resolve um problema central de agentes únicos de longa duração - a sobrecarga de contexto. Um planejador nunca se enche de detalhes de implementação; um executor dedica todo o contexto a uma parte restrita do trabalho. A Cursor acredita que a escalabilidade vem mais dessa eficiência de contexto do que do paralelismo em si.

Infraestrutura para 1.000 commits por segundo

O enxame anterior operava sobre Git e chegava a ~1.000 commits por hora. O novo sistema atinge ~1.000 commits por segundo, exigindo um VCS próprio construído do zero. A essa velocidade, surgem modos de falha inéditos: divergência de design (planejadores duplicando decisões), contenção entre planejadores (alterações de ida e volta nos mesmos arquivos), conflitos de merge massivos, megaarquivos que travam tudo e ossificação (agentes que evitam mexer em código central). Cada problema recebeu uma solução específica - desde documentos de design compartilhados com referências verificadas em tempo de compilação até agentes neutros de merge e decomposição automática de arquivos inchados.

Resultados do experimento SQLite

O novo enxame superou o antigo em todas as configurações de modelo. Com Grok 4.5, atingiu 80% da suíte sqllogictest em quatro horas, enquanto o antigo entrou em espiral e foi pausado antes de duas horas. Ao final, todas as novas configurações alcançaram 100%. A diferença qualitativa é ainda mais expressiva: a execução antiga com Grok gerou 68.000 commits e mais de 70.000 conflitos de merge; a nova registrou menos de mil conflitos em quatro horas. O arquivo mais disputado no sistema antigo acumulou 7.771 conflitos de 1.173 agentes diferentes; no novo, o mais disputado teve 47. Em termos de código final, o enxame antigo precisou de 64.305 linhas para passar na suíte; o novo fez o mesmo com 9.908.

Economia dos modelos

Todas as combinações produziram qualidade semelhante, mas os custos variaram de US$ 1.339 (híbrido Opus 4.8 + Composer 2.5) a US$ 10.565 (GPT-5.5 solo). Os executores consomem mais de 90% dos tokens, mas os tokens do planejador custam mais por unidade. Na combinação Opus + Composer, o planejador gerou uma fração dos tokens mas respondeu por dois terços do custo. A implicação prática: poucos momentos exigem inteligência de ponta - decomposição inicial, decisões de design, trade-offs. Depois que o planejador transforma ambiguidade em instrução explícita, modelos baratos simplesmente seguem. Só os executores com GPT-5.5 custaram US$ 9.373; com Composer 2.5, a frota inteira de executores custou US$ 411.

Especificações como nova unidade de trabalho

A Cursor enquadra o enxame como um compilador probabilístico de intenção: planejadores analisam um objetivo em árvores de tarefas e o transformam em trabalho executável, assim como um compilador traduz código-fonte em código de máquina. A diferença é que cada etapa é probabilística. O recurso escasso deixa de ser código e passa a ser a capacidade de descrever intenção com precisão. O código resultante da execução com Opus 4.8 está público em github.com/cursor/minisqlite.