Equipes paralelas de agentes rendem mais que o best-of-N

Um preprint publicado no arXiv em 6 de novembro de 2026 propõe uma resposta direta a uma pergunta prática que qualquer equipe que roda agentes de IA já fez: dado um orçamento fixo de computação na hora da inferência, é melhor disparar muitos agentes independentes ou montar um time grande que colabora? A conclusão dos autores é que nenhuma das duas — e que a melhor aposta é um meio-termo pouco explorado.

O trabalho, intitulado Test-Time Compute Scales Better with Parallel Agent Teams (arXiv:2611.09798), é assinado por Junlin Wang, Haozhe Chen, Ang Li, Rahul Chalamala e Zhuang Liu. São 29 páginas, 18 figuras e 4 tabelas. Trata-se de um preprint ainda sem revisão por pares, e os resultados devem ser lidos com essa ressalva. Os autores informam no campo de comentários do arXiv um endereço de repositório com o código dos experimentos, mas, na verificação feita em 13 de novembro de 2026, esse endereço não estava acessível publicamente.

O método proposto — equipes paralelas de agentes — consiste em amostrar muitos times pequenos simultaneamente e ficar com o resultado do melhor time. Em 12 tarefas longas, times de dez agentes superaram agentes paralelos isolados em 10 delas, e superaram um único time de 100 agentes em todas as quatro tarefas onde times desse tamanho foram testados.

O problema: como gastar computação na hora da inferência

Escalar o tempo de teste significa melhorar o desempenho de um modelo já treinado gastando mais computação no momento da inferência, sem tocar nos pesos. Quando existe um verificador capaz de pontuar cada tentativa — um juiz automático, um compilador, um conjunto de testes —, duas estratégias se tornaram padrão:

• Best-of-N: rodar muitos agentes independentes e ficar com o melhor resultado. Funciona, mas satura rápido: dobrar o número de tentativas deixa de trazer ganho proporcional.
• Um time grande: fazer os agentes colaborarem. Pontua mais alto que um agente sozinho, mas para de melhorar conforme o time cresce.

A proposta dos autores é combinar as duas: em vez de 100 agentes isolados ou um time de 100, rodar dez times de dez em paralelo e selecionar o melhor time pelo verificador. É uma mudança de granularidade na unidade de amostragem, não uma nova arquitetura de agente.

Como o experimento foi montado

Todas as tarefas são problemas de otimização de horizonte longo com pontuação contínua. Cada agente trabalha por doze horas — seis na tarefa de exploração de navegador — dentro do próprio sandbox. Nas tarefas de kernel, estruturais e do EdgeBench, o agente pontua as próprias tentativas contra um juiz durante a execução e guarda a melhor; nas duas tarefas do MLS-Bench não há juiz durante a execução, e o arquivo final é avaliado uma única vez no prazo. Travamento ou submissão inválida valem zero.

O modelo principal é o Qwen3.8-27B, com orçamento de 100 agentes por configuração. As 12 tarefas vêm de cinco conjuntos distintos:

A tarefa de segurança do conjunto é um exercício pontuado em escada dentro de um benchmark fechado, em ambiente controlado; o artigo traz declarações de uso de IA e de ética e não publica material ofensivo.

Os resultados

Com 100 agentes de orçamento, times de dez em paralelo venceram os agentes paralelos em 10 das 12 tarefas e o time único de 100 nas quatro tarefas em que esse formato foi executado. A comparação mais didática aparece no Graph Node Classification: um time de dez marca 79,0 em média, enquanto o melhor entre dez agentes independentes fica em 69,1 — mesmo número de agentes, mesmo tempo. Oito das 12 tarefas repetem o padrão.

Como os dois arranjos consomem os mesmos recursos, o ganho só pode vir do que os agentes trocam entre si.

Custo contra um modelo de fronteira

Os autores também compararam as equipes do modelo de 27B, precificadas por tempo de GPU, contra agentes de um modelo de fronteira (identificado como GPT-5.6-sol) precificados por tokens de lista. Um time de dez do Qwen3.8-27B custa aproximadamente o mesmo que um ou dois agentes do modelo de fronteira.

• Em Carleson Formalization, um agente de fronteira vence um time do 27B; mas pelo preço de cinco agentes de fronteira, oito times do 27B alcançam 52,0 contra 47,9.
• Em Dabic Gravity Inversion, quatro times de dez chegam a 29,0 contra 19,7 pelo preço de cinco agentes de fronteira.
• Em Graph Node Classification, três times de dez marcam 86,9 contra 84,6 — embora um único agente de fronteira (83,0) já supere qualquer coisa que o 27B compre pelo mesmo dinheiro.
• Nas oito tarefas com pelo menos cinco execuções do modelo de fronteira, os times do 27B vencem em quatro. Precificando o 27B por tokens em vez de tempo de GPU, a conta sobe para seis de oito.

O modelo de fronteira segue à frente onde sua média é mais alta — Borden Source Inversion e Ad Placement Optimization — ou onde sua dispersão é maior, como em KDA Chunk Forward. Em MoE Load Balance a diferença é de 0,78 contra 0,77. A explicação dos autores é simples: o modelo de fronteira pontua alto e varia pouco entre execuções, então repetir execuções acrescenta pouco, enquanto o melhor entre vários times do modelo menor continua subindo.

