Às vezes o número certo de agents é um

Dê a uma tarefa um budget e duas formas de gastá-lo. Gaste tudo num único agent que lê o problema inteiro, o segura numa cabeça só, e o trabalha de ponta a ponta. Ou divida o mesmo budget entre cinco agents, cada um recebendo uma fatia, nenhum vendo o trabalho dos outros até um sexto agent grampear as peças no fim. O segundo arranjo parece mais sério. Ele tem um diagrama. Ele tem um enxame.

Ele também, mais frequentemente do que as pessoas esperam, perde.

Sob um budget fixo com contexto limpo, um único agent vence um enxame, abra em leque só quando isolamento de domínio é um requisito rígido.

Este post é sobre quando adicionar agents e quando adicioná-los piora o resultado, e por que o instinto de abrir em leque é, na maioria das vezes, um instinto de gastar seu budget em coordenação em vez de pensamento.

A versão ingênua: mais agents devem significar mais capacidade

O movimento óbvio, o que todo demo de multi-agent te treina a fazer, é tratar agents como trabalhadores. Você tem um trabalho grande, então contrata uma equipe. Divida o trabalho em cinco partes, dê cada parte ao seu próprio agent, rode-os ao mesmo tempo, e colete os resultados. Mais mãos, mais feito. Parece a razão inteira de o paralelismo existir.

Ele demonstra lindamente. Aí você o roda numa tarefa real com um budget real e a matemática vira contra você.

Aqui está a falha, e não é que qualquer agent isolado seja ruim. Cada um faz sua fatia bem. A falha é que você gastou seu budget fixo em cinco vias, então cada agent ganhou um quinto do espaço para pensar, e então você gastou mais do budget na parte que nenhum agent isolado tinha que fazer antes: a costura. O agent três fez uma suposição sobre o formato dos dados. O agent um fez a suposição oposta. Nenhum viu o outro, porque o ponto inteiro de dividir era que eles não viam. Agora o agent de junção não está combinando trabalho terminado; ele é um árbitro descobrindo, no fim, que as peças não se encaixam. A contradição aparece por último, quando é mais cara de consertar, em vez de primeiro, quando uma mente só a teria pego de passagem.

Um único agent no mesmo budget nunca tem esse problema, porque não há costura. Ele leu o formato dos dados uma vez e toda decisão posterior o herdou. A suposição que quebrou o enxame nunca foi uma pergunta para o agent solo, era só contexto que ele já segurava. O enxame não falhou porque os agents eram fracos. Falhou porque dividir o trabalho dividiu o entendimento, e entendimento não sobrevive a ser cortado em quintos.

Então a primeira regra para a qual construímos é quase grosseira em sua simplicidade: não abra em leque para parecer sério. Abra em leque quando ficar junto é a coisa que de fato é impossível.

Vale demorar no porquê a contradição aparece por último em vez de primeiro, porque esse timing é o custo inteiro. Quando uma mente trabalha um problema, toda decisão que ela toma vira uma restrição na próxima. Ela não consegue quietamente se contradizer, porque a escolha anterior ainda está sentada em seu contexto, vetando a posterior incompatível. O check é contínuo e gratuito. Divida o trabalho, e você remove esse check corrente. Cada agent é internamente consistente e globalmente cego. As contradições não vão embora, elas ficam silenciosas, acumulando quietamente até o passo de junção arrancar a tampa e achar cinco respostas localmente corretas que não somam para um todo correto. Você não evitou o custo da consistência paralelizando. Você o adiou para o momento mais caro possível e o fez uma emergência de outra pessoa.

Coordenação é um imposto, e você o paga precisando ou não

Há um custo de rodar agents em paralelo que os demos nunca mostram, porque num demo ele arredonda para zero. Numa tarefa real ele não arredonda.

