Arquiteturas de Agentes de IA na Prática: Escolha o Pattern Certo para o Problema Certo

Existe um padrão que se repete em quase todo time que começa a construir sistemas com agentes de IA. A primeira semana é animadora: o agente responde, usa ferramentas, parece inteligente. Na terceira semana, o sistema virou um grafo de dependências impossível de debugar, com quatro agentes se chamando recursivamente, memória compartilhada entre contextos incompatíveis, e ninguém mais sabe exatamente o que está acontecendo quando uma requisição falha.

O problema raramente é o modelo. É a arquitetura.

A tese que quero defender aqui é simples: a complexidade da arquitetura de um agente deve ser proporcional à complexidade irredutível do problema. Não ao tamanho da empresa, não à maturidade do time, não ao quanto a tecnologia impressiona em demos. Ao problema.

E a forma mais direta de chegar nessa proporcionalidade é entender os oito patterns fundamentais de arquitetura de agentes, seus trade-offs reais, e o critério de decisão para escolher cada um.

O que Define uma Arquitetura de Agente

Antes de entrar nos patterns, preciso estabelecer o vocabulário. Um agente de IA, no contexto desse artigo, é um sistema que combina três elementos:

Chat Model: o LLM que raciocina, decide e gera. É o componente que consome mais custo e introduz mais não-determinismo no sistema.

Memory: o mecanismo que persiste contexto entre interações. Pode ser em memória (volátil, dentro de uma sessão), em banco vetorial (semântica, para RAG), ou em banco relacional (estruturada, para estado de longa duração).

Tools: as funções que o agente pode chamar para agir no mundo: APIs externas, bancos de dados, outros agentes, sistemas de arquivos.

A arquitetura define como esses três elementos se combinam, como os agentes se relacionam entre si, e onde o fluxo de controle reside: no LLM, no código, ou nos dois.

Essa última distinção é crítica e pouco discutida. Em sistemas onde o LLM controla o fluxo (fully agentic), o comportamento emergente é alto e a previsibilidade é baixa. Em sistemas onde o código controla o fluxo (orchestrated), o comportamento é determinístico mas a flexibilidade diminui. Todo pattern abaixo representa um ponto diferente nesse espectro.

Pattern 1: Single Agent + Tools

O pattern mais simples e, na maioria dos casos, o mais adequado. Um único agente com acesso a um conjunto de ferramentas, acionado por um gatilho (webhook, mensagem, evento).

Trigger → [Chat Model + Memory + Tools] → Response

Tools: Google Calendar, Gmail, Contacts, APIs externas
Memory: Simple Memory (em sessão) ou persistida em banco

Quando usar: Tarefas bem definidas com escopo limitado. Assistentes de produtividade, automações de comunicação, bots de atendimento com acesso a sistemas específicos. Qualquer coisa que um humano resolveria em uma sessão de trabalho sem precisar consultar outro especialista.

Trade-offs:

O ponto forte é a observabilidade. Com um único agente, o trace de uma requisição é linear: entrada, raciocínio, chamadas de ferramenta, saída. Quando algo falha, o diagnóstico é direto.

O limite é a capacidade de contexto. Quando o número de ferramentas cresce acima de 10-15, a qualidade do raciocínio do LLM sobre qual ferramenta usar começa a degradar. O modelo precisa manter em contexto a descrição de todas as ferramentas disponíveis, e o signal-to-noise ratio do prompt cai.

Sinal de que você está nesse limite: o agente começa a chamar ferramentas erradas com frequência, ou o tempo de resposta aumenta significativamente com o crescimento do catálogo de tools. Nesse ponto, considere Pattern 3 ou 4.

"

Referência: O paper "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022) formalizou o loop Thought→Action→Observation que fundamenta esse pattern. A maioria dos frameworks modernos (LangChain, LlamaIndex, n8n) implementa esse loop nativamente.

Pattern 2: Sequential Agents

Múltiplos agentes executando em sequência, onde a saída de um se torna a entrada do próximo. Cada agente tem seu próprio modelo, memória e conjunto de ferramentas.

