Quando um agent deveria virar muitos

Dê uma tarefa a um agent e ele faz a tarefa. Dê a mesma tarefa a seis agents e você agora tem um sétimo problema: impedir que os seis pisem uns nos outros, se contradigam e reportem com confiança seis versões diferentes de “pronto”. O trabalho ficou mais rápido. A contabilidade ficou mais difícil.

Esse segundo custo é o que todo mundo esquece de colocar na fatura. É também o que decide se dividir o trabalho foi uma boa ideia ou uma ruim.

O fan-out não é grátis, ele compra paralelismo e paga em coordenação, e a habilidade é saber de que lado dessa troca uma tarefa está. Este post é sobre a troca: quando um agent deveria virar muitos, como tornar os muitos confiáveis, e a disciplina mais difícil que quase ninguém escreve, quando deixar o um em paz.

A visão ingênua: mais agents, mais feito

O modelo óbvio é o que as demos vendem. Uma tarefa chega. É grande. Então você a corta em pedaços, entrega cada pedaço ao seu próprio agent, roda todos de uma vez e grampeia os resultados de volta no final. Seis agents, um sexto do wall-clock. O que não amar.

Funciona lindamente nas tarefas que já eram independentes. Resumir quarenta documentos, sim, distribua isso, os documentos não sabem uns dos outros. Buscar em dez fontes em paralelo, sim, as fontes não colidem. Para trabalho genuinamente paralelo, o enxame é exatamente certo, e um único agent moendo a lista um item por vez é só lento de propósito.

Aí você tenta numa tarefa cujos pedaços sabem uns dos outros, e o modelo quebra de um jeito que é fácil de não perceber até morder.

Digamos que você divida “construir esta feature” num pedaço que escreve a função e num pedaço que escreve o código que a chama. Rode-os em paralelo e cada um está adivinhando a forma do outro. Um assume que a função retorna uma lista; o outro assume um valor único. Os dois terminam. Os dois passam nos próprios testes. Grampeados juntos, não encaixam, e agora você está gastando o tempo que economizou no paralelismo desembaraçando uma costura que um único agent, segurando as duas pontas de uma vez, nunca teria criado.

O modelo ingênuo trata coordenação como zero. Ela nunca é zero. No momento em que dois pedaços de uma tarefa têm que concordar em qualquer coisa, uma forma, uma ordem, um fato, um arquivo, você adicionou um custo que cresce com quantos agents têm que ficar em sincronia. Às vezes esse custo é pequeno e o paralelismo vence. Às vezes ele come o paralelismo inteiro.

Fan-out, depois reavaliar, nunca confie no próprio relatório do enxame

Suponha que você decidiu que uma tarefa é mesmo paralela o suficiente para dividir. Você a decompõe, despacha os workers, eles rodam. Agora vem o passo que a versão ingênua pula inteiramente: você tem que decidir se cada pedaço de fato voltou pronto.

Aqui está a armadilha. Cada sub-agent reporta o próprio resultado. Cada um diz, com suas próprias palavras, parece pronto. E o agent que fez o trabalho é o pior juiz possível de se o trabalho está terminado, ele escreveu o teste, então o teste afirma o que o código já faz; ele definiu o objetivo, então o objetivo é o que quer que ele tenha alcançado. Junte seis “prontos” auto-avaliados e você não tem seis pedaços terminados. Você tem seis afirmações, cada uma assinada pela única parte com motivo para assiná-la.

Então o trabalho real do orchestrator não é despachar. Despachar é a metade fácil. O trabalho real é reavaliar, puxar cada pedaço retornado e checá-lo contra o que o pedaço de fato deveria fazer, com olhos frescos que não têm orgulho no resultado.

Uma afirmação não é um resultado.

Essa única regra muda a forma do sistema inteiro. O orchestrator deixa de ser uma coisa que coleta respostas e se torna uma coisa que as interroga. Ele re-roda o flow que o worker diz ter satisfeito. Ele procura o caso ausente em vez do presente. Quando um worker reporta complete, o orchestrator trata essa palavra como uma hipótese a refutar, não um fato a encaminhar cadeia acima. Um pedaço que não sobrevive à reavaliação volta, não importa quão confiante o relatório, não importa quão verdes os próprios testes do worker estavam.

O padrão, então, são três tempos, não um. Decompor a tarefa em pedaços que possam rodar separados. Paralelizar os pedaços por workers isolados para que não possam corromper o espaço de trabalho um do outro. Reavaliar cada resultado independentemente antes que qualquer um conte. Pule o terceiro tempo e você construiu um jeito mais rápido de entregar trabalho que ninguém checou, o que é pior que um agent cuidadoso, não melhor.

A disciplina que as demos pulam: quando NÃO fazer fan-out

Agora a parte mais difícil de vender e mais importante de aprender. A maioria das tarefas não deveria ser distribuída, e a razão é o custo que continuamos nos recusando a contar.

Imagine o trabalho como um grafo. Cada pedaço é um nó; cada “estes dois têm que concordar” é uma aresta. Uma tarefa sem arestas, quarenta documentos sem relação, é ouro paralelo puro; adicione agents e você adiciona velocidade sem nada a pagar. Mas arestas são onde a coordenação mora, e elas se multiplicam mais rápido que os nós. Três pedaços que todos dependem uns dos outros não são três relacionamentos, são o emaranhado de cada par mais o todo. Distribua isso e seus agents gastam mais esforço reconciliando suas adivinhações uns sobre os outros do que gastariam só fazendo o trabalho em sequência.