Toda vez que dois agents têm que concordar em algo, esse acordo custa budget. Alguém tem que especificar a fatia para o agent quatro precisamente o bastante para que ele não divague. Alguém tem que ler cinco outputs e notar os dois que conflitam. Alguém tem que re-rodar o agent dois porque ele resolveu um problema ligeiramente diferente do que recebeu. Nada desse esforço move a tarefa adiante. Ele existe apenas porque você dividiu a tarefa em primeiro lugar. É overhead que você criou e então tem que pagar.

A parte cruel é que o imposto escala na direção errada. Dois agents têm uma costura entre eles. Três agents têm três. Cinco agents têm dez pares possíveis que podem discordar, e um passo de junção que tem que reconciliar todos eles. Adicione agents para ir mais rápido e a partir de um ponto você adicionou mais coordenação que trabalho, a curva onde o quadro de pessoal para de ajudar é a mesma curva que um gerente aprende do jeito difícil quando um time de três entrega mais que um time de nove.

Um enxame não falha alto. Ele só quietamente gasta seu budget concordando consigo mesmo.

Sob um budget fixo com contexto limpo, um único agent vence um enxame. Não porque paralelismo é ruim, porque paralelismo é caro, e a maioria das tarefas não pode pagar por algo de que não precisa.

Quando contexto limpo é o jogo inteiro

A expressão fazendo o trabalho de verdade em nossa regra é “contexto limpo”, e vale ser concreto sobre o que ela significa, porque é a dobradiça em que a decisão inteira gira.

Contexto limpo significa que um agent consegue segurar tudo de que a tarefa precisa sem que o segurar em si vire o gargalo. O problema cabe. Os fatos relevantes cabem. As restrições cabem. Quando isso é verdade, dividir a tarefa é pura perda, você pega um problema que cabia numa cabeça e paga para espalhá-lo entre várias que agora têm que remontá-lo. Todo demo onde o agent solo quietamente supera o enxame é um demo onde o contexto era limpo e ninguém precisou admitir.

Contexto para de ser limpo por exatamente uma razão: a tarefa genuinamente contém peças que não devem compartilhar uma cabeça. Não “ficaria mais arrumado separado”. Não devem. Um revisor que tem que ser cético do código não pode ser a mesma mente que escreveu o código e tem orgulho dele, isso não é uma questão de budget, é uma estrutural, e já escrevemos antes sobre por que o revisor mais duro do time é o que não tem nenhum interesse no trabalho. Um agent de retrieval que tem que ler um documento hostil não pode compartilhar uma context window com o agent que segura seus segredos, porque no momento em que eles compartilham uma janela, o texto hostil pode alcançar o segredo. Essas são costuras reais. Valem ser pagas.

O erro é tratar toda fronteira como uma dessas. A maioria das fronteiras numa tarefa não são paredes de segurança ou paredes de ceticismo. São só linhas que alguém desenhou num quadro branco para fazer o trabalho parecer paralelizável. Desenhar a linha não torna a linha estrutural. E uma linha que não é estrutural é só um lugar onde você concordou em pagar o imposto de coordenação à toa.

Então o teste que aplicamos antes de abrir em leque é uma única pergunta, e ela tem que passar uma barra alta: há uma razão pela qual estas peças não podem viver na mesma mente, uma razão de correção, uma razão de segurança, uma razão grande-demais-para-caber, ou elas só parecem separáveis? Se for a segunda, o número certo de agents é um.

O caso “grande-demais-para-caber” merece sua própria honestidade, porque é o que as pessoas usam para justificar um enxame que queriam de qualquer jeito. Sim, algumas tarefas genuinamente transbordam um único contexto, uma base de código grande demais para ler de uma vez, um corpus largo demais para resumir numa passada. Mas no momento em que você divide por tamanho, você assumiu o imposto de coordenação de propósito, e o movimento certo é pagá-lo o mais barato possível: divida ao longo das fronteiras naturais que já existem no problema, não as convenientes. Um repositório divide limpo por módulo porque os módulos foram projetados para não saber uns dos outros. Um corpus de pesquisa divide limpo por fonte. Dividir uma única função fortemente acoplada entre três agents porque ela é “longa” divide algo que nunca foi feito para se separar, e você vai pagar por isso na costura, toda vez. Tamanho pode forçar uma abertura em leque. Não desculpa uma descuidada.

