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.
Perguntas frequentes
Como funciona uma arquitetura multiagente com supervisor?
Um agente supervisor não executa o trabalho: ele lê o pedido, decide qual especialista deve tratar e encaminha. Cada especialista tem instrução curta e poucas ferramentas, executa e devolve ao supervisor, que decide se a resposta está pronta ou se falta uma etapa. O desenho mantém cada especialista simples, concentra a decisão de roteamento num único ponto e permite adicionar capacidade sem alterar o que já funciona.
Quando usar multiagente em vez de um agente único?
Quando o escopo cresceu a ponto de a qualidade cair: instrução longa demais e muitas ferramentas com descrições que se sobrepõem fazem o modelo escolher errado com frequência. Se o escopo é estreito e estável, se as tarefas compartilham quase todo o contexto, se o processo tem ordem fixa (caso de cadeia) ou se ainda não há observabilidade, o agente único é a escolha certa e mais barata de operar.
Quais são as topologias de sistemas multiagente?
Quatro. Agente único, para escopo estreito e estável. Cadeia, com etapas fixas em ordem, para processo determinístico. Supervisor, com um roteador decidindo qual especialista trata cada pedido, indicado quando há domínios distintos com fronteira clara. E rede, em que os agentes se chamam entre si sem centro, flexível mas difícil de auditar e raramente adequada a processo de negócio.
O que quebra numa arquitetura multiagente em produção?
Quatro coisas. Custo multiplicado, porque cada salto é ao menos uma chamada de modelo a mais carregando contexto. Perda de contexto na passagem, que faz o cliente repetir informação ao trocar de assunto. Laço entre agentes, quando dois especialistas devolvem o pedido um ao outro sem limite de saltos. E erro sem dono, quando não há trilha por execução que mostre em qual etapa a resposta saiu errada.
O que medir numa arquitetura com supervisor?
Acerto de roteamento (percentual de pedidos que foram ao especialista certo na primeira tentativa), saltos por pedido, custo por pedido resolvido em vez de custo por chamada, e transbordo para humano separado por motivo: fora de escopo, falta de confiança ou falha técnica, porque cada um pede uma correção diferente.