Times de agentes por $155 em vez de $510: Cohere descobre onde delegar vale a pena

Agentes já estão em produção

No último ano, times de agentes programadores deixaram de ser demonstrações interessantes e passaram a ser projetos industriais reais. Dezesseis agentes Claude escreveram um compilador de C com 100 mil linhas, capaz de compilar o kernel do Linux, gastando cerca de 2 mil sessões e $20 mil em API. O time da Cursor colocou em ação centenas de agentes que escreveram juntos um navegador web com mais de um milhão de linhas de código em uma semana. O projeto Bun migrou sua base de código de Zig para Rust em 11 dias usando 64 agentes Claude trabalhando em paralelo.

Cada um desses projetos entregou código funcional, mas eles se diferenciaram na forma de organização: o compilador foi construído por agentes com status igualitário, sem orquestrador, pegando tarefas por meio de arquivos lock; a Cursor aplicou uma hierarquia — planejadores que dividiam recursivamente o trabalho em subtarefas para centenas de trabalhadores; a Bun atribuiu papéis fixos: um implementador, dois revisores críticos e um corretor para cada tarefa.

Comparar esses projetos entre si não diria muito sobre quais decisões realmente pesaram ou quanto custaram. A Factory publicou uma pesquisa sobre seu próprio sistema de três papéis (orquestrador → implementador → validador em loop): em uma única tarefa (restaurar a biblioteca GDAL), seu time dobrou o resultado de um único agente, mas custou 14 vezes mais e levou 13 vezes mais tempo.

Onde delegar importa mais do que quantos agentes usar

A Cohere construiu uma plataforma de testes controlada baseada no mini-SWE-agent: cada agente trabalha por meio de uma interface bash em um espaço de trabalho compartilhado, o líder distribui tarefas por meio de uma ferramenta delegate_agent, e os trabalhadores só veem sua própria subtarefa. Foram investigadas cinco variáveis:

1. Onde o líder usa os trabalhadores: um prompt mínimo apenas ordena que o time trabalhe; um prompt estruturado (P-I-V) adiciona etapas explícitas — planejamento, implementação, verificação. 2. Como o líder espera: síncrono (espera que todos reportem) ou assíncrono (continua trabalhando ele mesmo, verificando atualizações quando necessário). 3. Quais modelos em quais papéis: times homogêneos (todos no Sol) versus heterogêneos (líder no Sol, trabalhadores no Luna). 4. Tamanho do time: o líder decide por conta própria quantos trabalhadores são necessários, ou o tamanho é fixado em 2, 4, 8 ou 16. 5. Comunicação: por meio do líder (padrão) ou diretamente entre os agentes.

Os testes foram feitos no benchmark ProgramBench — 200 programas, de utilitários (jq, ripgrep) a sistemas complexos (SQLite, FFmpeg, um interpretador de PHP). O agente vê apenas o binário em funcionamento e a documentação do programa original, e precisa descobrir seu comportamento por engenharia reversa para escrever uma nova implementação. A avaliação é o percentual de testes de comportamento aprovados.

O planejamento rende o dobro

Um time completo de agentes Sol superou um único agente por 9,7 pontos (61,8% contra 52,1%), mas custou de 4 a 7 vezes mais. Um líder assíncrono economiza tempo: com um prompt PIV, o time termina 19,5% mais rápido com o mesmo resultado.

A principal descoberta: quando o líder delegou apenas o planejamento (agentes Luna que investigam o programa, descobrem seu comportamento e esboçam um plano), ele alcançou 63,6% de precisão por $249. Isso é exatamente a metade dos $510 gastos por um time que delega as três etapas, perdendo apenas 0,4 ponto (63,2% contra 63,6%). Implementação e verificação deram resultados bem menores — entre 58% e 71% com os mesmos 16 agentes.

A razão está no design do ProgramBench: o programa-alvo é uma caixa-preta, e seu comportamento precisa ser descoberto por meio de testes. Os trabalhadores-planejadores investigam em paralelo diferentes partes da interface, e o líder reúne os relatórios e escreve o código ele mesmo. Esse é o paralelismo que gera o maior retorno.

No caso do utilitário dsq: um único agente com prompt PIV obteve 60%, um time que delegou apenas o planejamento obteve entre 76% e 79%, e cada uma de suas seis execuções superou cada execução solo. Delegar a implementação ou a verificação nas mesmas condições resultou em 58% a 71%.

Um benchmark secundário, o Commit0-Lite (16 bibliotecas Python com a implementação removida, mas com documentação e testes completos), confirmou o padrão: quando a especificação é dada explicitamente, a etapa de planejamento continua sendo crítica.