Trigger → [Agent 0: extração] → [Agent 1: enriquecimento] → [Agent 2: ação] → Response

Cada agente: Chat Model + Memory própria + Tools específicas

Quando usar: Pipelines com estágios claramente distintos que requerem contextos ou especializações diferentes. Extração de dados de documentos seguida de enriquecimento via API seguida de geração de relatório. Triagem de leads seguida de qualificação seguida de roteamento para CRM.

Trade-offs:

A especialização por estágio é o ganho principal. Cada agente tem um prompt otimizado para sua função específica, um conjunto restrito de ferramentas, e uma memória isolada que não carrega ruído dos outros estágios. O resultado é qualidade melhor por estágio do que um único agente tentando fazer tudo.

O custo é a propagação de erros. Num pipeline sequencial, um erro no estágio 2 contamina todos os estágios seguintes. Se o agente de extração retorna dados malformados, o agente de enriquecimento vai raciocinar sobre dados errados, e o agente de ação vai tomar decisões baseadas em premissas falsas. Isso exige validação explícita entre estágios, o que a maioria das implementações ingênuas omite.

# Validação entre estágios — o que quase ninguém implementa
# mas é o que separa um pipeline robusto de um frágil

def run_sequential_pipeline(input_data):
    # Estágio 1: extração
    extracted = extraction_agent.run(input_data)

    # Validação explícita antes de passar adiante
    if not validate_extraction_schema(extracted):
        raise PipelineError(stage="extraction", data=extracted)

    # Estágio 2: enriquecimento
    enriched = enrichment_agent.run(extracted)

    if not validate_enrichment_completeness(enriched):
        # Retry com contexto do erro, não apenas reexecução cega
        enriched = enrichment_agent.run(extracted,
            hint="Previous attempt missing: " + get_missing_fields(enriched))

    # Estágio 3: ação
    return action_agent.run(enriched)

Sinal de que você precisa desse pattern: a tarefa tem estágios que requerem ferramentas incompatíveis, ou o prompt de um único agente cresceu a ponto de incluir instruções contraditórias para contextos diferentes.

Pattern 3: Single Agent + MCP Servers + Tools

Uma extensão do Pattern 1 onde, em vez de ferramentas individuais, o agente se conecta a servidores MCP (Model Context Protocol) que expõem capacidades organizadas por domínio.

Trigger → [Agent: Chat Model + Memory] → MCP Server (Atlassian) → Tools (Jira, Confluence)
                                        → MCP Server (Google) → Tools (Calendar, Gmail, Drive)
                                        → Tools diretas (Contacts)

Quando usar: Quando o agente precisa de acesso a múltiplos sistemas corporativos com autenticação e contexto próprios, e a quantidade de ferramentas individuais tornaria o catálogo ingerenciável. O MCP Server funciona como um proxy que agrupa ferramentas relacionadas, reduz a superfície de configuração do agente principal e permite que o servidor gerencie autenticação, retry e rate limiting de forma centralizada.

Trade-offs:

O ganho de manutenibilidade é real: adicionar uma nova ferramenta num domínio existente não requer modificar o agente principal. O time responsável pelo MCP Server de CRM pode evoluir suas capacidades independentemente do time que mantém o agente.

O custo é a indireção. Uma chamada de ferramenta agora passa por uma camada extra de rede, com latência adicional e um ponto de falha a mais. Em fluxos onde o agente precisa fazer múltiplas chamadas sequenciais para o mesmo servidor MCP, o overhead acumula.

"

Referência: O Model Context Protocol foi especificado pela Anthropic e publicado como padrão aberto em novembro de 2024. A especificação completa está disponível em modelcontextprotocol.io. Implementações de servidor existem para os principais sistemas corporativos (Atlassian, Salesforce, GitHub, Google Workspace).

Pattern 4: Single Agent + Tools + Router

Um único agente com lógica de roteamento explícita: baseado na entrada ou no resultado de uma ferramenta, o fluxo é direcionado para caminhos diferentes.