A arquitetura: uma mente por padrão, costuras só onde são reais

Aqui está o formato para o qual de fato construímos, e ele é deliberadamente chato no centro.

Por padrão, uma tarefa é um agent com o budget inteiro e o problema inteiro. Ele planeja, ele trabalha, ele carrega toda decisão adiante sem nunca se re-explicar a um colega, porque não tem colega. Isso não é nós subutilizando o enxame. É nós nos recusando a pagar um imposto que a tarefa não cobrou.

Adicionamos um segundo agent apenas quando uma costura é real, e o adicionamos através daquela costura e em nenhum outro lugar. O revisor adversarial é um agent separado porque ceticismo não pode compartilhar uma cabeça com autoria, uma costura, justificada, paga. O agent em sandbox que lê input não confiável é separado porque o texto não confiável nunca deve tocar o contexto privilegiado, uma costura, justificada, paga. Não dividimos a escrita de uma feature entre três agents porque a feature tem três arquivos. Arquivos não são costuras. O entendimento que os conecta é o ativo, e não cortamos o ativo para fazer um gráfico parecer mais ocupado.

Esta é a mesma disciplina que uma boa organização de engenharia aplica a times, só que acelerada. Você não divide um projeto entre cinco pessoas porque ele tem cinco partes; você o divide onde as partes genuinamente não podem ser seguradas por uma pessoa, e mantém todo o resto junto para que continue coerente. Toda fronteira extra que você adiciona é um lugar onde a informação tem que ser re-transmitida, e toda re-transmissão é um lugar onde ela é distorcida. A organização que entrega mantém suas fronteiras escassas e estruturais. Nós também.

O retorno é que quando de fato abrimos em leque, a abertura significa algo. Um segundo agent numa tarefa é um sinal de que uma parede real existe, um lugar onde duas mentes não é um luxo mas um requisito. Ninguém no time precisa se perguntar se o enxame é teatro, porque não rodamos enxames como teatro. A contagem de agents é uma leitura de quantas costuras genuínas a tarefa tem, e a maioria das tarefas tem uma.

A virada: o julgamento é a parte que não escala

Você pode comprar mais agents. Você não pode comprar o julgamento que decide se deve.

Essa decisão, abra em leque aqui, fique junto ali, é a habilidade inteira, e é a única coisa que mais compute nunca vai te entregar de graça. Um time que consegue subir cem agents e aponta todos os cem para toda tarefa não construiu capacidade; construiu uma forma muito cara de gastar um budget em coordenação. A capacidade está na contenção: a disposição de olhar um problema que poderia ser dividido, reconhecer que dividi-lo só espalharia um contexto que já era limpo, e atribuí-lo a um agent que vai simplesmente resolvê-lo. Essa contenção parece, de fora, fazer menos. Ela está fazendo exatamente o suficiente.

Os sistemas vão continuar ficando mais baratos de paralelizar. A tentação de jogar mais agents em tudo só vai crescer, porque mais agents vão continuar parecendo mais seriedade. Nada disso muda a regra por baixo. Sob um budget fixo com contexto limpo, um único agent vence um enxame, e o engenheiro que sabe quando isso é verdade, e tem a disciplina de agir nisso em vez de recorrer à multidão de aparência impressionante, vale mais que a multidão.

---

É essa a disciplina que estamos construindo na Apollo Space: um sistema operacional que adiciona um agent porque uma costura exige, nunca porque um enxame parece impressionante. Se você já viu um time de nove entregar menos que um time de três, você já entende a regra, e já sabe que saber quando não abrir em leque é a chamada mais difícil e mais valiosa da sala.