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

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.

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.

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.