# Playbook: Multi-agente — quando 1 basta e quando você precisa orquestrar

Cada agente adicional dobra custo, latência e superfície de erro. Este playbook oferece critério cirúrgico para decidir entre agente único, supervisor, pipeline e debate — com tabelas de decisão, topologias visuais e as armadilhas que destroem sistemas multi-agente em produção.

- URL: https://fernando.moretes.com/studies/playbook-multi-agente-quando-1-basta-e-quando-orquestrar

- Markdown: https://fernando.moretes.com/studies/playbook-multi-agente-quando-1-basta-e-quando-orquestrar/study.md?lang=pt

- Type: Playbook

- Domain: IA / Agentes

- Date: 2025-12-10

- Tags: multi-agent, bedrock, genai, orchestration, llm, aws, agents, architecture

- Reading time: 9 min

---

A pressão para adicionar agentes é quase sempre arquitetural por ansiedade, não por necessidade. Um agente bem configurado com as ferramentas certas resolve 80% dos casos — e resolve mais rápido, mais barato e com menos pontos de falha. Este playbook mata o hype com critério: você vai sair sabendo exatamente quando parar em 1 e quando a orquestração multi-agente é a resposta certa.

## O que você vai conseguir decidir depois de ler isto

- Diagnosticar se seu caso realmente exige múltiplos agentes ou se é complexidade acidental
- Escolher entre as quatro topologias (único, supervisor, pipeline, debate) com critério técnico
- Entender o custo real de cada agente adicional em tokens, latência e superfície de erro
- Identificar a armadilha do 'auto-verifier' — por que agentes se avaliando entre si não é verificação
- Implementar a topologia certa no Amazon Bedrock com guardrails e isolamento adequados

## Contexto de referência deste playbook

- **Domínio:** IA Generativa / Sistemas de Agentes LLM
- **Plataforma principal:** Amazon Bedrock Agents + AWS Step Functions
- **Modelos cobertos:** Claude 3.x (Anthropic via Bedrock), modelos Titan, qualquer modelo com suporte a tool use
- **Custo base de referência (estimativa):** Cada hop entre agentes adiciona ~1-3s de latência e duplica o consumo de tokens de contexto
- **Fontes primárias:** AWS Bedrock Docs, Anthropic Engineering Blog, AWS Step Functions
- **Audiência:** Engenheiros e arquitetos construindo sistemas agênticos em produção

## O modelo mental que desbloqueia tudo: agente é um loop, não um serviço

Um agente LLM é fundamentalmente um loop de raciocínio: percebe o estado atual, decide uma ação (chamar uma ferramenta, responder, ou continuar pensando), executa, observa o resultado, e itera. Isso é o ReAct pattern em sua forma mais pura. O problema começa quando arquitetos tratam agentes como microsserviços — cada um com uma responsabilidade, cada um conversando com o próximo via mensagens. A analogia é sedutora, mas falsa.

Microsserviços têm interfaces determinísticas. Agentes têm interfaces probabilísticas. Quando você conecta dois microsserviços, você sabe exatamente o que vai trafegar entre eles. Quando você conecta dois agentes, você está passando linguagem natural — e cada hop é uma oportunidade para alucinação, perda de contexto, ou deriva de objetivo. A propagação de erro em sistemas multi-agente não é linear: é multiplicativa.

A Anthropic articula isso com precisão no seu guia de agentes efetivos: prefira sistemas simples. Aumente a complexidade apenas quando a simplicidade demonstravelmente falha. Isso não é conservadorismo — é engenharia. Um agente único com 5 ferramentas bem definidas (busca vetorial, execução de código, chamada de API, leitura de documentos, escrita estruturada) cobre a maioria dos workflows de conhecimento que vejo em produção. O contexto do Claude 3.5 Sonnet já suporta 200k tokens — cabe muita coisa num único prompt bem estruturado.

Então qual é o critério real para escalar para múltiplos agentes? **Papéis genuinamente distintos que não podem coexistir no mesmo contexto.** Não 'tarefas diferentes' — papéis com objetivos, permissões e estilos de raciocínio fundamentalmente incompatíveis. Um planejador estratégico e um executor de código têm incentivos diferentes. Um crítico e um gerador têm papéis adversariais por design. Isso é real. 'Preciso de um agente para pesquisa e outro para escrita' geralmente não é — é um agente com duas ferramentas.