Trigger → [Agent: Chat Model + Memory + Tools] → Router (If/Switch) → Path A → Response A
                                                                     → Path B → Response B
                                                                     → Path C → Response C

Exemplo: classificação de intent → roteamento para handler especializado

Quando usar: Quando um único agente precisa lidar com tipos de requisições fundamentalmente diferentes que requerem fluxos distintos. Suporte técnico que distingue entre bug report, feature request e billing question, com cada um seguindo um pipeline diferente. Processamento de documentos que distingue entre contrato, nota fiscal e e-mail, com parsing específico para cada tipo.

Trade-offs:

O Router externaliza a lógica de controle do LLM para o código. Isso é um ganho de previsibilidade: as condições de roteamento são explícitas, testáveis e auditáveis. Quando o sistema faz a escolha errada de path, o diagnóstico é imediato.

O risco é a rigidez. Um Router baseado em regras explícitas assume que os tipos de entrada são discretos e conhecidos. Entradas ambíguas ou casos-limite que não se encaixam nas categorias pré-definidas podem cair no path errado silenciosamente, sem sinalização de erro.

# Router com fallback explícito — não deixe casos-limite sem tratamento

def route_request(agent_output: AgentOutput) -> str:
    intent = agent_output.classified_intent
    confidence = agent_output.confidence

    # Threshold de confiança explícito
    if confidence < 0.75:
        return "human_escalation"  # Não adivinhe em casos ambíguos

    routes = {
        "technical_bug": "bug_handler",
        "billing": "billing_handler",
        "feature_request": "pm_handler",
    }

    return routes.get(intent, "human_escalation")  # Fallback sempre definido

Pattern 5: Single Agent + Human in the Loop + Tools

Introduz um ponto de aprovação humana no fluxo do agente. O agente executa até um determinado ponto, pausa e aguarda validação ou instrução humana antes de continuar.

Trigger → [Agent: Chat Model + Memory + Tools] → Stack Approval (humano) → Continua
                                                                          → Rejeita → Retry com feedback
                                               → [Ação irreversível bloqueada até aprovação]

Quando usar: Qualquer fluxo onde o agente tem capacidade de executar ações irreversíveis de alto impacto. Envio de comunicações em massa, execução de queries destrutivas em banco de dados de produção, aprovação de transações financeiras, publicação de conteúdo em canais públicos. A regra prática: se a ação não pode ser desfeita com um rollback simples, ela precisa de aprovação humana.

Trade-offs:

O ganho é a contenção de risco. Um agente com acesso a HubSpot e Microsoft SQL, operando sem supervisão humana, pode causar danos significativos com um único mal-entendido de instrução. O Human in the Loop não é uma admissão de que o agente não é confiável: é uma decisão arquitetural consciente sobre onde o custo de um erro é inaceitável.

O custo é a latência de processamento e a dependência de disponibilidade humana. Um fluxo que requer aprovação humana não pode ser totalmente automatizado, e o SLA do sistema passa a depender do tempo de resposta do aprovador. Isso precisa estar explícito no design do produto.

A implementação mais comum e mais frágil é usar e-mail ou Slack como canal de aprovação sem timeout definido. A implementação robusta inclui: timeout com escalação automática, contexto completo para o aprovador tomar decisão informada, e mecanismo de feedback que alimenta o agente na retomada.

# Human-in-the-loop robusto com timeout e escalação

async def request_approval(action: ProposedAction, approver: str) -> ApprovalResult:
    approval_request = ApprovalRequest(
        action=action,
        context=action.full_context,      # Contexto completo, não resumo
        risk_assessment=action.risk_level, # Explícito para o aprovador
        timeout_seconds=3600,              # 1 hora
        escalation_contact="manager@company.com"
    )

    result = await approval_queue.submit(approval_request)

    if result.status == "timeout":
        # Nunca bloqueie indefinidamente
        return await escalate_to_manager(approval_request)

    if result.status == "rejected":
        # Feedback estruturado volta para o agente, não apenas "rejeitado"
        return ApprovalResult(
            approved=False,
            feedback=result.rejection_reason,
            suggested_alternative=result.suggestion
        )

    return result

