Um orquestrador, muitas mãos: multiagente em produção

Tem uma demo circulando por aí — você já viu alguma versão dela. Uma pequena sociedade de agentes de IA: um agente-CEO define a estratégia, um agente-PM escreve os tickets, agentes-desenvolvedores discutem a implementação, um agente-QA revisa. Todos conversam em linguagem natural eloquente. A transcrição parece uma empresa que finalmente atingiu a comunicação perfeita. A plateia aplaude.

Aí alguém tenta rodar isso em trabalho de verdade, e a sociedade desmorona — de forma educada, prolixa e cara.

A tese deste texto: sistemas multiagente entram em 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 à produção não tem glamour nenhum: um orquestrador com autoridade de verdade, muitas mãos estreitas, handoffs tipados, uma espinha determinística. Todo o resto que hoje é vendido como "multiagente" é basicamente teatro — impressionante exatamente do jeito e exatamente pelo tempo que uma demo exige. Já escrevemos sobre esse abismo em O abismo entre a demo e a produção; este aqui é o capítulo sobre o que construir no lugar.

Teatro multiagente, diagnosticado

Por que o padrão sociedade-de-agentes desmorona fora da demo? Quatro razões mecânicas — nenhuma filosofia necessária:

Os erros se acumulam a cada salto. Encadeie componentes probabilísticos via linguagem natural e o ruído se multiplica. Uma acurácia por mensagem que parece alta vira cara ou coroa depois de saltos suficientes — e sociedades de agentes adoram saltos; deliberar é a estética delas.
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 exatamente B sabe agora? Chat entre agentes é ambiguidade serializada. Cada mensagem precisa de interpretação, e cada interpretação é uma nova chance de desvio.
O custo explode de forma quase quadrática. Cada "reunião" interna queima tokens. A trupe delibera até consumir seu orçamento antes mesmo de encostar na tarefa real.
Ninguém é dono do estado. Quando cinco agentes carregam, cada um, uma visão parcial e possivelmente contraditória nas suas janelas de contexto, a "verdade atual" do sistema é um boato distribuído entre amnésicos. Quando quebra às 2h da manhã, não existe linha de log dizendo no que o sistema acreditava — existem transcrições, e você vai lê-las como quem lê borra de café.

O sinal de alerta é o diagrama. Se o slide da arquitetura parece um organograma, você construiu uma empresa — com reuniões, mal-entendidos e folha de pagamento inclusos, só que denominada em tokens.

O padrão que entra em produção

O que sobrevive ao contato com a produção parece menos uma sociedade e mais uma cozinha bem tocada: um chef, várias estações, comandas nos trilhos.

Um orquestrador, com autoridade. Um único componente planeja o trabalho, roteia tarefas, é dono do estado, julga resultados, repete o que falhou e decide quando um humano entra. É a única parte do sistema com direito a ter opinião sobre o todo. Pode ser um LLM com um plano; pode ser — melhor, sempre que possível — um workflow engine determinístico que chama LLMs nos passos que exigem julgamento.

Muitas mãos, cada uma estreita. Os workers fazem uma coisa só: extrair campos deste documento, redigir esta seção, validar esta afirmação contra esta fonte, formatar esta saída para este canal. Escopo estreito, contexto enxuto, testável individualmente — uma mão, não um colega. O modelo mental produtivo é o de uma função com cabeça, e funções têm assinatura.

Handoffs tipados, não conversas. As mãos recebem input estruturado e devolvem output estruturado — schemas, não prosa. {claim, source, verdict, confidence} dá para validar, logar, comparar e reprocessar. "Acho que isso bate na maior parte!" não dá. Cada interface em que você troca chat por tipos elimina uma espécie inteira de falha.

Uma espinha determinística. Por baixo de tudo: filas, retries, timeouts, chaves de idempotência, dead-letter — engenharia de workflow chata, do tipo que já era madura antes de os LLMs chegarem. Inteligência é cara e probabilística; encanamento é barato e certo. Gaste inteligência só onde mora o julgamento e deixe código ser código — o argumento que já fizemos sem rodeios em Determinismo é uma feature.

Quatro regras saem desse formato:

Um único escritor do estado. Só o orquestrador atualiza o registro de onde as coisas estão. Todo o resto devolve resultado e vai embora.
Contratos, não chat. 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 worker pode dar timeout, alucinar ou devolver lixo — e o sistema deve dar de ombros: validar, repetir, redirecionar ou escalar. Fragilidade nas bordas, nunca no centro.
Humanos são um nó, não um detalhe de última hora. Portões de aprovação são passos de primeira classe no grafo — colocados onde mora o risco, com tudo o que a pessoa precisa para decidir em uma olhada.

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

