Agentes LLM são só sistemas distribuídos

A comunidade de IA está construindo sistemas multiagente — equipes de LLMs que dividem o trabalho, se comunicam e colaboram para resolver problemas que nenhum modelo isolado consegue lidar. Um agente 'pesquisador' reúne informações, um agente 'programador' escreve a implementação, um agente 'revisor' verifica a qualidade, e um agente 'coordenador' gerencia o fluxo de trabalho. A proposta é atraente: agentes especializados colaborando como um time de engenharia bem azeitado.

Se isso soa familiar, não é por acaso. Pesquisadores de sistemas distribuídos estudam a coordenação de processos independentes há 40 anos. Sistemas multiagente com LLMs estão redescobrindo, a partir do zero, problemas que a comunidade de sistemas distribuídos resolveu (ou provou serem insolúveis) décadas atrás. Entender esses paralelos evita que você reinvente soluções — e que construa sistemas que falham de maneiras previsíveis e bem conhecidas.

O Custo da Coordenação

A primeira lição de sistemas distribuídos: coordenação tem overhead. Dois processos trabalhando de forma independente em tarefas separadas são duas vezes mais rápidos que um. Já dois processos trabalhando na mesma tarefa, precisando se coordenar, costumam ser mais lentos que um só — porque o overhead de comunicação e sincronização supera o ganho do paralelismo.

Sistemas multiagente com LLMs caem nisso imediatamente. Um agente 'pesquisador' produz um relatório. O agente 'programador' precisa entender o relatório para escrever código. O agente 'revisor' precisa entender tanto o relatório quanto o código para dar um feedback útil. Cada passagem de bastão exige serializar o contexto em um prompt, que o agente receptor precisa interpretar. Esse é exatamente o problema de estado compartilhado dos sistemas distribuídos — e fica pior à medida que você adiciona agentes.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

Em sistemas distribuídos, isso é a Lei de Amdahl aplicada à comunicação: o ganho de velocidade do paralelismo é limitado pela parte sequencial da comunicação que não pode ser paralelizada. Adicionar mais agentes a uma tarefa que exige coordenação forte deixa o sistema mais lento, não mais rápido.

O Problema do Consenso

Quando vários agentes trabalham na mesma tarefa, eles precisam concordar em algumas coisas. Quais são os requisitos? Qual abordagem seguir? Essa implementação está correta? Em sistemas distribuídos, isso é o problema do consenso, e ele é comprovadamente difícil — o resultado de impossibilidade FLP mostra que consenso determinístico é impossível em um sistema assíncrono com sequer um processo defeituoso.

Agentes LLM são piores que processos distribuídos tradicionais para consenso porque são não determinísticos. Faça a mesma pergunta ao mesmo agente duas vezes e você pode receber respostas diferentes. Dois agentes revisando o mesmo código podem discordar sobre se ele está correto. Um agente 'coordenador' chamado para resolver a divergência pode acabar jogando uma moeda.

Frameworks multiagente geralmente lidam com isso designando um agente coordenador com autoridade final (um modelo de consenso centralizado — simples, mas cria um ponto único de falha) ou por votação majoritária (caro — você precisa de pelo menos três agentes por decisão). As duas abordagens funcionam, mas estão resolvendo um problema que só existe porque você dividiu o trabalho entre vários agentes para início de conversa.

Modos de Falha que Deveriam Ser Familiares

Sistemas multiagente falham de formas que engenheiros de sistemas distribuídos vão reconhecer imediatamente.

• Falhas em cascata. O agente A produz uma saída ruim. O agente B, trabalhando a partir da saída de A, produz algo pior. O agente C, revisando o trabalho de B, não percebe o erro original porque herdou as premissas erradas. É o equivalente em sistemas distribuídos da propagação de erros — lixo entra, lixo sai, amplificado em cada etapa.
• Deadlocks. O agente A espera a saída do agente B para prosseguir. O agente B espera o feedback do agente A para prosseguir. Nenhum dos dois avança. Na prática, isso aparece como loops infinitos em que os agentes ficam passando o trabalho de um lado para o outro sem convergir.
• Split brain. Dois agentes trabalhando em tarefas relacionadas desenvolvem visões inconsistentes do problema. Um assume que a API retorna JSON; o outro assume XML. As saídas de cada um estão corretas isoladamente, mas são mutuamente incompatíveis.
• Thundering herd. Um agente coordenador despacha trabalho para vários agentes ao mesmo tempo. Todos batem na mesma API, esgotam o mesmo rate limit ou tentam modificar o mesmo arquivo. Contenção de recursos que um agente único nunca enfrentaria.