## O custo real de cada agente que você adiciona

Antes de qualquer tabela de decisão, você precisa internalizar a matemática do custo marginal. Cada agente adicional na sua topologia não adiciona custo linearmente — ele multiplica em três dimensões:

**1. Tokens:** Cada handoff entre agentes requer que o agente receptor receba contexto suficiente para entender o que está sendo pedido. Na prática, isso significa que o output do agente A vira parte do input do agente B, que vira parte do input do agente C. Em topologias de supervisor com 3 sub-agentes, você pode facilmente estar pagando 4-6x os tokens de uma solução de agente único equivalente. No Bedrock, isso se traduz diretamente em custo de inferência.

**2. Latência:** Cada hop de agente é uma chamada de inferência síncrona (ou assíncrona com polling). Com Claude 3.5 Sonnet, uma chamada típica de raciocínio leva 2-8 segundos dependendo da complexidade. Uma pipeline de 4 agentes em série tem latência mínima de ~8-32 segundos, sem contar o tempo de execução das ferramentas. Para aplicações interativas, isso é inaceitável. Para batch processing, pode ser tolerável.

**3. Superfície de erro:** Cada agente é um ponto de falha independente. Ele pode alucinar, interpretar mal a instrução do agente anterior, chamar a ferramenta errada, ou entrar em loop. Em sistemas multi-agente, o debugging é exponencialmente mais difícil porque você precisa reconstruir o estado de cada agente no momento da falha. O trace do Bedrock Agents ajuda, mas não elimina o problema.

A regra prática que uso: antes de adicionar um agente, pergunte 'posso resolver isso com uma ferramenta adicional no agente existente?' Se a resposta for sim, não adicione o agente. Ferramentas são determinísticas, baratas e fáceis de testar. Agentes são probabilísticos, caros e difíceis de debugar.

## Topologias de agente: prós, contras e veredito

### Agente Único

**Pros**
- Latência mínima — um único loop de raciocínio
- Custo previsível e controlável
- Debugging simples: um trace, um contexto
- Sem perda de contexto entre hops
- Ferramentas cobrem especialização sem overhead de agente

**Cons**
- Contexto limitado para tarefas muito longas (mesmo com 200k tokens)
- Não paraleliza trabalho independente nativamente
- Papéis conflitantes no mesmo prompt podem degradar qualidade

**Verdict:** Padrão para 80% dos casos. Comece aqui sempre.

### Supervisor + Sub-agentes

**Pros**
- Delegação clara de responsabilidade por domínio
- Sub-agentes podem ter permissões e ferramentas isoladas
- Suportado nativamente no Amazon Bedrock multi-agent collaboration
- Supervisor mantém contexto estratégico enquanto sub-agentes executam

**Cons**
- 2-3x custo de tokens vs agente único equivalente
- Latência acumulada: cada sub-agente adiciona 1 round-trip de inferência
- Supervisor pode tomar decisões de delegação subótimas
- Debugging requer correlacionar traces de múltiplos agentes

**Verdict:** Use quando domínios têm permissões realmente distintas ou quando sub-tarefas são longas o suficiente para justificar contextos separados.

### Pipeline (Sequencial)

**Pros**
- Cada estágio transforma o output do anterior de forma determinística
- Fácil de testar estágio por estágio
- Integrável com Step Functions para orquestração durável e retry
- Separação clara de concerns: extração → análise → formatação

**Cons**
- Latência é a soma de todos os estágios — sem paralelismo
- Erro em estágio intermediário invalida todo o trabalho anterior
- Contexto do problema original pode se perder ao longo da cadeia

**Verdict:** Ideal para transformações de dados bem definidas (ETL com LLM, geração de documentos estruturados). Não use para raciocínio aberto.

### Debate (Multi-agente Adversarial)

**Pros**
- Crítico genuinamente adversarial melhora qualidade de outputs de alto risco
- Detecta vieses e pontos cegos que um único agente não vê
- Útil para geração de código com verificação independente

**Cons**
- 3-5x custo de tokens — o mais caro de todos
- Agentes do mesmo modelo base têm vieses correlacionados — debate não é verificação real
- Pode convergir para consenso falso em vez de verdade
- Latência proibitiva para casos interativos