Por que times pequenos em paralelo vencem

O artigo propõe um modelo estatístico qualitativo. O valor esperado do melhor resultado cresce com a média das amostras e com a raiz do logaritmo do número de amostras, ponderado pelo desvio padrão. Daí decorrem as duas derrotas: agentes isolados perdem porque suas muitas amostras têm média baixa; um time único grande perde porque, sendo uma única amostra, não extrai nenhum ganho da variância. Amostrar muitos times pequenos equilibra média alta com o benefício da dispersão.

O que acontece dentro de um time

Para entender a colaboração, os pesquisadores analisaram as mensagens trocadas pelos agentes em um fórum compartilhado. O que eles mais fazem é relatar o que tentaram e quanto pontuou. Já na primeira hora começam a marcar esses relatos com etiquetas curtas do tipo win e fail, que tornam o histórico rápido de varrer.

Hábitos úteis se espalham sem que ninguém atribua papéis: no Borden Source Inversion, depois que um agente passa a anunciar experimentos antes de rodá-los, 88% dos colegas de time adotam a prática. Os agentes também constroem sobre o trabalho alheio — em uma execução, seis de oito colegas reenviaram a nova melhor solução de um par em menos de dez minutos.

Liderança emergente existe, mas é rara. Das 707 execuções com fórum do Qwen3.8-27B, 149 contêm oito ou mais instruções dirigidas a um colega nomeado; em apenas cinco delas um único agente concentra a maior parte dessas instruções durante toda a execução. O agente mais diretivo de uma execução costuma escrever cerca de um terço das instruções.

Impactos, possibilidades e limitações

Para quem opera agentes em produção, o resultado prático é barato de testar: trata-se de reorganizar como o orçamento é fatiado, não de trocar modelo ou harness. Se já existe um verificador confiável no fluxo — suíte de testes, benchmark de latência, juiz automático —, dividir 100 execuções em dez times de dez é uma mudança de configuração.

Há também uma leitura econômica relevante: em parte das tarefas, um modelo aberto de 27B com orquestração melhor empata ou supera um modelo de fronteira pelo mesmo gasto. Isso não vale para todas as tarefas, e o próprio artigo mostra os casos em que o modelo de fronteira continua imbatível.

As limitações declaradas pelos autores são substanciais e merecem peso: o modelo estatístico é qualitativo nos regimes de falha ou de teto; os conjuntos de times têm apenas 10 a 11 execuções por tarefa; times maiores que dez rodaram em apenas quatro tarefas, com uma a cinco execuções por tamanho; em times de 64 e 100 agentes o índice do fórum listava só as mensagens mais recentes e as não lidas, o que limita a análise de comunicação; variou-se a duração da sessão em uma única tarefa; e foi usado um único harness de agente. A dependência mais importante, porém, é conceitual: sem um verificador, escolher o melhor time vira um problema em si — e é justamente isso que falta na maioria das aplicações reais.

O que dá para aplicar

• Verificar se o fluxo tem um verificador objetivo e barato. Sem ele, a estratégia não se sustenta.
• Tratar o tamanho do time como hiperparâmetro: testar dez times de dez antes de assumir que mais agentes isolados é a resposta.
• Medir custo na moeda certa — tempo de GPU e tokens levam a conclusões diferentes, como o próprio artigo demonstra.
• Instrumentar a comunicação entre agentes. Etiquetas simples de resultado, do tipo acerto/erro, foram o mecanismo que os agentes criaram sozinhos para reaproveitar descobertas.

Conclusão

O artigo não anuncia nova capacidade de modelo; ele mostra que a forma de distribuir o orçamento de inferência tem efeito mensurável e que a escolha mais comum — mais agentes independentes — nem sempre é a melhor. É um resultado de engenharia de sistemas de agentes — e, enquanto o repositório indicado pelos autores não estiver acessível, a replicação independente depende de reconstruir o arranjo a partir da descrição do artigo.

Vale acompanhar se os números se sustentam em outros harnesses e modelos, se a revisão por pares confirma o modelo estatístico, e se alguém consegue estender o método para cenários sem verificador — a fronteira que o próprio trabalho aponta como aberta. Em agosto, o Plugged Ninja cobriu um estudo correlato, sobre como o ranking de LLMs muda conforme o limite de tokens; os dois trabalhos apontam na mesma direção: o orçamento de inferência é parte da avaliação, não um detalhe de implantação.

Fontes e referências

• arXiv — Junlin Wang, Haozhe Chen, Ang Li, Rahul Chalamala, Zhuang Liu, “Test-Time Compute Scales Better with Parallel Agent Teams”, arXiv:2611.09798 — arxiv.org
• arXiv — versão HTML completa do preprint, com apêndices de tarefas, custos e análise de comunicação — arxiv.org/html
• DOI do preprint — doi.org/10.48550/arXiv.2611.09798
• Repositório de código indicado pelos autores no campo de comentários do arXiv: github.com/modal-projects/parallel-agent-teams-scaling — inacessível na verificação de 13 de novembro de 2026 (por isso o endereço é reproduzido sem link).