Quando Multiagente Realmente Ajuda

O paralelo com sistemas distribuídos vale nos dois sentidos. Sistemas distribuídos têm benefícios reais para problemas específicos. Sistemas multiagente também — quando usados em problemas que se beneficiam de verdade da decomposição.

Tarefas embaraçosamente paralelas. Se você precisa analisar 50 bases de código em busca do mesmo padrão, 50 agentes trabalhando de forma independente são de fato 50 vezes mais rápidos. Nenhuma coordenação é necessária — cada agente trabalha em uma entrada separada e produz uma saída independente. Esse é o padrão MapReduce, e funciona tão bem para agentes LLM quanto para processamento distribuído de dados.

Perspectivas diversas. Pedir a três agentes com system prompts diferentes que revisem o mesmo código pode revelar problemas que uma única revisão deixaria passar. É o padrão de redundância — como ter vários revisores em um PR. O custo é três vezes mais computação, mas a cobertura é mais ampla.

Especialização com interfaces limpas. Um agente de tradução que recebe texto e devolve texto traduzido tem uma interface limpa. Um agente de sumarização que recebe um documento e devolve um resumo também. Compor os dois — traduzir e depois resumir — funciona bem porque a interface entre eles é simples. O equivalente em sistemas distribuídos: microsserviços com APIs bem definidas funcionam melhor do que microsserviços com interfaces complexas e muito verbosas.

Lições dos Sistemas Distribuídos

Se você está construindo sistemas multiagente com LLMs, décadas de sabedoria em sistemas distribuídos se aplicam diretamente.

1. Prefira poucos agentes mais capazes a muitos especializados. Assim como um monólito bem projetado supera uma arquitetura de microsserviços mal feita, um único agente capaz, com bons prompts, supera um time de agentes limitados na maioria das tarefas. Adicione agentes só depois de provar que um agente sozinho não dá conta da carga.
2. Defina interfaces claras entre os agentes. A entrada e a saída de cada agente devem ser bem definidas. Passagens vagas ('descubra o que o pesquisador encontrou e implemente') levam a perda de contexto e interpretações erradas. Contratos de dados estruturados entre agentes funcionam melhor do que texto livre.
3. Torne os agentes idempotentes. Se um agente falhar no meio do caminho, você deve conseguir reiniciá-lo com a mesma entrada e obter um resultado correto. Isso exige agentes sem estado oculto e sem efeitos colaterais até que tenham confirmado que a saída está correta.
4. Adicione observabilidade. Registre cada mensagem entre agentes, cada decisão e cada falha. Quando um sistema multiagente produz uma saída errada, você precisa rastrear o erro até o agente que tomou a decisão errada e entender por quê. Sem observabilidade, depurar vira adivinhação.
5. Projete para falhas parciais. Qualquer agente pode falhar, produzir lixo ou estourar o timeout. O sistema deve lidar com isso de forma elegante — tentando de novo, recorrendo a uma abordagem mais simples ou pedindo ajuda a um humano. Nunca presuma que todos os agentes vão ter sucesso.

A Verdade Incômoda

A maioria dos sistemas multiagente com LLMs funcionaria melhor como um único agente com um bom prompt. O overhead de coordenação, a perda de contexto e os modos de falha de arquiteturas multiagente quase sempre superam os benefícios em tarefas que um único modelo consegue resolver. Conforme as ferramentas de IA evoluem, a tentação de construir sistemas multiagente elaborados cresce, mas a lição dos sistemas distribuídos é clara: não distribua o que não precisa ser distribuído.

As exceções são reais — tarefas embaraçosamente paralelas, especialização genuína com interfaces limpas e problemas que excedem a janela de contexto de um único modelo. Para todo o resto, um único agente com um prompt bem estruturado, boas ferramentas e uma estratégia de retry bem pensada vai superar um time de agentes. É menos empolgante arquiteturalmente, mas funciona melhor. O melhor sistema distribuído é aquele que você não precisou construir.