**Verdict:** Use com critério cirúrgico: apenas quando o custo de um output errado supera muito o custo do debate. Verificação real exige código, não outro LLM.

## Custo, latência e risco por topologia
| Critério | Topologia | Custo de tokens (relativo) | Latência típica | Superfície de erro | Quando usar |
| --- | --- | --- | --- | --- | --- |
| Agente Único | 1x (baseline) | 2–8s por chamada | Baixa — 1 ponto de falha | Tarefa cabe numa linha de raciocínio; ferramentas cobrem especialização | Nunca por padrão — avalie primeiro |
| Supervisor | 2–4x | 5–20s (+ sub-agentes) | Média — N+1 pontos de falha | Domínios com permissões distintas; sub-tarefas longas e independentes | Quando ferramentas resolvem o problema; latência é crítica |
| Pipeline | 1.5–3x | Soma dos estágios (10–60s) | Média — erro em cascata possível | Transformações sequenciais bem definidas; ETL com LLM; batch | Raciocínio aberto; casos interativos; quando estágios são interdependentes |
| Debate | 3–6x | 15–60s+ por rodada | Alta — viés correlacionado entre agentes | Outputs de altíssimo risco; geração + verificação de código crítico | Verificação factual (use código/ferramentas); casos de custo sensível; tempo real |

## Checklist: como decidir sua topologia em 6 passos

1. **Passo 1: Escreva o objetivo numa frase** — Se você não consegue descrever o que o sistema precisa fazer em uma frase clara, você não entende o problema ainda. Não arquitete. Exemplos bons: 'Dado um ticket de suporte, classificar, buscar documentação relevante e redigir resposta.' Exemplos ruins: 'Um sistema inteligente que processa informações de forma autônoma.'

2. **Passo 2: Liste as ações necessárias — são ferramentas ou agentes?** — Para cada ação, pergunte: é determinística e tem interface bem definida? → Ferramenta (Lambda, API, query SQL). Requer raciocínio autônomo com estado próprio e objetivo próprio? → Candidato a agente. Na maioria dos casos, 90% das 'ações' são ferramentas. Se tudo são ferramentas, você tem um agente único.

3. **Passo 3: Verifique se há paralelismo real** — Há sub-tarefas que podem executar simultaneamente e cujos resultados são independentes? Se sim, pipeline paralelo ou supervisor com sub-agentes paralelos pode justificar o overhead. Se as tarefas são sequenciais ou interdependentes, o paralelismo é ilusório e o overhead não se justifica.

4. **Passo 4: Verifique se há isolamento de segurança obrigatório** — Diferentes partes do sistema precisam de IAM roles distintas, acesso a dados segregado, ou compliance que exige separação de contexto? Isso é um dos poucos motivos técnicos sólidos para múltiplos agentes. No Bedrock, cada agente tem sua própria execution role — use isso para isolamento real, não cosmético.

5. **Passo 5: Estime o custo da topologia candidata** — Calcule: tokens médios por chamada × multiplicador da topologia × volume de chamadas/dia × preço por token do modelo escolhido. Se o custo multi-agente for >2x o agente único para o mesmo resultado, você precisa de justificativa técnica explícita — não 'fica mais organizado'.

6. **Passo 6: Defina seu verifier — e garanta que não é outro LLM** — Todo sistema agêntico em produção precisa de verificação. Mas verificação real é determinística: testes unitários no código gerado, validação de schema no JSON produzido, execução em sandbox, checagem de regras de negócio em código. Um segundo LLM 'revisando' o output do primeiro tem viés correlacionado — não é verificação, é teatro de qualidade.

## Como o Amazon Bedrock implementa colaboração multi-agente — e onde os limites importam

O Amazon Bedrock suporta colaboração multi-agente nativamente desde 2024, com um modelo de supervisor que pode invocar sub-agentes como se fossem ferramentas. A arquitetura é elegante: o agente supervisor recebe a tarefa, decide qual sub-agente invocar, passa o contexto relevante, recebe o resultado, e continua seu raciocínio. Cada sub-agente tem sua própria execution role IAM, seus próprios knowledge bases, e suas próprias action groups.

