Subagentes em paralelo não garantem entrega mais rápida

Delegar para vários agentes parece uma forma direta de terminar antes. Em tarefas longas de engenharia, porém, paralelizar também cria filas, dependências, sobreposição de contexto, conflitos de estado e um novo trabalho de integração. A pergunta técnica não é quantos agentes cabem no fluxo, mas quando o trabalho pode ser decomposto sem perder coerência global.

Estado: Evidence Brief aprovado para publicação. Série editorial: Papers que lemos por você. Este texto analisa o preprint *When Sub-Agents Work in Parallel* e seus artefatos públicos. Não afirma que a Trustyu Forge reproduziu os experimentos nem que os resultados classificam universalmente Codex, Claude Code, Kimi Code ou qualquer versão futura desses produtos.

O que foi comparado

Os autores avaliaram três agentes de código com suporte nativo a concorrência dinâmica: Codex, Claude Code e Kimi Code. Em cada tarefa, compararam duas condições: o agente podia decidir quando criar subagentes ou precisava executar sem delegação paralela. Modelo, prompt, ambiente e orçamento de tempo foram mantidos equivalentes dentro de cada par.

A amostra reúne 354 tarefas: 254 de quatro benchmarks de longa duração e 100 do SWE-bench Verified, tratado como referência de trabalho mais delimitado. Cada tarefa foi executada com os três agentes nas duas condições, totalizando 2.124 execuções. A telemetria registrou 11,2 bilhões de tokens e um custo estimado pelos autores de US$ 20.780,02 nas tarifas de API adotadas no estudo.

Mais capacidade não produziu ganho uniforme

No agregado reportado, habilitar concorrência dinâmica alterou a resolução entre uma queda de 11,9 pontos percentuais e um ganho de 2,3 pontos, conforme agente e conjunto. O consumo de tokens ficou entre 1,41 e 3,31 vezes o modo sequencial. O tempo médio aumentou em 14 das 15 combinações entre agente e benchmark.

O resultado foi sensível ao tipo de trabalho. Em LoopsBench, conjunto de tarefas mais longas do estudo, Codex e Claude Code tiveram ganhos de task pass, com aumento de até 14,3 pontos percentuais. No SWE-bench Verified, Claude Code caiu de 83% para 59% e Kimi Code de 77% para 59%; Codex ficou em 71% nas duas condições. Paralelismo ajudou onde havia trabalho complementar suficiente e prejudicou quando o custo de coordenação superou a oportunidade de decomposição.

O gargalo migra para integração

Uma trajetória apresentada no paper ilustra o risco. O agente principal criou 20 subagentes para implementar comandos de uma ferramenta, aguardou o lote inteiro e deixou de integrar e testar o que já estava disponível antes do limite de tempo. O programa compilou, mas passou em apenas 92 de 440 testes porque partes essenciais não foram integradas.

A análise manual das trajetórias produziu quatro categorias, 13 subcategorias e 28 padrões de falha. Os grupos cobrem orquestração da tarefa, governança da execução, gestão de contexto global e estado compartilhado/merge. A concordância entre anotadores foi reportada com Cohen's kappa de 0,77.

Quando a concorrência tende a ajudar

O paper identifica três mecanismos de benefício: trabalho complementar realmente independente, exploração de soluções alternativas e validação separada do trabalho principal. Isso sugere um gate antes do spawn:

1. Independência: o subproblema tem entradas e saída explícitas e pode avançar sem editar o mesmo estado de outros agentes?
2. Integração: existe um owner responsável por reconciliar interfaces, conflitos e efeitos colaterais antes do aceite?
3. Orçamento: a delegação preserva tempo e tokens suficientes para integração, testes e correção?
4. Observabilidade: é possível ver dependências, espera, arquivos tocados e resultados parciais?
5. Fallback: se um subagente atrasar ou falhar, o principal consegue usar resultados parciais ou voltar ao caminho sequencial?

Regra de arquitetura

Concorrência é uma política de execução, não uma garantia de produtividade. O harness deve permitir delegação somente quando a tarefa declarar fronteiras de estado, contrato de entrega, orçamento de integração e um responsável pelo aceite global. Velocidade local de subagentes não substitui a prova de que o artefato integrado atende ao contrato. [R2-C3]

Na Forge, um fluxo multiagente precisa registrar o plano de decomposição, dependências, contexto entregue, mudanças produzidas, conflitos, testes e aceite. A métrica principal não é quantidade de agentes ocupados; é tempo e custo até uma entrega integrada, verificável e recuperável.

Limites e conflito de interesse

O estudo é um preprint v1 de 07/10/2026. A amostra cobre três agentes, configurações escolhidas em julho de 2026 e cinco benchmarks; ela não representa todas as ferramentas, versões, linguagens ou formas de orquestração. As tarefas foram amostradas por dificuldade e, por custo, cada célula aparece uma vez no experimento principal, o que limita estimativas de variância em sistemas estocásticos.

Os autores liberaram trajetórias e artefatos de análise, mas até o corte editorial não localizamos replicação independente completa. Os autores declaram afiliações a Nanjing University, Central University of Finance and Economics e University of Illinois Urbana-Champaign; não localizamos afiliações comerciais declaradas aos três fornecedores avaliados. Ausência de conflito identificado não é prova de independência absoluta.

Fontes diretas

1. When Sub-Agents Work in Parallel — arXiv. Preprint, autores, resumo, versão e data.
2. When Sub-Agents Work in Parallel — texto integral. Método, denominadores, resultados, taxonomia e limites.
3. Concurrency Failures Trajectory Artifact — repositório oficial. Trajetórias e artefatos disponibilizados pelos autores.

Nota editorial e de responsabilidade

Este texto combina fatos atribuídos às fontes com análise e proposta técnica do autor. Pontos de vista pessoais e profissionais não são fatos comprovados; dados, denominadores, limites, afiliações e ausência de reprodução independente são indicados quando disponíveis. O conteúdo é informativo e não substitui avaliação técnica, jurídica, financeira ou de segurança. Nomes de produtos pertencem aos respectivos titulares; não há patrocínio ou endosso. Tech Human e Trustyu atuam comercialmente em desenvolvimento e governança de produtos digitais. Pesquisa, estrutura e redação tiveram assistência de IA; revisão factual, aprovação autoral e publicação foram autorizadas por Fernando Parreiras em 08/10/2026, sem revisão humana independente adicional.

Corte da pesquisa: 08/10/2026. Estado editorial: Evidence Brief especial autorizado para 13/10/2026 às 09h BRT.