Arquitetura de agentes de IA: quando multi-agente vence (e quando é só complexidade gratuita)

Toda conferência de IA agora tem palestra sobre multi-agente. Frameworks novos toda semana — CrewAI, AutoGen, LangGraph, Swarm. E o efeito colateral é previsível: empresas que precisavam de um workflow simples acabam com 4 agentes conversando entre si, custo de inferência triplicado e bug intermitente que ninguém consegue debugar.

Multi-agente é poderoso. Mas é poderoso como o C++ é poderoso: você só precisa quando precisa, e quando não precisa, está pagando custo de complexidade que não retorna.

Vou abrir aqui o framework de decisão que uso pra escolher entre três arquiteturas: workflow determinístico, single-agente e multi-agente.

Workflow determinístico: a opção que ninguém vende

A primeira pergunta sempre é: esse problema precisa de LLM?

Boa parte das "automações de IA" que vejo poderia ter sido resolvida com uma function call simples, uma regex bem feita ou um workflow no n8n. LLM só entra quando o problema tem interpretação de linguagem natural ambígua ou geração de conteúdo contextual.

Exemplos onde workflow determinístico vence:

• Validação de formato de CPF, CNPJ, e-mail → regex
• Roteamento por categoria conhecida → switch case
• Cálculo de score baseado em regras claras → fórmula
• Extração de dado estruturado de input padronizado → parser

Quando o cliente vem com "quero IA para automatizar isso", a primeira investigação é: o input é estruturado? Se for, IA é overkill. Workflow determinístico é mais rápido, mais barato e mais auditável.

Single-agente: 80% dos casos reais

Single-agente é um LLM com prompt, ferramentas (function calls) e contexto. É a arquitetura certa pra:

• Conversação com humanos (atendimento, qualificação, suporte)
• Geração de conteúdo guiado (e-mails, posts, resumos)
• Análise de texto livre (sentimento, intenção, classificação)
• Tradução, reformulação, expansão de conteúdo

Quase tudo que se vende como "IA conversacional" deveria ser single-agente bem feito — não multi-agente.

Single-agente bem feito significa:

• Prompt do sistema denso, com instruções claras de papel, tom e limites
• Function calling para ações que precisam ser determinísticas (consulta a banco, criação de ticket, envio de e-mail)
• Estado externo (não no contexto do LLM) para memória de longo prazo
• Guardrails explícitos do que não pode dizer/fazer

90% dos problemas que dão "vontade de usar multi-agente" são, na verdade, single-agente mal arquitetado.

Multi-agente: quando vale a complexidade

Multi-agente vence quando você tem dois ou mais problemas de natureza fundamentalmente diferente que precisam coexistir no mesmo fluxo.

Exemplo real: operação de transportadora que atende compradores de veículos de frota (B2B, ticket alto, ciclo longo) e interessados em curso sobre leilão (B2C, ticket baixo, ciclo curto) no mesmo WhatsApp.

Single-agente nesse caso vira um Frankenstein: o mesmo prompt tem que ser técnico-comercial pra frota e didático-vendedor pra curso. Resultado: faz mal os dois.

Multi-agente resolve com:

• Router: classifica o lead na primeira mensagem (B2B ou B2C)
• SDR especializado em frota: tom técnico, conhece especificações, leva pra agendamento com vendedor
• Closer especializado em curso: tom didático, conhece a metodologia, leva pra checkout
• Guardrail compartilhado: ambos passam por validação antes de qualquer ação irreversível

Cada agente tem prompt e ferramentas dedicadas. A complexidade extra paga conta porque a alternativa (single-agente fazendo dois trabalhos) seria pior em ambos.

Outros casos onde multi-agente faz sentido:

• Pipelines analíticos com etapas heterogêneas (extração + análise + síntese + ação)
• Mesa de operações com agentes especializados por skill (research, execution, compliance)
• Sistemas de pesquisa com agentes que se contradizem propositalmente para reduzir viés

A pergunta que separa o joio do trigo

Quando você está em dúvida entre single e multi-agente, pergunte:

"O mesmo prompt e o mesmo conjunto de ferramentas resolveriam todos os casos?"

Se a resposta é sim, é single-agente. Se você precisa de prompts substancialmente diferentes ou conjuntos de ferramentas diferentes para subproblemas diferentes, aí entra multi-agente — e a complexidade extra está justificada.

Os 3 erros mais comuns

Vejo esses erros toda semana em projetos de IA:

1. Multi-agente prematuro: 4 agentes pra problema que single-agente resolveria. Custo de inferência multiplicado por 4, latência multiplicada por 4, debug 10x mais difícil. Justificativa: "queríamos arquitetura escalável". Você não escalou nada, só complicou.

2. Single-agente fazendo trabalho de workflow: LLM consumindo R$ 800 por mês para fazer roteamento de chamado que uma function call de 5 linhas resolveria. Latência ruim, custo ruim, auditoria impossível.

3. Workflow determinístico tentando ser inteligente: switch case com 47 ramificações tentando lidar com input em linguagem natural. Cobertura ruim, manutenção impossível, deveria ser single-agente desde o começo.

Conclusão

Multi-agente é uma ferramenta poderosa, mas não é a resposta default. A arquitetura certa é a mais simples que resolve o problema com qualidade — e crescer dela quando o problema cresce.

Em todo projeto novo que entro, começo perguntando se realmente precisa de LLM. Depois, se single-agente resolve. Multi-agente só entra quando tenho evidência clara de que single-agente seria pior. Essa disciplina economiza dezenas de horas de retrabalho e milhares de reais em fatura mensal de inferência.

Outros posts