Isto resolve o problema de isolamento de permissões de forma limpa. Um sub-agente que acessa dados financeiros sensíveis pode ter uma role restrita, enquanto o supervisor opera com permissões mais amplas de orquestração. Isso é um caso de uso legítimo para multi-agente — não é sobre 'organização', é sobre boundary de segurança.

O que o Bedrock não resolve automaticamente é o problema de contexto. Quando o supervisor invoca um sub-agente, ele precisa passar contexto suficiente para que o sub-agente entenda o que está sendo pedido. Isso significa que o contexto relevante é serializado, enviado, processado, e o resultado é retornado. Para tarefas longas, isso pode resultar em contextos de entrada muito grandes nos sub-agentes, aumentando custo e latência.

Para orquestração mais complexa — especialmente quando você precisa de retry, compensação, ou fluxos de longa duração — o AWS Step Functions é o complemento natural. Você pode orquestrar chamadas ao Bedrock Agents via Step Functions, com controle total sobre timeout, retry com backoff exponencial, e estado durável entre etapas. Isso é especialmente valioso em pipelines de processamento de documentos onde uma etapa pode falhar e você precisa retomar de onde parou, não reiniciar do zero.

Uma nota importante sobre limites do Bedrock multi-agent: a profundidade de aninhamento de agentes tem limites (verifique a documentação atual para limites específicos de sua região). Topologias muito profundas — supervisor invocando sub-agente que invoca outro sub-agente — rapidamente se tornam indebuggáveis e violam o princípio de simplicidade. Se você está pensando em 3+ níveis de aninhamento, pare e redesenhe.

## Topologias multi-agente: mapa de decisão visual

As quatro topologias possíveis, seus fluxos de dados e pontos de decisão. A topologia correta emerge do problema, não da preferência arquitetural.

### 👤 Entrada / Input

- Usuário User (user)

### 🟢 Topologia A: Agente Único / Single Agent

- Agente Único Single Agent (ReAct loop) (ai)
- Ferramentas Tools (Lambda / API / KB) (compute)

### 🔵 Topologia B: Supervisor / Supervisor

- Supervisor Agent (Bedrock) (ai)
- Sub-agente A Sub-agent A (domínio/role A) (ai)
- Sub-agente B Sub-agent B (domínio/role B) (ai)
- IAM Role A (permissões isoladas) (security)
- IAM Role B (permissões isoladas) (security)

### 🟡 Topologia C: Pipeline Sequencial / Sequential Pipeline

- Step Functions (orquestração durável) (messaging)
- Estágio 1 Extração / Extract (ai)
- Estágio 2 Análise / Analyze (ai)
- Estágio 3 Formatar / Format (ai)
- Verifier (código / schema não LLM) (compute)

### 🔴 Topologia D: Debate / Adversarial

- Gerador Generator (propõe solução) (ai)
- Crítico Critic (adversarial) (ai)
- Árbitro Judge (ou código) (ai)
- Verificação Code-based (obrigatório) (compute)

### 💾 Saída / Output

- Resposta Final Final Response (data)

### Fluxos

- user -> single_agent: tarefa
- single_agent -> tools_single: tool call
- tools_single -> single_agent: resultado
- single_agent -> output
- user -> supervisor: tarefa complexa
- supervisor -> sub_a: delega
- supervisor -> sub_b: delega
- sub_a -> iam_a
- sub_b -> iam_b
- sub_a -> supervisor: resultado
- sub_b -> supervisor: resultado
- supervisor -> output
- user -> sfn: inicia pipeline
- sfn -> stage1
- stage1 -> stage2
- stage2 -> stage3
- stage3 -> verifier: valida (código)
- verifier -> output
- user -> generator: alto risco
- generator -> critic: proposta
- critic -> judge: crítica
- judge -> code_verify: verificação real
- code_verify -> output

> **Anti-padrões que destroem sistemas multi-agente em produção:** **1. Multi-agente prematuro por flexibilidade ('vamos separar pra ficar mais organizado'):** Organização arquitetural não é justificativa para múltiplos agentes. Você não separa microsserviços por estética — separa por boundary de domínio, escala independente, ou isolamento de falha. O mesmo critério se aplica a agentes. Se o único argumento é 'fica mais limpo', você está pagando 2-4x mais por um problema que um bom system prompt resolve.