Pattern 6: Single Agent + Dynamically Call Other Agents

Um agente orquestrador que, durante sua execução, decide dinamicamente chamar outros agentes especializados como se fossem ferramentas.

Trigger → [Orchestrator Agent] → chama [Agent Especialista A] quando necessário
                               → chama [Agent Especialista B] quando necessário
                               → Tools diretas para operações simples
                               → Response final sintetizada

Quando usar: Tarefas complexas onde o escopo das sub-tarefas não é conhecido de antemão. Um agente de pesquisa que decide, baseado nos resultados iniciais, se precisa acionar um agente de análise de dados, um agente de síntese de documentos, ou ambos. A diferença fundamental em relação ao Pattern 2 é que aqui a sequência e a composição dos agentes são decididas em runtime, não em design time.

Trade-offs:

A flexibilidade é o ganho principal. O orquestrador pode compor capacidades de formas que não foram antecipadas no design, respondendo a entradas que exigem combinações incomuns de especialistas.

O risco é a imprevisibilidade e os loops. Quando agentes podem chamar outros agentes dinamicamente, o grafo de chamadas pode crescer de forma não controlada. Um orquestrador que chama um especialista que chama de volta o orquestrador (mesmo que indiretamente) cria loops que são difíceis de detectar e travar.

# Proteção contra loops em dynamic agent calling

class OrchestratorAgent:
    MAX_DEPTH = 3        # Profundidade máxima de chamadas aninhadas
    MAX_AGENT_CALLS = 10 # Total de chamadas de agente por requisição

    def __init__(self):
        self.call_stack = []
        self.total_agent_calls = 0

    def call_agent(self, agent_name: str, input: str, depth: int = 0):
        # Detecta loops pelo call stack
        if agent_name in self.call_stack:
            raise AgentLoopDetected(
                agent=agent_name,
                stack=self.call_stack
            )

        # Limites explícitos de profundidade e total de chamadas
        if depth > self.MAX_DEPTH:
            raise MaxDepthExceeded(depth=depth)

        if self.total_agent_calls >= self.MAX_AGENT_CALLS:
            raise MaxAgentCallsExceeded()

        self.call_stack.append(agent_name)
        self.total_agent_calls += 1

        try:
            result = agents[agent_name].run(input, depth=depth+1)
        finally:
            self.call_stack.pop()

        return result

Pattern 7: Agents Hierarchy + Parallel Agents + Shared Tools

O pattern mais complexo: múltiplos agentes operando em paralelo, coordenados por uma hierarquia de orquestradores, compartilhando ferramentas e contexto via mecanismos explícitos de sincronização.

Webhook → Switch/Router
            → [Agent A (paralelo)] → Tools compartilhadas (Gmail, Drive, Twilio)
            → [Agent B (paralelo)] → Tools compartilhadas
            → [Agent C (paralelo)] → Vector Store → Embeddings
                         ↓
                    Merge/Aggregator
                         ↓
                    Response final

Quando usar: Tarefas que são genuinamente paralelizáveis e onde o tempo total é dominado pela execução sequencial de sub-tarefas independentes. Processamento de múltiplos documentos simultaneamente, consulta paralela a múltiplas fontes de dados com síntese posterior, execução de análises independentes sobre o mesmo dataset.

A palavra-chave é "genuinamente". Muitas tarefas parecem paralelizáveis mas têm dependências ocultas que só aparecem em produção.

Trade-offs:

O ganho de latência pode ser significativo quando as sub-tarefas são realmente independentes. Se cada agente paralelo leva 3 segundos, executar 4 em paralelo resulta em ~3 segundos totais, não 12.

Os custos são múltiplos e sérios:

