Um orquestrador, muitas mãos: multiagente que funciona

Anda por aí uma demo — já viu certamente uma versão dela. Uma pequena sociedade de agentes de IA: um agente-CEO define a estratégia, um agente-PM escreve os tickets, agentes-programadores discutem a implementação, um agente-QA revê tudo. Conversam entre si numa linguagem natural eloquente. A transcrição lê-se como uma empresa que finalmente alcançou a comunicação perfeita. A sala aplaude.

Depois alguém tenta pô-la a correr em trabalho real e a sociedade desfaz-se — educadamente, prolixamente, caramente.

A tese deste artigo: os sistemas multiagente chegam a produção quando são construídos como sistemas distribuídos e morrem quando são construídos como pequenas empresas. O padrão que sobrevive em produção não tem glamour: um orquestrador com autoridade real, muitas mãos estreitas, handoffs tipados, uma espinha determinista. Tudo o resto que hoje se vende como "multiagente" é sobretudo teatro — impressionante exatamente da forma e exatamente durante o tempo que uma demo exige. Já escrevemos sobre esse fosso em O abismo entre a demo e a produção; este é o capítulo sobre o que construir em vez disso.

Teatro multiagente, diagnosticado

Porque é que o padrão da sociedade de agentes colapsa fora da demo? Quatro razões mecânicas — não é preciso filosofia:

Os erros acumulam-se a cada salto. Encadeie componentes probabilísticos através de linguagem natural e o ruído multiplica-se. Uma precisão por mensagem que parece alta transforma-se num lançamento de moeda ao fim de saltos suficientes — e as sociedades de agentes adoram saltos; a deliberação é a sua estética.
A linguagem natural é um péssimo formato de transporte. Quando o agente A diz ao agente B que "o cliente parece flexível quanto ao prazo", o que é que B fica a saber ao certo? Conversa entre agentes é ambiguidade serializada. Cada mensagem precisa de interpretação e cada interpretação é uma nova oportunidade de desvio.
O custo explode de forma quase quadrática. Cada "reunião" interna queima tokens. A companhia de teatro delibera até esgotar o orçamento antes sequer de tocar na tarefa real.
Ninguém é dono do estado. Quando cinco agentes têm cada um uma imagem parcial, e possivelmente contraditória, nas suas janelas de contexto, a "verdade atual" do sistema é um boato distribuído por amnésicos. Quando falha às 2 da manhã, não há uma linha de log que diga aquilo em que o sistema acreditava — há transcrições, e vai lê-las como quem lê as borras do café.

O sinal revelador é o diagrama. Se o slide da arquitetura parece um organograma, construiu uma empresa — incluindo as reuniões, os mal-entendidos e a folha salarial, só que denominada em tokens.

O padrão que chega a produção

O que sobrevive ao contacto com a produção parece menos uma sociedade e mais uma cozinha bem gerida: um chef, várias praças, comandas a andar sobre carris.

Um orquestrador, com autoridade. Um único componente planeia o trabalho, encaminha tarefas, é dono do estado, avalia resultados, repete falhas e decide quando entram humanos. É a única parte do sistema com direito a ter uma opinião sobre o todo. Pode ser um LLM com um plano; pode ser — melhor, sempre que possível — um motor de workflow determinista que chama LLMs nos passos que exigem julgamento.

Muitas mãos, cada uma estreita. Os trabalhadores fazem uma coisa: extrair campos deste documento, redigir esta secção, validar esta afirmação contra esta fonte, formatar este output para este canal. Âmbito estreito, contexto apertado, testáveis individualmente — uma mão, não um colega. O modelo mental produtivo é uma função com discernimento, e as funções têm assinaturas.

Handoffs tipados, não conversas. As mãos recebem input estruturado e devolvem output estruturado — esquemas, não prosa. {claim, source, verdict, confidence} pode ser validado, registado, comparado e repetido. "Acho que isto bate certo, na maior parte!" não pode. Cada interface em que substitui conversa por tipos elimina uma espécie inteira de falhas.

Uma espinha determinista. Por baixo de tudo: filas, retries, timeouts, chaves de idempotência, vias de dead-letter — engenharia de workflow aborrecida, do tipo que já era madura antes de os LLMs chegarem. A inteligência é cara e probabilística; a canalização é barata e certa. Gaste a inteligência apenas onde vive o julgamento e deixe o código ser código — o argumento que defendemos sem rodeios em O determinismo é uma funcionalidade.

Desta forma decorrem quatro regras:

Um único escritor do estado. Só o orquestrador atualiza o registo do ponto de situação. Os restantes devolvem resultados e vão para casa.
Contratos, não conversa. Se dois componentes trocam linguagem natural, um deles está prestes a ser mal interpretado.
As mãos podem falhar; a orquestração não. Qualquer trabalhador pode entrar em timeout, alucinar ou devolver lixo — e o sistema deve encolher os ombros: validar, repetir, reencaminhar ou escalar. Fragilidade nas pontas, nunca no centro.
Os humanos são um nó, não uma reflexão tardia. As portas de aprovação são passos de primeira classe no grafo — colocadas onde está o risco, com tudo o que a pessoa precisa para decidir num só relance.

