Multi-Agent Systems: como arquitetar centenas de agentes trabalhando juntos

Um agente sozinho é uma demo. Duzentos agentes coordenados é uma empresa. A próxima batalha de arquitetura não é construir o agente mais inteligente: é orquestrar exércitos deles sem que a coisa inteira pegue fogo. E a maioria das empresas vai descobrir isso da pior forma.

No artigo 15 da série, eu defendi que o Agentic OS é o novo sistema operacional: um kernel que agenda processos que pensam. Mas todo sistema operacional precisa responder uma pergunta brutal: o que acontece quando você tem centenas de processos rodando ao mesmo tempo, todos com iniciativa própria, todos capazes de agir, todos achando que a prioridade deles é a mais importante?

Em um SO clássico, o scheduler resolve isso em silêncio, em microssegundos. Em um sistema multiagente, os "processos" argumentam, negociam, contratam uns aos outros e às vezes sabotam o resultado por acidente. Otimismo ingênuo vira caos. Caos vira custo. Custo vira cancelamento de contrato.

1. A lei fundamental: coordenação é o gargalo, não inteligência

Todo time técnico cai no mesmo erro: gasta 90% do esforço tornando cada agente mais inteligente (prompt melhor, modelo melhor, RAG melhor) e 10% na coordenação entre eles.

Os números do mundo real dizem o contrário.

• Gargalo de performance: agente único = qualidade do modelo. MAS = arquitetura de coordenação.
• Modo de falha comum: agente único = alucinação. MAS = deadlock, duplicação de trabalho, cascata de erro.
• Custo dominante: agente único = tokens de inferência. MAS = tokens de coordenação (às vezes 40–60% do total).
• Debug: agente único = ler um trace. MAS = reconstruir uma conversa entre 12 entidades.
• Escalonamento: agente único = trocar o modelo. MAS = redesenhar a topologia.

A analogia que uso com todo CTO: um agente único é um freelancer genial. Um sistema multiagente é uma empresa de 300 funcionários. Contratar 300 gênios não garante nada se não houver estrutura, processos e um organograma. Gênios sem organograma produzem guerra civil.

2. As topologias: escolha seu organograma agêntico

Não existe "arquitetura multiagente". Existem topologias, e cada uma tem um modo de falha característico. Escolher errado a topologia é como montar uma empresa com o organograma errado: não importa quão bons são os funcionários.

• Orquestração (hub-and-spoke): use em tarefas heterogêneas com controle forte. Falha: orquestrador vira gargalo e ponto único de falha. Custo de coordenação: médio.
• Hierarquia (árvore): use em escala de verdade (100+ agentes) e domínios distintos. Falha: gerentes repassam objetivo distorcido ("telefone sem fio"). Custo: baixo-médio.
• Pipeline (linha de montagem): use em fluxo determinístico (ETL, revisão de conteúdo). Falha: etapa lenta trava a fila inteira. Custo: baixo.
• Swarm / mesh (debate entre pares): use em problemas sem resposta conhecida e verificação cruzada. Falha: loops infinitos de debate, custo explode. Custo: alto.
• Mercado (leilão / contratação): use em workload dinâmico com agentes de custos diferentes. Falha: "vencedores" se sobrecarregam e games do sistema. Custo: variável.

A resposta de engenharia madura: topologia híbrida. O Agentic OS usa hierarquia entre times, orquestração dentro do time, e swarm apenas para as decisões críticas que merecem debate, porque debate é caro.

3. Anatomia de um MAS de produção: os 6 componentes não-negociáveis

Qualquer sistema multiagente sério tem estes órgãos. Se falta um, você não tem um MAS: tem uma sala de chat com bots.

3.1 Blackboard / estado compartilhado

O "quadro branco" onde todos os agentes leem e escrevem. Sem ele, cada agente reconstrói sua visão própria da realidade, e duas visões de realidade em conflito é a definição técnica de bug de produção. Implementação típica: store transacional com versionamento (o histórico de decisões importa mais que o estado atual).

3.2 Barramento de mensagens (A2A)

