Agent swarm: mais agentes fazem melhor que um?

Um livro de 13 mil palavras e 277 execuções de subagente

Revisei o meu primeiro livro com o Claude Code. Pela conta feita na própria sessão, foram 277 execuções de subagentes para chegar a cerca de 13 mil palavras. O trabalho inteiro consumiu cerca de 587 milhões de tokens, se pagos por uso em API, dariam cerca de US$ 397.

O mercado tem um nome para esse arranjo: agent swarm, o enxame de agentes. Gosto dele, com uma ressalva. Um swarm não cria paralelismo. Ele aproveita o paralelismo que a tarefa já tem, e cobra por isso.

Um coordenador e vários estagiários sem memória

Um agente é um modelo de linguagem que trabalha em etapas: lê a instrução, usa uma ferramenta, olha o resultado e decide o próximo passo. Tudo o que ele leu fica na context window, a janela de texto que o modelo enxerga de uma vez. Ela é finita.

Um subagente é um agente convocado para uma subtarefa. Ele recebe um objetivo, trabalha em uma context window separada e devolve um resumo. A conversa de quem o convocou ele não herda. Quem convoca é o orquestrador, o agente que divide o trabalho, dispara os subagentes e junta as respostas.

Agent swarm é o rótulo para um orquestrador com vários subagentes, em geral rodando ao mesmo tempo:

              pergunta
                 |
           orquestrador
          /      |      \
  subagente  subagente  subagente
          \      |      /
           orquestrador
                 |
             resposta

O nome não tem definição tão formal, mas o mercado já usa. Um exemplo é o Swarm, projeto experimental da OpenAI substituído pelo Agents SDK (OpenAI, Swarm). Outro é o qa-swarm, montado por um engenheiro da PostHog, que dispara quatro agentes revisores de código, cada um com instruções próprias (Jina Yoon, Stop being the code review bottleneck).

Em junho de 2025, a Anthropic descreveu o que o arranjo compra ao contar como montou o seu sistema de pesquisa (Anthropic, How we built our multi-agent research system). São duas coisas. A primeira é exploração em paralelo: o orquestrador dispara de três a cinco subagentes de uma vez, cada um em um aspecto da pergunta. A segunda é contexto separado: cada subagente lê muito e devolve pouco, e a context window do orquestrador enche mais devagar. Na avaliação interna de pesquisa deles, um modelo maior orquestrando subagentes de um modelo menor teve resultado 90,2% melhor que o modelo maior sozinho.

Quinze vezes o preço de um chat, e a conta não para aí

O mesmo texto traz o preço. As restrições são quatro:

A conta. A Anthropic relata que um agente gasta cerca de 4 vezes os tokens de uma conversa de chat, e que o sistema com vários agentes gasta cerca de 15 vezes;
O subagente começa do zero. Ele não enxerga o histórico da conversa principal nem os arquivos que ela já leu (Claude Code, Subagents). O que ele precisa saber tem de caber na instrução que o orquestrador escreve;
As partes dependem umas das outras. A Anthropic avisa que o arranjo não é bom candidato quando todos os agentes precisam do mesmo contexto ou quando há muita dependência entre eles;
Dois agentes escrevem no mesmo lugar. Ler em paralelo é tranquilo. Escrever em paralelo no mesmo arquivo ou no mesmo repositório é disputa.

A primeira restrição explica o ganho. Em outro teste da Anthropic, a quantidade de tokens gasta explicou, sozinha, 80% da variação de desempenho. Os autores escrevem que esses sistemas funcionam principalmente porque ajudam a gastar tokens suficientes para resolver o problema. O ganho e o gasto andam juntos.

A terceira é a que mais derruba expectativa. A Anthropic cita programação como exemplo, por ter menos tarefas de fato paralelizáveis do que pesquisa. Walden Yan, da Cognition, argumenta que cada ação carrega decisões implícitas, e que decisões em conflito dão resultado ruim. No exemplo dele, dois subagentes dividem um clone de Flappy Bird. Um entrega um cenário com cara de Super Mario, o outro entrega um pássaro que nem parece peça de jogo (Walden Yan, Don’t Build Multi-Agents).