Os agentes devem coordenar-se como funções, não como colegas de trabalho. Deixe as reuniões para os humanos.

Quando precisa mesmo de muitos agentes

Nada disto defende o "um modelo faz tudo". Há razões honestas de engenharia para multiplicar agentes — repare que todas elas são razões de engenharia, não antropomórficas:

Fan-out paralelo. Quarenta documentos para analisar, cinco fornecedores para investigar — tarefas estreitas e idênticas, despachadas em largura, resultados unidos pelo orquestrador. O paralelismo é uma propriedade da fila, não uma personalidade.
Isolamento de permissões. A mão que toca nas APIs de faturação e a mão que lê documentação pública devem ser processos diferentes com credenciais diferentes — desenho por raio de impacto, exatamente como separaria serviços.
Especialização de contexto. Uma mão com um prompt apertado, um conjunto pequeno de ferramentas e uma só tarefa supera um generalista a afogar-se em instruções. Especialização é foco, não títulos de cargo.
Contenção de falhas. Um investigador que alucina deve ficar em quarentena pela validação de esquema na sua fronteira — uma mão má, um artefacto rejeitado, zero contágio.

O teste decisivo para qualquer agente proposto: conseguiria desenhar a sua máquina de estados? Se o comportamento não se consegue esboçar em estados e transições — se a resposta for "os agentes desenrascam-se entre eles" —, estão a vender-lhe teatro.

Como isto é na prática

Aplicamos este padrão todos os dias, por isso os exemplos são nossos — descritos com honestidade:

O nosso hub de publicação é o diagrama tornado real. Entra um briefing. O orquestrador planeia canais e sequência. Uma mão de redação escreve; uma mão de verificação de marca valida o rascunho contra as regras estruturadas do brandbook; mãos de formatação moldam o resultado para o blogue, o LinkedIn e o Facebook; uma porta de aprovação humana antecede qualquer publicação. As mãos nunca falam entre si — cada uma devolve o seu artefacto à espinha e para. Quando um passo falha, repete ou cai numa via de erro com contexto. O resultado parece automação, não improviso — que é exatamente o que é.

O nosso motor de brandbook-para-website divide-se da mesma maneira. Os agentes trabalham a montante, a produzir e a refinar dados de marca estruturados. A jusante, um renderizador determinista transforma esses dados num website multi-tenant — mesmo input, mesmo site, sempre. As mãos estão limitadas por tipos; o caminho de entrega não improvisa. Essa divisão — julgamento a montante, determinismo a jusante — é a ideia mais reutilizável de todo o nosso trabalho em sistemas de IA.

E a espinha é n8n self-hosted numa fatia crescente dos nossos fluxos internos: filas, retries, webhooks e vias de escalamento que controlamos de ponta a ponta, com passos de LLM embebidos como nós dentro de um grafo auditável — um componente do ecossistema mais amplo sobre o qual construímos. Nada disto tem glamour. É tudo isto que faz com que as coisas continuem a correr quando ninguém está a olhar.

Repare, já agora, no que esta arquitetura faz às contas de headcount: um engenheiro sénior mais uma camada de orquestração disciplinada opera aquilo que de outra forma exigiria a coordenação de um departamento inteiro. É esse o mecanismo por trás de Equipas pequenas, grande alavancagem — a alavancagem está na espinha.

O interrogatório do comprador

Se alguém lhe apresentar um sistema multiagente — fornecedor, integrador ou nós —, seis perguntas separam quem constrói de quem faz teatro:

Mostre-me o diagrama de estados. Não o slide conceptual — os estados e as transições.
Quem é o dono do estado? Se a resposta listar mais do que um dono, encontrou o incidente futuro.
Qual é a história dos retries? Por passo: em caso de falha — repetir, reencaminhar ou humano? Decidido quando?
Quanto custa uma execução ao volume de produção? O teatro é barato de demonstrar e ruinoso de operar; quem constrói sabe o número.
O que acontece quando a mão #3 alucina? A resposta deve envolver esquemas e quarentena, não "o agente revisor costuma apanhar isso".
Onde é que os humanos aprovam? Aponte para as portas no grafo. "Depois acrescentamos supervisão" quer dizer nunca.

Respostas balbuciadas em três ou mais: está a assistir a um ensaio, não a um sistema.

A conclusão silenciosa

O futuro multiagente é real — construímo-lo e apostamos nele a empresa. Só que não se parece com a demo. Parece-se com uma cozinha em serviço: um chef a cantar o passe, praças a executar briefings estreitos, comandas a andar sobre carris, ninguém a fazer uma reunião sobre o risoto. A inteligência está em todo o lado; a autoridade está exatamente num sítio.

Se está a desenhar um sistema de agentes — ou a auditar um que delibera lindamente e não entrega nada —, fale connosco. Levamos os diagramas de estados. Até gostamos de os desenhar.