Multi-agent orchestration patterns: 6 padrões com tradeoffs

Multi-agent virou tema vendido demais. Em 80% dos casos que vemos, um agente bem desenhado venceria três agentes em “crew”. Mas há casos genuínos onde multi-agente paga. Seis padrões, com tradeoffs.

Padrão 1 · Sequential pipeline

Agente A → output → Agente B → output → Agente C.

Quando vale: tarefas com fases distintas e troca de modelo apropriada por fase. Pesquisador (Sonnet) → escritor (Opus) → revisor (Haiku para checagem rápida).

Tradeoff:

• ✅ Cada fase otimizada por modelo certo.
• ✅ Auditability alta (cada output é checkpoint).
• ❌ Latência soma. 3 agentes sequenciais = 3× latência de 1 agente.
• ❌ Erro propaga. Falha em A vira garbage em B e C.

Mitigação: validation entre stages, com retry.

Padrão 2 · Specialist routing (router + experts)

Agente router classifica request → roteia para expert apropriado (jurídico, financeiro, suporte). Cada expert é especializado.

Quando vale: domínio onde especialização real existe e o router classifica com alta confiança.

Tradeoff:

• ✅ Cada expert pode ter system prompt curto e focado.
• ✅ Cost-efficient (expert simples pode usar Haiku).
• ❌ Router errado destrói o sistema.
• ❌ Cross-domain (request que toca jurídico + financeiro) vira problema.

Mitigação: router com confidence threshold; quando baixo, escala para multi-expert ou humano.

Padrão 3 · Debate / dialectical

Dois agentes argumentam posições opostas; um terceiro decide.

Quando vale: decisão com tradeoffs sensíveis (aprovar/rejeitar pedido complexo, escolher entre alternativas).

Tradeoff:

• ✅ Captura nuances que um agente único pula.
• ❌ Caríssimo. 3× o custo, e latência mais alta.
• ❌ Risco de “debate teatral” — agentes geram argumentos sem real adversarialidade.

Padrão usado em: Anthropic’s Constitutional AI training; raramente em produção comercial direta.

Padrão 4 · Hierarchical (manager + workers)

Manager agent quebra task em subtasks, distribui para workers, agrega.

Quando vale: tasks que decompõem bem (research em N tópicos paralelos, código em N módulos).

Tradeoff:

• ✅ Paralelismo real.
• ❌ Coordenação custa. Manager precisa de janela grande de contexto.
• ❌ Quando subtasks são interdependentes, manager vira gargalo.

Padrão 5 · Adversarial / red team

Um agente gera, outro tenta quebrar. Iterativo até estabilizar.

Quando vale: produzir output robusto (código com edge cases cobertos, texto sem ambiguidade legal).

Tradeoff:

• ✅ Output final muito melhor que single-agent.
• ❌ Iterações infinitas se design ruim. Time-box obrigatório.

Padrão 6 · Single agent with advisor escalation

Um agente principal. Adviser (outro modelo) consultado quando confidence baixa ou stakes altos.

Quando vale: a maioria dos casos.

Tradeoff:

• ✅ Simplicidade. Advisor max_uses=1 por interação controla custo.
• ✅ Cobre 80% do valor de multi-agent com fração do overhead.
• ❌ Não cobre tasks que precisam de paralelismo real.

Esse é nosso padrão padrão (literal).

O anti-pattern: “crew” para tudo

Frameworks como CrewAI populariza “delegate tasks to a crew of specialized agents”. Em produção real, vemos:

• 5 agentes consumindo 5× os tokens para entregar o que 1 entregaria.
• Bug em um agente cascateia para os outros (vetor 5 da Prompt Infection Taxonomy).
• Debugging vira pesadelo (qual agente errou?).

Heurística: comece com 1 agente. Adicione segundo só quando demonstrar gargalo específico que decomposição resolve.

Cost matrix (estimativa relativa)

Padrão	Tokens	Latência	Complexidade
Single agent	1×	1×	Baixa
Single + advisor (raro)	1.5×	1.5×	Média
Sequential pipeline	3×	3×	Média
Specialist routing	1.5-2×	1.5×	Alta
Debate (3 agents)	3×	2×	Alta
Hierarchical	2-5×	2-3×	Muito alta
Adversarial loop	2-10×	2-5×	Muito alta

Onde aprofundar

Para o framework de delegação ([qual tarefa delegar a qual agente]): Agent Trust Stack. Para safety em multi-agent (cross-agent propagation): Prompt Infection Taxonomy.