Contention em ferramentas compartilhadas. Se dois agentes tentam escrever no mesmo recurso simultaneamente (mesmo arquivo no Drive, mesmo registro no CRM), você tem um problema de concorrência clássico. A maioria dos frameworks de agentes não resolve isso automaticamente.

Custo financeiro. Quatro agentes paralelos consomem quatro vezes mais tokens de LLM que um agente sequencial para o mesmo trabalho. O custo por requisição sobe linearmente com o grau de paralelismo.

Complexidade de debugging. Quando um trace envolve 4 agentes rodando em paralelo com tools compartilhadas, reconstruir o que aconteceu num incidente de produção requer instrumentação cuidadosa de distributed tracing. OpenTelemetry com spans por agente é o mínimo aceitável.

# Parallel agents com controle de concorrência em tools compartilhadas

import asyncio
from asyncio import Semaphore

# Rate limiting por ferramenta compartilhada
gmail_semaphore = Semaphore(3)   # Máximo 3 agentes usando Gmail simultaneamente
drive_semaphore = Semaphore(2)   # Máximo 2 agentes usando Drive simultaneamente

async def run_agent_with_shared_tools(agent, input_data, tool_semaphores):
    async with tool_semaphores.get(agent.primary_tool, Semaphore(10)):
        return await agent.arun(input_data)

async def run_parallel_agents(inputs: list[str]) -> list[AgentResult]:
    tasks = [
        run_agent_with_shared_tools(
            agent=create_agent(i),
            input_data=inputs[i],
            tool_semaphores={"gmail": gmail_semaphore, "drive": drive_semaphore}
        )
        for i in range(len(inputs))
    ]

    # gather com return_exceptions=True para não cancelar tudo se um agente falha
    results = await asyncio.gather(*tasks, return_exceptions=True)

    # Trate falhas individuais, não propague para o batch inteiro
    return [
        r if not isinstance(r, Exception)
        else AgentResult(error=str(r), input=inputs[i])
        for i, r in enumerate(results)
    ]

Pattern 8: Agents Hierarchy + Parallel Agents + Shared Tools + RAG

A extensão do Pattern 7 com um Vector Store para recuperação semântica de conhecimento. Os agentes consultam embeddings de documentos para fundamentar suas respostas em contexto relevante antes de agir.

Webhook → Switch
            → [Agent A] → Vector Store (embeddings) → contexto relevante
            → [Agent B] → Vector Store (embeddings) → contexto relevante
            → [Agent C] → Tools + Google Drive + Gmail
                ↓
           Executive Command (orquestrador de segundo nível)
                ↓
           Merge + Response

Quando usar: Sistemas que precisam raciocinar sobre grandes corpora de documentos que não cabem no contexto do LLM. Knowledge bases corporativas, suporte técnico com acesso a documentação extensa, análise de contratos com referência a jurisprudência.

Trade-offs adicionais em relação ao Pattern 7:

A qualidade do RAG depende inteiramente da qualidade dos embeddings e da estratégia de chunking. Chunks muito grandes perdem precisão. Chunks muito pequenos perdem contexto. Recuperação por similaridade semântica pode trazer documentos relevantes por superfície mas irrelevantes por conteúdo. Isso exige avaliação contínua da qualidade do retrieval, não apenas do comportamento do agente.

O custo de manutenção do Vector Store é frequentemente subestimado: atualização incremental de embeddings quando documentos mudam, detecção de documentos desatualizados, e controle de acesso por segmento são problemas de engenharia sérios que não existem em sistemas sem RAG.

"

Referência: Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (Meta AI, NeurIPS 2020) é o paper fundacional. Para estratégias de chunking e avaliação de retrieval quality, Gao et al., "Retrieval-Augmented Generation for Large Language Models: A Survey" (2023) é a referência mais abrangente disponível.

O Framework de Decisão: Como Escolher o Pattern Certo

A recomendação de começar simples e adicionar complexidade conforme necessário é correta, mas vaga. Prefiro um critério mais preciso baseado em três perguntas:

1. O problema tem sub-tarefas com contextos genuinamente distintos?