No artigo de protocolos da série, apresentei o Agentic Web: MCP para agentes falarem com ferramentas, A2A para agentes falarem com agentes. O MAS é onde o A2A deixa de ser padrão bonito e vira requisito de sobrevivência. Cada mensagem precisa ter: identidade verificável, intenção, deadline e custo declarado.

3.3 Memory hierarchy compartilhada

Memória de curto prazo (blackboard), memória de tarefa (contexto do job atual), memória institucional (o que a organização de agentes aprendeu). No Agentic OS, a memória era o sistema de arquivos. No MAS, ela é o patrimônio: o que sobrevive quando os processos (agentes) morrem.

3.4 Contratos de interface

Agente que não cumpre contrato não entra no sistema. Cada agente publica um manifest: o que faz, o que consome, o que produz (estruturado, não prosa livre), SLA e custo estimado. Sem manifestos, você não tem orquestração: tem telepatia com orçamento de GPU.

3.5 Observabilidade total

Você não pode debugar o que não pode reproduzir. Cada decisão de cada agente precisa ser rastreável: qual mensagem originou, qual dado consultou, quanto custou, o que decidiu e por quê. É o flight recorder do avião, e num MAS o avião cai com frequência estatística.

3.6 A guarda (policy layer)

O subsistema de segurança (Agent Harness e Zero Trust) aplicado à escala: nenhum agente confia em outro agente por padrão. Permissões são escopo por tarefa, revogáveis, auditadas. Em um sistema onde "funcionários" escrevem código e movem dinheiro, Zero Trust não é paranoia: é RH.

4. O problema duro: deadlocks, cascatas e a entropia agêntica

Aqui está onde 80% dos MAS morrem. Não na arquitetura feliz: nos modos de falha.

• Deadlock circular: agente A espera B, B espera A, ambos esperam eternamente (análogo: deadlock de processos).
• Cascata de erro: um agente publica dado errado no blackboard; 30 agentes constroem sobre ele (análogo: corrupção de cache compartilhado).
• Tempestade de mensagens: cada mensagem gera N mensagens de resposta; exponencial (análogo: broadcast storm).
• Duplicação de esforço: dois agentes "espertos" resolvem a mesma tarefa em paralelo (análogo: race condition).
• Divergência de objetivos: agente otimiza a métrica dele contra o objetivo global (análogo: cada time com seu OKR, guerra fria).

As contramedidas que realmente funcionam em produção:

• Deadlines obrigatórios: toda mensagem tem TTL. Agente que não responde em X segundos é declarado morto e a tarefa é reatribuída. Sem piedade.
• Escrita única, leitura múltipla: cada artefato do blackboard tem exatamente um dono. Race conditions morrem por desenho.
• Validação de entrada entre agentes: nenhum agente consome dado de outro sem validar schema. Agentes são tratados como APIs hostis (Zero Trust entre pares).
• Orçamento por tarefa, não por agente: cada job entra com um budget de tokens/dinheiro. Estourou o orçamento, a tarefa sobe na hierarquia pedindo aprovação (o "modo kernel" do Agentic OS).
• Circuit breaker agêntico: agente com taxa de erro acima do limite é removido da rotação e enviado para diagnóstico automático. O sistema degrada graciosamente, como um cluster bem operado.

5. Escala real: o que muda de 5 para 500 agentes

A arms race atual é "quantos agentes seu sistema suporta". A pergunta certa é: o que quebra primeiro quando você multiplica por 10?

• 5–10 agentes: orquestração central, tudo em memória. Quebra primeiro: orquestrador vira gargalo; ninguém percebe.
• 10–50: hierarquia com times, blackboard transacional. Quebra primeiro: custo de coordenação; logs impossíveis de ler.
• 50–200: registro de manifestos, descoberta dinâmica, mercado interno de tarefas. Quebra primeiro: divergência de objetivos; agentes com "política" interna.
• 200–500+: MAS como plataforma: células semi-independentes com orçamento próprio, autogovernadas com policy central. Quebra primeiro: governança. Agora você gerencia uma cidade, não um sistema.