**2. Auto-avaliação como verifier ('o agente B vai revisar o output do agente A'):** Este é o anti-padrão mais perigoso e mais comum. Dois agentes baseados no mesmo modelo base têm vieses correlacionados — eles tendem a cometer os mesmos tipos de erro e a aprovar os mesmos tipos de resposta incorreta. Isso não é verificação: é viés conversando com viés. Verificação real é determinística: execute o código gerado, valide o JSON contra um schema, cheque regras de negócio em código Python. Se você não pode verificar deterministicamente, seja honesto sobre o nível de confiança do output.

**3. Loops sem condição de saída clara:** Agentes em loop sem critério de parada explícito e testável vão iterar até o timeout ou até consumir seu budget de tokens. Defina sempre: número máximo de iterações, critério de sucesso verificável, e o que acontece quando nenhum dos dois é atingido.

**4. Ignorar o trace do Bedrock em desenvolvimento:** O trace de raciocínio do Bedrock Agents é sua única janela para o que está acontecendo dentro do loop. Desenvolver sem inspecionar o trace é como debugar código sem logs. Ative sempre em desenvolvimento e tenha um plano para sampling em produção.

> **Regra de bolso: complexidade não é sofisticação:** **Se você não consegue explicar por que precisa de N agentes em vez de N-1 ferramentas, você não precisa de N agentes.**

Mais especificamente: adicione um agente apenas quando uma dessas três condições for verdadeira:
1. **Isolamento de segurança real** — o sub-agente precisa de permissões que o agente principal não pode ter.
2. **Paralelismo genuíno** — as sub-tarefas são independentes e o ganho de tempo justifica o overhead de custo.
3. **Papéis adversariais por design** — gerador e crítico precisam de objetivos explicitamente conflitantes.

Tudo o mais é ferramenta.

> **Minha perspectiva: o que eu faço na prática:** Quando começo um projeto agêntico, minha posição padrão é agente único com o máximo de ferramentas que o caso de uso exige. Só movo para multi-agente quando bato em um dos três critérios acima de forma demonstrável — não teórica.

O padrão que mais vejo em projetos que chegam até mim com problemas é o que chamo de 'arquitetura de orgulho': alguém construiu um sistema com 5 agentes porque parece mais impressionante em um diagrama. O sistema tem 3x o custo, 4x a latência, e ninguém consegue debugar quando algo dá errado. Refatorar para agente único com ferramentas geralmente resolve o problema em uma tarde.

Para verificação, nunca confio em LLM-as-judge para nada que importe. Se estou gerando código, executo em Lambda sandbox e verifico o resultado. Se estou gerando JSON estruturado, valido contra um schema Pydantic antes de qualquer downstream. Se estou gerando análise financeira, tenho regras de sanidade em código que checam ranges esperados. Isso não é desconfiança do modelo — é engenharia básica de sistemas.

O Amazon Bedrock multi-agent collaboration é uma feature bem implementada para os casos onde multi-agente é realmente necessário. O isolamento por IAM role é genuinamente útil para compliance. Mas a feature existir não significa que você deve usá-la. A maioria dos sistemas que construo em Bedrock usa agente único com knowledge bases e action groups — e funciona muito bem.

## Veredito

Multi-agente é uma solução de engenharia para problemas específicos de engenharia — não uma filosofia de design. Cada agente que você adiciona é uma aposta: você está apostando que o ganho em isolamento, paralelismo, ou especialização adversarial supera o custo em tokens, latência, e complexidade operacional. Na maioria dos casos, essa aposta perde.

O critério não é 'o sistema é complexo?' — é 'a complexidade do sistema exige papéis que não podem coexistir num único contexto?' Se a resposta for não, você tem um agente com ferramentas. Se a resposta for sim, você tem um caso legítimo para multi-agente — e agora você sabe qual topologia escolher e por quê.

A sofisticação real em sistemas agênticos não está no número de agentes. Está na clareza do objetivo, na qualidade das ferramentas, na robustez da verificação, e na honestidade sobre o que o sistema pode e não pode fazer com confiança.

## Referências

- [AWS — Multi-agent collaboration on Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [AWS Step Functions](https://aws.amazon.com/step-functions/)

## Fontes do caso

- [AWS — Multi-agent collaboration on Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [AWS Step Functions](https://aws.amazon.com/step-functions/)