Agentes de IA por Dentro (2/3): Catálogo de Padrões, de ReAct a Multi-Agente

Se você leu a Parte 1, você sabe que um agente é essencialmente um loop: o LLM recebe uma observação, raciocina, decide uma ação, executa, observa o resultado e repete. O que diferencia os padrões arquiteturais não é esse loop em si, é como o raciocínio é estruturado dentro dele e quantos agentes participam.

Pense como um desenvolvedor de software. Você já escreveu um while com condição de parada. Um agente é exatamente isso, mas a condição de parada é decidida pelo LLM ('a tarefa está completa?'), e o corpo do loop pode chamar ferramentas externas. O problema de engenharia é: como você estrutura o raciocínio dentro do loop para que ele seja confiável, auditável e não entre em loop infinito?

O ReAct (Reasoning + Acting, Yao et al., 2022) foi o primeiro padrão a formalizar isso: o modelo alterna explicitamente entre um passo de Thought (raciocínio em linguagem natural), um passo de Action (chamada de ferramenta) e um passo de Observation (resultado da ferramenta). Essa alternância explícita é poderosa porque torna o raciocínio auditável, você pode ler o log e entender por que o agente tomou cada decisão. É o equivalente a escrever código com comentários inline em vez de um bloco monolítico.

Reflexion (Shinn et al., 2023) adiciona um segundo loop interno de autocrítica: após cada tentativa, o agente gera uma reflexão sobre o que deu errado e armazena essa reflexão na memória de sessão antes de tentar novamente. É como um desenvolvedor que escreve um teste, vê falhar, anota o diagnóstico e então corrige, em vez de simplesmente tentar de novo no escuro. O custo é claro: mais tokens por tentativa. Use quando a tarefa tem critério de correção verificável (ex: código que deve compilar, SQL que deve retornar resultado não-vazio).

Plan-and-Execute separa o raciocínio em duas fases distintas: um Planner LLM gera um plano de passos (pense num Makefile), e um Executor LLM executa cada passo independentemente. A vantagem é que o plano pode ser inspecionado e aprovado por um humano antes da execução, excelente para fluxos de alto risco. A desvantagem é rigidez: se o ambiente muda durante a execução, o plano pode ficar obsoleto.

Agentic RAG é o upgrade do RAG estático que todo arquiteto deveria conhecer. No RAG tradicional, você sempre busca documentos antes de gerar. No Agentic RAG, o agente decide quando buscar, formula a query de busca como parte do raciocínio, e pode fazer múltiplas buscas iterativas ('não encontrei, vou reformular a query'). Isso reduz ruído no contexto, você não injeta documentos irrelevantes, mas exige que o agente saiba quando ele não sabe algo, o que é um problema de calibração do modelo.

Memória em agentes é análoga a storage em microsserviços: você tem RAM (rápida, cara, volátil), disco local (mais barato, persistente por sessão) e banco de dados distribuído (lento, barato, compartilhado). Cada camada tem um trade-off diferente.

A janela de contexto é a RAM do agente: tudo que está no prompt ativo. É a memória mais rápida, mas tem custo linear em tokens, cada token a mais que você injeta no contexto aumenta o custo de inferência e a latência. O erro clássico é jogar tudo na janela de contexto ('vou colocar todo o histórico da conversa') e descobrir que a conta de API triplicou.

A memória de sessão (curto prazo) é o equivalente a um cache Redis por sessão: você persiste o histórico da conversa atual fora do prompt e injeta apenas o resumo ou os últimos N turnos. Isso resolve o problema de custo, mas exige uma estratégia de sumarização, e sumarização feita pelo LLM tem custo também.

A memória de longo prazo: vetorial, episódica, semântica, é o banco de dados distribuído. Você armazena fatos, preferências do usuário, episódios passados em um vector store (ex: OpenSearch, pgvector) e recupera por similaridade semântica quando relevante. O risco aqui é duplo: memória sem TTL cresce indefinidamente (custo de storage e latência de busca), e memória desatualizada gera alucinações, o agente 'lembra' de um fato que mudou.

A pergunta mais importante sobre multi-agente não é 'qual topologia usar', é 'eu realmente preciso de multi-agente?' A resposta honesta é: na maioria dos casos, não. Um agente único bem projetado com as ferramentas certas resolve 80% dos problemas que as pessoas tentam resolver com arquiteturas multi-agente complexas.

Multi-agente faz sentido em três cenários reais: (1) paralelismo genuíno: sub-tarefas independentes que podem rodar simultaneamente (ex: analisar 10 documentos em paralelo); (2) especialização de domínio: um sub-agente com prompt system e ferramentas otimizados para um domínio específico (ex: agente de compliance vs. agente de análise financeira); (3) isolamento de contexto: você não quer que o contexto de uma sub-tarefa contamine o raciocínio de outra.

As quatro topologias principais são: Supervisor/Orquestrador (um agente central delega para sub-agentes e consolida resultados, como um tech lead distribuindo tarefas); Hierárquico (supervisor de supervisores, para problemas muito grandes); Swarm/Peers (agentes sem hierarquia que se comunicam por mensagens, mais resiliente, mais difícil de debugar); e Roteamento por Especialista (um router LLM classifica a tarefa e envia para o agente especializado correto, análogo a um API Gateway com roteamento semântico).

O critério de decisão que uso em produção: se você não consegue explicar em uma frase por que cada agente existe separado, você provavelmente não precisa de multi-agente.

O erro mais comum que vejo em times que estão chegando em agentes de IA é tratar segurança como uma camada que se adiciona depois. Não funciona assim. Guardrails precisam ser projetados como parte do fluxo desde o início, porque eles afetam latência, custo e o design das ferramentas.

Prompt injection é o SQL injection dos agentes: dados externos (um e-mail, um documento, uma resposta de API) podem conter instruções que sequestram o comportamento do agente. A defesa é em camadas: (1) separar claramente dados de instruções no prompt (use delimitadores explícitos); (2) validar no guardrail de entrada se o conteúdo de dados contém padrões de instrução; (3) aplicar o princípio do menor privilégio nas ferramentas, um agente que só precisa ler documentos não deve ter ferramenta de escrita em banco de dados.

Tool sprawl é o anti-pattern de dar ao agente 30 ferramentas 'porque pode precisar'. O LLM precisa escolher a ferramenta certa entre todas as disponíveis, quanto mais ferramentas, maior a probabilidade de escolha errada e maior o tamanho do prompt de sistema. Regra prática: se um agente tem mais de 15 ferramentas, considere dividir em sub-agentes especializados.

Human-in-the-loop não é um sinal de fraqueza da arquitetura, é um requisito de negócio em qualquer sistema que executa ações irreversíveis (transferências financeiras, envio de e-mails em massa, deleção de dados). O padrão correto é modelar checkpoints explícitos no fluxo Plan-and-Execute: o plano é gerado, um humano aprova, a execução começa. Isso também é o que o Amazon Bedrock Agents suporta nativamente com 'human approval steps'.