Se não, um único agente bem configurado (Pattern 1 ou 4) é suficiente. A tentação de dividir em múltiplos agentes quando um único agente com bom prompt resolveria é o erro mais comum que vejo.

2. Existe ação irreversível de alto impacto no fluxo?

Se sim, Pattern 5 não é opcional. Não existe argumento de performance ou automação que justifique remover a supervisão humana de ações que não podem ser desfeitas.

3. As sub-tarefas são independentes o suficiente para paralelismo real?

Se houver qualquer dependência de dados ou estado compartilhado não trivial, o overhead de sincronização vai anular o ganho de paralelismo. Prefira sequencial com validação entre estágios (Pattern 2) ao invés de paralelo mal sincronizado (Pattern 7).

Árvore de decisão prática:

Tarefa simples, escopo definido?
  → Pattern 1 (Single Agent + Tools)

Precisa de múltiplos sistemas corporativos?
  → Pattern 3 (+ MCP Servers)

Precisa de roteamento por tipo de input?
  → Pattern 4 (+ Router)

Tem ação irreversível?
  → Pattern 5 (+ Human in the Loop)

Tem estágios sequenciais distintos?
  → Pattern 2 (Sequential Agents)

Agente precisa de especialistas ad-hoc?
  → Pattern 6 (Dynamic Agent Calling)

Sub-tarefas genuinamente paralelas?
  → Pattern 7 (Hierarchy + Parallel)

Precisa de conhecimento em documentos externos?
  → Pattern 8 (+ RAG)

O que Quase Ninguém Fala: Observabilidade em Sistemas Multi-Agente

Nenhuma das discussões sobre arquitetura de agentes é completa sem falar de observabilidade. Um sistema multi-agente sem instrumentação adequada é uma caixa preta que falha de formas silenciosas e difíceis de reproduzir.

O mínimo aceitável para qualquer sistema acima do Pattern 1:

Tracing distribuído por requisição. Cada requisição deve ter um trace ID que propaga por todos os agentes, chamadas de ferramenta e etapas de memória. OpenTelemetry com LangSmith, Langfuse ou Arize Phoenix são as opções mais maduras hoje.

Logging estruturado de prompts e completions. Para cada chamada de LLM: o prompt completo enviado (incluindo system prompt e histórico), a completion recebida, o modelo usado, latência e custo em tokens. Sem isso, diagnosticar comportamento inesperado é adivinhação.

Métricas de qualidade por estágio. Em pipelines sequenciais, instrumentar a qualidade da saída de cada estágio (não apenas se executou sem erro) é o que permite identificar degradação antes que afete o usuário final.

O custo de implementar isso no início é baixo. O custo de adicionar retroativamente num sistema já em produção é alto. Essa é a decisão técnica que mais me arrependo de não ter forçado cedo em sistemas que mantive.

Conclusão: Complexidade Tem Custo, Não Apenas Benefício

A evolução de Pattern 1 para Pattern 8 não é uma progressão de pior para melhor. É uma progressão de mais simples para mais complexo, com custos crescentes de manutenção, debugging, custo financeiro e superfície de falha.

O sistema mais sofisticado que você pode construir é aquele que resolve o problema com o menor grau de complexidade necessário. Não porque simplicidade seja um valor em si, mas porque cada camada de complexidade adicionada é uma dívida de manutenção que o time vai pagar indefinidamente.

Comece no Pattern 1. Adicione complexidade quando o problema exigir, não quando a tecnologia permitir.

Referências

• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (Princeton/Google, ICLR 2023)
• Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (Meta AI, NeurIPS 2020)
• Gao et al., "Retrieval-Augmented Generation for Large Language Models: A Survey" (2023)
• Anthropic, "Model Context Protocol Specification" (modelcontextprotocol.io, 2024)
• Chase, "LangChain: Building Applications with LLMs through Composability" (2022)
• Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation" (Microsoft, 2023)
• Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework" (2023)
• Significant Gravitas, "AutoGPT: An Autonomous GPT-4 Experiment" (2023)