Perceba o padrão: cada salto de escala não adiciona agentes: muda a arquitetura. É o mesmo salto conceitual de "aplicativo monolítico" para "organização de serviços". Quem escala MAS somando agentes sem redesenhar a coordenação constrói o equivalente a um monólito distribuído: o pior dos dois mundos, com fatura de GPU.

E aqui está o insight que quase ninguém escreve: a partir de ~200 agentes, o design converge para o formato de uma empresa real. Células com orçamento (unidades de negócio), mercado interno de tarefas (contratação), policy central (compliance), memória institucional (cultura e processos). Não é coincidência: é a mesma teoria de sistemas que a administração descobriu há décadas, agora executada por processos que pensam. Arquitetar MAS é, literalmente, desenhar uma organização.

6. Analogia final: a orquestra sem maestro (e com)

Uma orquestra de 100 músicos não funciona porque cada músico é virtuoso: os solistas de conservatório são, individualmente, melhores que 95% dos músicos de orquestra. Ela funciona porque existe partitura, regência, seções e protocolo de ensaio.

• A partitura é o blackboard compartilhado.
• O maestro é o orquestrador, que, ironicamente, no MAS moderno às vezes é apenas outro agente com mandato diferente.
• As seções são os times hierárquicos.
• O protocolo de ensaio é a observabilidade: gravar tudo para revisar tudo.

E quando o maestro falha? As orquestras profissionais continuam tocando alguns compassos, porque os músicos leem uns aos outros. Esse é o estado da arte em MAS: sistemas onde a coordenação não morre com o coordenador. Redundância de regência.

7. Roteiro de 90 dias: do monólito agêntico ao MAS de produção

Dias 1–30: fundação (o esqueleto)

• Mapeie os processos do negócio como domínios independentes (não como prompts diferentes: como competências distintas).
• Implemente o blackboard com versionamento e escrita única por artefato.
• Defina o contrato de mensagem A2A: identidade, intenção, deadline, custo.
• Critério de sucesso: dois agentes completam uma tarefa de duas etapas lendo/escrevendo o mesmo estado, com trace completo de quem fez o quê.

Dias 31–60: tensão controlada (os órgãos)

• Suba para 10–15 agentes em hierarquia com manager agents.
• Implemente budgets por tarefa e circuit breakers.
• Simule falhas deliberadamente: mate agentes no meio de jobs, injete dados corrompidos.
• Critério de sucesso: o sistema recupera sozinho de um agente morto sem intervenção humana, dentro do deadline da tarefa.

Dias 61–90: escala e governança (o sistema nervoso)

• 50+ agentes com descoberta dinâmica via manifestos.
• Swarm/mercado apenas nos pontos de decisão crítica.
• Dashboard de observabilidade: custo por tarefa, taxa de erro por agente, deadlocks, orçamentos estourados.
• Critério de sucesso: uma semana de operação com zero intervenção humana e custo por tarefa estável ou em queda.

Conclusão: o exército é fácil. A guerra é difícil.

A tentação de 2026 é comprar "agentes" como se compra headcount: mais agentes, mais produtividade. É a mesma lógica que criou os monólitos gigantes de microservices: empresas com 400 serviços e o custo operacional de 400 times para entregar o que uma equipe coesa entregava antes.

Multi-Agent Systems não são sobre quantidade. São sobre estrutura. Sobre desenhar uma organização onde os funcionários pensam em milissegundos, nunca dormem, e precisam de contratos, orçamentos e supervisão exatamente como pessoas, porque qualquer sistema com iniciativa distribuída desenvolve, inevitavelmente, política.

Arquitetar centenas de agentes trabalhando juntos é o trabalho mais difícil da nossa era de software: é engenharia de sistemas, teoria de organizações, economia de incentivos e segurança, tudo ao mesmo tempo, em uma plataforma que executa decisões na velocidade da luz.

Um dia, o currículo de arquitetura de software terá duas aulas: como construir sistemas que obedecem, e como construir sistemas que cooperam. Quem só estudou a primeira está obsoleto.

Se sua empresa está montando (ou tentando domar) um sistema multiagente, do esqueleto de coordenação à governança de centenas de agentes, fale com a EmerSoftware. Arquitetamos MAS de produção, com controle, custo e observabilidade desde o primeiro dia.