O instinto ingênuo é perguntar “essa tarefa é grande?”. Tarefas grandes parecem querer mais mãos. Mas tamanho é a pergunta errada. Uma tarefa grande que é principalmente uma longa cadeia dependente, faça isso, depois com aquele resultado faça o próximo, depois o próximo, não tem paralelismo a extrair. Dividi-la não te dá seis agents trabalhando; te dá um agent trabalhando e cinco esperando, mais o overhead de passar o bastão entre estranhos a cada handoff.

A pergunta certa não é “quão grande é isso?”. É “quanto disto pode de fato acontecer ao mesmo tempo sem que os pedaços precisem concordar?”. Isso é a única coisa que a versão paralela compra, e numa tarefa fortemente acoplada a resposta é quase nada. Ali, o único agent vence de longe, não porque é heroico, mas porque ele segura a tarefa inteira numa cabeça só e nunca tem que negociar com uma cópia de si mesmo.

O sinal é o overhead de coordenação excedendo o ganho do paralelismo. Quando os agents gastariam mais tempo sincronizando do que trabalhando, você cruzou a linha. E a falha de cruzá-la não é lentidão, lentidão você notaria. É uma incorreção sutil: seis pedaços localmente corretos que são globalmente incoerentes, cada um defensável por si, nenhum encaixando. Um bug pelo qual nenhum worker é responsável, porque ele vive nas costuras entre eles.

O fan-out compra paralelismo e paga em coordenação. Numa tarefa sem costuras, você não paga nada e embolsa a velocidade. Numa tarefa que é toda costura, você paga tudo e embolsa um problema de coordenação. A habilidade é ler as costuras antes de dividir.

O trabalho de verdade do orchestrator: rotear, não multiplicar

Junte as duas metades e uma verdade mais silenciosa aparece. A parte difícil de rodar muitos agents nunca foi rodar muitos agents. É decidir, por tarefa, se deve.

Um orchestrator fraco tem um movimento: dividir tudo. Ele trata o fan-out como o objetivo, então toda tarefa é estilhaçada em pedaços querendo ou não, e o imposto de coordenação é pago em tarefas que não tinham paralelismo para pagá-lo. Ele parece ocupado. Está principalmente ocupado reconciliando problemas que criou.

Um bom orchestrator tem dois movimentos, e o julgamento para escolher. Ele lê uma tarefa por suas costuras. Fracamente acoplada, genuinamente paralela, distribua, depois reavalie cada pedaço. Fortemente acoplada, uma longa cadeia dependente, entregue a um único agent e saia do caminho. A decisão de não paralelizar é tão parte do trabalho quanto a decisão de paralelizar, e um sistema que só consegue fazer um desses dois é só meio orchestrator.

É por isso que “quantos agents” é o enquadramento errado para otimizar. Mais agents não é um objetivo. O objetivo é o trabalho, feito e verificado, pelo menor custo total, e o custo total inclui a coordenação para a qual você estaria se inscrevendo. Às vezes essa conta diz seis. Frequentemente diz um. O orchestrator ganha seu sustento sendo certo sobre qual.

A virada: coordenação é um custo que humanos também pagam

Dê um passo atrás dos agents e você vai reconhecer isso. Você viveu.

É a reunião que deveria ter sido a tarde de uma pessoa. O projeto dividido entre cinco pessoas que agora gastam metade da semana em calls de sincronia reconciliando o que cada uma assumiu. A feature entregue a um time quando queria um engenheiro focado, e as costuras entre os pedaços viraram o bug que foi para produção. Toda empresa aprende, geralmente do jeito caro, que jogar mais gente numa tarefa não é a mesma coisa que fazê-la mais rápido, que, passado um ponto, a coordenação come o ganho, e a coisa de que você precisava era uma pessoa que pudesse segurar o problema inteiro de uma vez.

Agents tornam essa lição literal, e barata de aprender. Você consegue ver o imposto de coordenação nos traces. Você consegue ver os seis pedaços localmente corretos que não encaixam. Você consegue medir o momento em que a sincronia custou mais do que o paralelismo economizou. A conta que levou décadas para as organizações humanas sentirem é, para um enxame de agents, só números que você consegue ler.

Então a pergunta em torno da qual a orquestração da Apollo é construída não é “como rodamos cem agents de uma vez”. É a mais antiga e mais difícil por baixo: dado este trabalho específico, qual é o número certo de mentes, e como confiamos no que cada uma delas afirma? Às vezes a resposta é muitas, distribuídas e reavaliadas independentemente. Às vezes a resposta é uma, deixada em paz para pensar. Saber a diferença é a habilidade inteira, para software, e acontece que, para empresas.

---

É isso que estamos construindo na Apollo Space: não um enxame por si só, mas um orchestrator que lê uma tarefa antes de dividi-la, reavalia tudo que divide, e não tem vergonha de entregar o problema fortemente enrolado a um único agent e ir embora. A coordenação mais barata é a coordenação que você foi sábio o suficiente para não criar.