Um benchmark de programação publicado por Fabio Akita ilustra o mesmo ponto. O modelo mais forte fez 97 de 100 pontos sozinho. Proibido de escrever código e obrigado a delegar a um subagente, ficou entre 90 e 95 (Fabio Akita, Vale a Pena Misturar 2 Modelos?). O teste é um aplicativo só, e o relato é dele. A leitura que ele tira é a que adotei na abertura: orquestrar agentes só expõe o paralelismo que já existe.

No meu enxame, subagente não escreve

Os subagentes do livro eram leitores, chamados de novo a cada rodada de revisão. É daí que saem as 277 execuções. No repositório em que escrevo, a pasta versionada com os meus textos, toda escrita ou revisão de conteúdo aciona cinco agentes revisores, em três rodadas, no máximo dois ao mesmo tempo. Cada um tem uma função e um limite:

O revisor de texto lê voz, clareza e repetição, e não julga o argumento;
O conferente de evidências compara cada afirmação com a minha base de fontes;
O advogado do diabo ataca o argumento e, numa revisão, lê o que mudou entre as versões;
O leitor leigo recebe só o texto publicável, sem as minhas anotações, sem guia e sem versão anterior;
O leitor do público veste a pessoa para quem o texto foi escrito, decide se compra ou para a leitura.

Nenhum deles edita arquivo. Os achados voltam para mim, e eu decido o que entra. No livro, quatro citações que entraram em uma rodada foram quase todas derrubadas por eles.

O leitor leigo é o melhor exemplo disso. Eu tenho o contexto inteiro na cabeça e não consigo mais ler o texto como quem chegou agora. Ele consegue, porque a context window dele nasceu vazia. Jina Yoon, da PostHog, recomenda o mesmo para código: o agente que escreveu não revisa, porque agentes checam mal o próprio trabalho (Jina Yoon).

A escrita ficou fora do enxame. No livro, eu escrevi à mão, e os subagentes só criticaram. Cinco leituras do mesmo texto são independentes. Os capítulos de um livro dependem uns dos outros: do termo que o anterior fixou, do episódio que ele já contou.

Dois agentes, um repositório e nenhuma reserva

Na mesma época, o trabalho em paralelo falhou comigo. Em outro projeto, montei com sessões do Claude Code a base de fontes que os meus textos consultam. Foram 66 commits, os registros de alteração de um repositório. Mais de uma sessão trabalhou em paralelo na mesma cópia do repositório. Elas disputaram os identificadores numerados das fontes. E uma delas levou arquivos da outra para dentro do próprio commit.

Ali não havia orquestrador além de mim, e eu não tinha dado a cada sessão um lugar só dela. É a quarta restrição em estado puro: duas escritas no mesmo estado, sem reserva. Prompt melhor não resolve esse tipo de falha. Quem acusa a colisão é um programa comum, como um validador que recusa identificador repetido, e ele só avisa depois. Evitar pede reserva: cada agente com a sua faixa de identificadores e a sua cópia do repositório. A reserva tem preço, porque alguém junta as cópias no fim.

Conte as partes antes de contar os agentes

Antes de montar um enxame, eu responderia a três perguntas:

As partes se resolvem sem conversar entre si? Pesquisa, leitura e revisão costumam passar. Construir uma coisa só costuma não passar;
O resultado paga a conta? Cerca de quinze vezes os tokens de um chat cabem em uma decisão cara e não cabem em uma dúvida rápida;
Cada agente escreve em um lugar só dele? Se dois escrevem no mesmo arquivo, resolva isso antes de ligar o segundo.

Pegue a próxima tarefa que você pensou em entregar a vários agentes e escreva a lista das partes. Risque as que dependem da resposta de outra, e as pequenas demais para pagar um subagente que começa do zero. O que sobrar é o tamanho do seu enxame, e às vezes sobra um.