Quando você realmente precisa de vários agentes

Nada disso defende o um-modelo-faz-tudo. Existem 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 pesquisar — tarefas estreitas e idênticas, disparadas em paralelo, resultados unidos pelo orquestrador. Paralelismo é propriedade de fila, não de personalidade.
Isolamento de permissões. A mão que toca APIs de billing e a mão que lê docs públicos precisam ser processos diferentes, com credenciais diferentes — design de raio de impacto, exatamente como você separaria serviços.
Especialização de contexto. Uma mão com prompt enxuto, poucas ferramentas e uma única função supera um generalista se afogando em instruções. Especialização é sobre foco, não sobre cargos.
Contenção de falhas. Um pesquisador que alucina deve ser posto em quarentena pela validação de schema na sua fronteira — uma mão ruim, um artefato rejeitado, zero contágio.

O teste decisivo para qualquer agente proposto: você consegue desenhar a máquina de estados dele? Se o comportamento não dá para ser esboçado como estados e transições — se a resposta é "os agentes vão se entender entre eles" — estão te vendendo teatro.

Como isso fica na prática

Rodamos esse padrão todo dia, então os exemplos são nossos — descritos com honestidade:

Nosso hub de publicação é o diagrama virado realidade. Entra um briefing. O orquestrador planeja canais e sequência. Uma mão de redação escreve; uma mão de brand check valida o rascunho contra as regras estruturadas do brandbook; mãos de formatação moldam o resultado para o blog, o LinkedIn e o Facebook; um portão de aprovação humana fica antes de qualquer publicação. As mãos nunca conversam entre si — cada uma devolve seu artefato para a espinha e para por aí. Quando um passo falha, ele repete ou cai numa fila de erro com contexto. O resultado parece automação, não improviso — que é exatamente o que é.

Nosso motor de brandbook-para-site se divide da mesma forma. Os agentes trabalham a montante, produzindo e refinando dados estruturados de marca. A jusante, um renderizador determinístico transforma esses dados em um site multi-tenant — mesmo input, mesmo site, sempre. As mãos são delimitadas por tipos; o caminho de entrega não improvisa. Essa divisão — julgamento a montante, determinismo a jusante — é a ideia mais reaproveitável de todo o nosso trabalho com sistemas de IA.

E a espinha é n8n self-hosted para uma fatia crescente dos nossos fluxos internos: filas, retries, webhooks e trilhas de escalonamento que controlamos de ponta a ponta, com passos de LLM embutidos como nós dentro de um grafo auditável — um componente do ecossistema mais amplo sobre o qual construímos. Nada disso tem glamour. E é justamente por isso que as coisas continuam rodando quando ninguém está olhando.

Repare, aliás, o que essa arquitetura faz com a conta de headcount: um engenheiro sênior mais uma camada de orquestração disciplinada opera o que, de outra forma, exigiria um departamento inteiro só de coordenação. É esse o mecanismo por trás de Times pequenos, alavancagem grande — a alavancagem mora na espinha.

O interrogatório do comprador

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

Me mostre o diagrama de estados. Não o slide conceitual — os estados e as transições.
Quem é dono do estado? Se a resposta listar mais de um dono, você acabou de achar o incidente do futuro.
Como funciona o retry? Passo a passo: em caso de falha — repetir, redirecionar ou chamar um humano? Decidido quando?
Quanto custa uma execução no volume de produção? Teatro é barato de demonstrar e ruinoso de operar; quem constrói sabe o número.
O que acontece quando a mão nº 3 alucina? A resposta deve envolver schemas e quarentena, não "o agente revisor normalmente pega".
Onde os humanos aprovam? Aponte os portões no grafo. "A gente adiciona supervisão depois" quer dizer nunca.

Enrolação em três ou mais: você está assistindo a um ensaio, não a um sistema.

A conclusão silenciosa

O futuro multiagente é real — construímos isso e apostamos a empresa nisso. Só que ele não se parece com a demo. Ele se parece com uma cozinha em plena operação: um chef comandando a passagem, estações executando briefings estreitos, comandas correndo nos trilhos, ninguém fazendo reunião sobre o risoto. A inteligência está em todo lugar; a autoridade está em exatamente um lugar.

Se você está desenhando um sistema de agentes — ou auditando um que delibera lindamente e não entrega nada — fale com a gente. Levamos os diagramas de estados. A gente gosta de verdade de desenhar isso.