Todo projeto de agente começa com um agente só. Ele atende bem, o time adiciona uma capacidade, depois outra, e em algum momento a qualidade cai sem que ninguém tenha mudado nada. A instrução virou uma página e meia, o agente tem vinte ferramentas disponíveis e passou a escolher errado com frequência.
Esse é o ponto em que arquitetura multiagente deixa de ser sofisticação e vira necessidade. O padrão supervisor é a forma mais previsível de organizá-la, e este texto explica como ele funciona, o que ele custa e quando não usar.
Por que o agente único degrada
A degradação tem duas causas, e as duas são mecânicas, não misteriosas.
A primeira é competição por atenção na instrução. Cada regra nova disputa espaço com as anteriores. Um prompt que descreve vendas, financeiro e suporte ao mesmo tempo obriga o modelo a decidir, a cada mensagem, qual dos três papéis assumir, antes de decidir o que responder.
A segunda é ruído no catálogo de ferramentas. Escolher entre três ferramentas é fácil. Entre vinte, com nomes parecidos e descrições que se sobrepõem, o erro de escolha cresce rápido. E erro de escolha de ferramenta é caro: gera chamada errada, resposta inútil e uma nova tentativa.
O que é o padrão supervisor
No padrão supervisor existe um agente que não executa o trabalho. Ele lê o pedido, decide quem deve tratar e encaminha. Os especialistas fazem o trabalho de fato, cada um com a sua instrução curta e o seu conjunto pequeno de ferramentas, e devolvem ao supervisor, que decide se a resposta está pronta ou se falta uma etapa.
Três propriedades derivam desse desenho, e são elas que justificam o custo:
- Cada especialista fica simples. Instrução curta, poucas ferramentas, escopo claro. É a condição para a qualidade parar de cair conforme o sistema cresce.
- A decisão de roteamento fica num lugar só. Quando o encaminhamento erra, existe um ponto para corrigir, em vez de uma regra espalhada por cinco prompts.
- Adicionar capacidade não mexe no que já funciona. Um especialista novo entra sem alterar a instrução dos outros, que é exatamente o que não acontece no agente único.
As quatro topologias, e quando usar cada uma
| Topologia | Como funciona | Quando é a escolha certa |
|---|---|---|
| Agente único | Um agente, uma instrução, um conjunto de ferramentas. | Escopo estreito e estável. Enquanto a qualidade não cair, é a arquitetura certa e a mais barata de operar. |
| Cadeia | Etapas fixas em ordem: extrair, validar, registrar. | O processo é determinístico e a ordem nunca muda. Não precisa de modelo decidindo o caminho. |
| Supervisor | Um roteador decide qual especialista trata cada pedido. | Domínios distintos com fronteira clara (vendas, financeiro, suporte). É o caso mais comum em operação. |
| Rede | Agentes se chamam entre si, sem centro. | Problemas exploratórios sem caminho previsível. Flexível e difícil de auditar: raramente é o desenho certo em processo de negócio. |
Se o seu processo tem ordem fixa, você não precisa de supervisor: precisa de cadeia. Colocar um modelo para decidir o que já está decidido é pagar por latência e variabilidade sem receber nada em troca.
Como o roteamento funciona na prática
O supervisor decide com base em três entradas: a mensagem atual, o histórico da conversa e a descrição de cada especialista. A terceira é a que os times mais negligenciam e a que mais afeta o resultado.
Descrição de especialista não é rótulo, é critério de decisão. "Agente financeiro" não diz ao supervisor se segunda via de boleto é com ele ou com o suporte. "Trata cobrança, segunda via de boleto, renegociação e status de pagamento; não trata cancelamento de contrato" diz. A parte que começa com "não trata" costuma resolver mais casos de roteamento errado do que a parte afirmativa.
Dois cuidados que evitam a maioria dos problemas de encaminhamento:
- Fronteiras que não se sobrepõem. Se dois especialistas podem legitimamente atender o mesmo pedido, o roteamento fica instável e o mesmo cliente recebe tratamento diferente em dias diferentes.
- Um caminho para o que não se encaixa. Sem destino de fallback explícito, o supervisor escolhe o especialista menos errado e a resposta sai confiante e fora do escopo. Um caminho para o humano é melhor que um palpite.
O que quebra em produção
Custo multiplicado
Cada salto entre supervisor e especialista é pelo menos uma chamada de modelo a mais, carregando contexto. Um pedido que o agente único resolvia em uma chamada pode consumir três ou quatro. O ganho de qualidade costuma compensar, mas precisa ser medido, não presumido. Um ajuste prático: o supervisor raramente precisa do modelo mais caro, porque a tarefa dele é classificar, não redigir.
Perda de contexto na passagem
O especialista recebe o pedido, mas nem sempre recebe o que já foi dito antes. O sintoma clássico é o cliente que precisa repetir a informação que acabou de dar ao trocar de assunto. Definir explicitamente o que atravessa a fronteira (histórico completo, resumo ou só o pedido atual) é decisão de arquitetura, não detalhe de implementação.
Laço entre agentes
O supervisor manda para o financeiro, que entende que o caso é de suporte e devolve, e o supervisor manda de novo. Sem limite de saltos e sem registro de por onde o pedido já passou, o laço só aparece na fatura do fim do mês.
Erro sem dono
Quando a resposta sai errada, a pergunta é onde. Roteamento errado, especialista com instrução ruim, ferramenta que devolveu dado desatualizado. Sem trilha por execução, com a decisão de cada salto registrada, a depuração vira tentativa e erro sobre um sistema que muda de comportamento a cada rodada.
O que medir desde o primeiro dia
- Acerto de roteamento. Percentual de pedidos que foram para o especialista certo na primeira tentativa. É a métrica que diz se o problema está no supervisor ou nos especialistas.
- Saltos por pedido. A média revela laço e roteamento instável antes de o custo chamar atenção.
- Custo por pedido resolvido, e não custo por chamada. Chamada barata que não resolve é a mais cara de todas.
- Transbordo para humano, separado por motivo: fora de escopo, falta de confiança ou falha técnica. Os três pedem correções diferentes.
Quando não usar multiagente
Vale dizer com clareza, porque a arquitetura virou moda e o custo dela é real. Fique no agente único quando:
- O escopo é estreito e a qualidade está estável. Não existe prêmio por complexidade.
- As tarefas compartilham quase todo o contexto. Separar em especialistas só recria a passagem de contexto como problema novo.
- O processo tem ordem fixa. Isso é cadeia, e cadeia é mais barata e mais previsível.
- Você ainda não mede nada. Sem observabilidade, multiagente não é mais capaz: é mais difícil de depurar.
Como isso aparece na Runflow
O SDK TypeScript da Runflow traz o padrão supervisor como primitiva, ao lado de ferramentas tipadas, memória com resumo automático e Agentic RAG, tudo definido em código versionado no seu Git. No Conversation Hub, é o supervisor que orquestra especialistas de vendas, financeiro e suporte por contexto, na mesma thread em que o atendente humano trabalha.
A parte que sustenta essa arquitetura em produção não é o roteamento, é o registro: cada execução, decisão e chamada de ferramenta fica gravada e reproduzível. É o que permite responder onde o pedido errou, em vez de supor.
