Sistemas multiagente: orquestrador + subagentes na prática

Um único agente de IA resolve bem uma tarefa estreita. Quando o cenário cresce - tickets, documentos, código, CRM, suporte - um agente “universal” começa a misturar papéis, inflar o contexto e ficar mais caro a cada passo. Um sistema multiagente resolve de outro jeito: um orquestrador recebe o objetivo e coordena o trabalho, enquanto subagentes executam papéis estreitos com ferramentas e instruções separadas. Abaixo - como isso funciona na prática, quando o padrão compensa e quais erros matam um piloto.

• Orquestrador - plano, roteamento, controle de limites e montagem do resultado
• Subagentes - papéis estreitos: pesquisa, código, revisão, redação, CRM
• Contexto - cada agente recebe só o que precisa para o seu passo
• Controle - human-in-the-loop em ações críticas
• Início - 2-4 papéis e um cenário mensurável, não um “zoológico de agentes”
• Risco - loops infinitos, corrida de ferramentas e responsabilidade nebulosa

O que é um sistema multiagente

Um sistema multiagente é uma arquitetura em que vários agentes de IA resolvem juntos uma tarefa sob um coordenador. Diferente de um único agente com um prompt “gordo” para todos os casos, os papéis são separados:

A mesma ideia já é familiar da automação de workflows: há um despachante e executores. A diferença é que passos e ramificações são em parte escolhidos por um LLM, não só por regras rígidas if-then.

Por que separar orquestrador e subagentes

Um agente com acesso a todas as APIs parece conveniente - e rapidamente vira problema:

• O contexto infla. Em um diálogo misturam-se logs, rascunhos de e-mail, pedaços de código e exportações de CRM - o modelo perde o foco.
• O custo cresce. Cada token extra no chat “compartilhado” é pago a cada turno.
• As permissões ficam largas demais. Um agente que escreve código e também manda e-mail ao cliente é mais arriscado que um executor estreito.
• Fica mais difícil depurar. Quando tudo vive em um único loop, não fica claro o que quebrou: o plano, a ferramenta ou a redação.

A separação de papéis entrega:

1. Um system prompt estreito por subagente - menos alucinações “fora do papel”.
2. Um conjunto de ferramentas separado - um pesquisador não pode excluir uma oportunidade no CRM por acidente.
3. Paralelismo - vários subagentes podem trabalhar ao mesmo tempo (busca + rascunho + checagem de fatos).
4. Observabilidade - os logs mostram quem foi chamado, com qual entrada e com qual saída.

Design baseline: orquestrador + pool de subagentes

Um esqueleto mínimo prático:

Usuário / gatilho
        │
        ▼
   Orquestrador
   (plano, rotas, limites)
        │
   ┌────┼────┬────────┐
   ▼    ▼    ▼        ▼
 Research  Coder  Reviewer  Writer
   │    │    │        │
   └────┴────┴────────┘
        │
        ▼
   Resumo + artefatos
   (+ aprovação humana no risco)

O que o orquestrador faz

• recebe o objetivo e as restrições (tempo, orçamento de tokens, proibições);
• escolhe quais subagentes chamar e em que ordem;
• passa a cada um um brief comprimido, não o chat bruto inteiro;
• aplica limites de passos e interrompe loops;
• monta o resultado no formato que o negócio precisa (relatório, diff, cartão de negócio).

O orquestrador pode ser “fino” (só roteamento) ou “grosso” (planeja e replaneja sozinho). Para negócios, um orquestrador fino + subagentes estreitos e fortes costuma vencer: mais fácil de testar e mais barato de manter sob controle.

Subagentes típicos em cenários de negócio e dev

Você não precisa de todos os papéis no primeiro dia. Um piloto costuma precisar só de um orquestrador + 2-3 subagentes.

Quando o padrão realmente vale a pena

O design multiagente faz sentido quando pelo menos duas destas condições são verdadeiras:

• a tarefa é composta (várias habilidades: busca + síntese + ação);
• você precisa de direitos de acesso diferentes aos sistemas;
• o volume de contexto é grande - um agente “não cabe” sem perda de qualidade;
• você precisa de um revisor separado, não da autoavaliação do autor;
• o cenário se repete e pode ser descrito como um pipeline baseado em papéis.

Exemplos práticos

1. Suporte: orquestrador → Research (base de conhecimento/RAG) → Writer (resposta) → humano aprova o envio.
2. Leads e CRM: qualificação → enriquecimento → gravação no CRM → tarefa para o gestor; campos críticos checados por humano ou regra.
3. Desenvolvimento: orquestrador no Cursor / runtime de agente → subagente de exploração → coder → reviewer; deploy só após approve.
4. Conteúdo e GEO: pesquisa de tema → writer → subagente de fact-check → publicação por checklist.
5. Operações: parse de e-mail de entrada → classificação → ações via n8n/API → escalar exceções para um humano.

Se a tarefa é um if-then simples (“formulário enviado → criar negócio”), multiagentes são exagero: melhor usar automação nativa ou n8n.

Como desenhar papéis em um dia

Um checklist curto e pragmático:

1. Descreva o happy path no papel: entrada → 3-6 passos → artefato de saída.
2. Nomeie papéis por verbos: “encontrar”, “checar”, “escrever”, “gravar no CRM” - não “agente inteligente #3”.
3. Para cada papel, fixe: entrada, saída (schema/JSON), ferramentas, proibições.
4. Decida quem orquestra: planejador LLM ou grafo determinístico (muitas vezes híbrido: grafo + LLM dentro dos nós).
5. Insira human-in-the-loop onde o custo do erro é alto.
6. Defina condições de parada: máximo de passos, custo máximo, timeout, “se incerto - escalar”.

Um contrato de subagente vence um “prompt bonito”

Um bom contrato:

• entrada: { task, constraints, sources[] }
• saída: { status, summary, artifacts[], confidence, needs_human }
• proibição: “não inventar URLs”, “não alterar prod”, “não e-mailar o cliente diretamente”

Assim o orquestrador consegue mesclar respostas com confiabilidade e decidir a quem chamar em seguida.

Padrões de orquestração que funcionam

Para PME, pipeline + despachante costuma bastar. “Debates de agentes” brilham em demos e ficam caros em produção sem orçamento rígido de tokens.

Controle, segurança e custo

Um sistema multiagente sem guardrails vira rápido um bot caótico e caro.

Mínimo indispensável:

• Chaves de API e permissões separadas por papel (least privilege).
• Limites: passos, tokens, paralelismo, timeouts.
• Ações idempotentes (um retry não pode criar 5 negócios).
• Audit log: quem → com qual entrada → qual ferramenta → qual saída.
• Secrets fora do prompt: vault, env - não “colar o token na system message”.
• Aprovação humana para ações irreversíveis: pagamentos, exclusão, disparos, deploy em prod.

No custo, conte não o “preço do modelo”, e sim o preço da cadeia: orquestrador × N chamadas de subagente × retries. Às vezes uma chamada forte com bom contexto sai mais barata que cinco fracas passando JSON umas às outras.

Erros comuns de implementação

• Criar 10 subagentes “para depois” sem um cenário funcionando.
• Dar a todos o mesmo acesso a todas as ferramentas.
• Passar o log completo do orquestrador a um subagente em vez de um brief curto.
• Não limitar loops - orquestrador e reviewer discutem para sempre.
• Tratar o design multiagente como substituto de processo: sem Definition of Done clara, o sistema imita ocupação.
• Confundir com vibe coding: “deixe os agentes resolverem” sem papéis e contratos - caminho para dívida técnica.

Como iniciar um piloto de 2-3 semanas

1. Escolha um cenário com KPI mensurável (tempo de resposta, taxa de erro, minutos do gestor).
2. Monte orquestrador + dois subagentes (ex.: research + writer, ou coder + reviewer).
3. Congele contratos de entrada/saída e um checklist de escalação para humanos.
4. Rode 20-50 casos reais e rotule falhas por tipo.
5. Só então adicione um terceiro papel ou paralelismo.

A tooling pode ser um framework de agentes (LangGraph, setups estilo Crew, runtime de IDE), uma ponte para n8n nas arestas determinísticas, ou Python custom. A arquitetura de papéis importa mais que o logo do framework.

Conclusão

Orquestrador + subagentes é um padrão que funciona quando a tarefa é maior que uma habilidade e você precisa de direitos, contextos e checagens de qualidade diferentes. A força não está no número de agentes - está em papéis claros, ferramentas estreitas e paradas rígidas. Comece com um loop pequeno e um cenário mensurável: é assim que um sistema multiagente vira alavanca de velocidade, não teatro de autonomia caro.

Perguntas frequentes

Em que um sistema multiagente difere de um agente com prompt longo?

Um agente de prompt longo tenta ser “tudo ao mesmo tempo” em um contexto e um conjunto de permissões. O design multiagente separa papéis: o orquestrador coordena, os subagentes executam de forma estreita. Fica mais fácil de controlar, mais barato em tokens em cadeias longas e mais seguro porque cada executor tem superfície de acesso menor.

Sempre é preciso um orquestrador LLM?

Não. Muitas vezes um grafo determinístico (máquina de estados / workflow) é melhor, com o LLM vivendo dentro dos nós. Um orquestrador LLM compensa quando a entrada é não estruturada e a rota não pode ser hardcoded de antemão. Híbrido é a escolha mais comum em produção.

Quantos subagentes são ideais no início?

Em geral 2-4. Um orquestrador mais research e writer já é um loop funcional para conteúdo e suporte; coder e reviewer - para desenvolvimento. Mais papéis só fazem sentido depois que o piloto bate KPI de forma consistente e os logs são legíveis.

Como evitar queimar dinheiro em tokens?

Comprima briefs, proíba “recontar o diálogo inteiro”, cacheie o system prompt estável, limite max steps, paralelize só onde isso reduz wall-time - não para show. Meça o custo do cenário ponta a ponta, não de uma resposta bonita de demo.

Ainda precisa de humano no loop se os agentes são “inteligentes”?

Sim, nos riscos. Um modelo não remove a responsabilidade por dinheiro, dados pessoais, redação jurídica e produção. Human-in-the-loop não é fraqueza de arquitetura - é a condição sob a qual o negócio permite agentes perto de sistemas reais.