Sistema multiagente: quando um único agente de IA basta

Sistema multiagente: quando um único agente de IA basta

Na maioria dos processos de negócio, um único agente de IA com ferramentas bem definidas basta. Vale usar um sistema multiagente quando há contextos que se atrapalham, permissões que precisam ficar separadas, tarefas independentes que podem rodar em paralelo ou uma etapa que exige revisão com critérios próprios. Fora desses casos, mais agentes costumam trazer mais custo, mais pontos de falha e mais dificuldade para auditar.

Principais pontos

• Comece com um agente, ferramentas com nomes e limites claros e um fluxo que você consiga ler no registro de decisões.
• Dividir compensa quando existe um problema concreto: contexto sobrecarregado, permissões que não devem se misturar, trabalho paralelo ou necessidade de revisão independente.
• Cada agente novo adiciona instruções, falhas possíveis, gasto de tokens e passagens de informação que precisam ser testadas.
• Muitas vezes a resposta certa é um fluxo determinístico com um passo de IA, e não um segundo agente.
• Decida com evidência de um piloto: meça onde o agente único falha antes de redesenhar a arquitetura.

O que é, na prática, um sistema multiagente?

O termo é usado de forma frouxa, e isso gera decisões ruins. Vale separar três coisas.

A primeira é um agente único: um modelo com instruções, acesso a ferramentas (consultar um pedido, listar horários, abrir um chamado) e um laço em que ele decide o próximo passo até concluir ou transferir para uma pessoa.

A segunda é um fluxo de trabalho, ou workflow: etapas definidas em código, em que o modelo é chamado em pontos específicos. Quem decide a ordem é o desenho do fluxo, não o modelo. A documentação da Anthropic sobre construção de agentes faz exatamente essa distinção entre fluxos e agentes, e recomenda buscar a solução mais simples que resolva o problema, aumentando a complexidade só quando ela se justifica.

A terceira é o sistema multiagente: vários agentes, cada um com instruções, contexto e ferramentas próprios, coordenados por um agente principal ou por regras de encaminhamento. Aqui nasce a complexidade: é preciso decidir quem fala com quem, o que cada um enxerga e como o trabalho volta para o conjunto.

Para quem decide na empresa, a pergunta útil não é qual arquitetura parece mais moderna. É qual é a menor estrutura que entrega o processo com controle.

Por que um agente com ferramentas bem definidas resolve tanto?

Boa parte dos fluxos de empresa é estreita. Atender dúvidas de clientes, consultar o status de um pedido, sugerir horários, registrar uma solicitação e passar o caso para uma pessoa quando a situação foge da regra. Para isso, um agente com quatro ou cinco ferramentas bem descritas costuma bastar.

O que separa um bom resultado de um ruim, nesses casos, raramente é o número de agentes. É a qualidade do que está em volta dele:

• Ferramentas com nome claro, parâmetros simples e retorno curto, que devolvem só o que o agente precisa para decidir.
• Instruções que dizem o que fazer, o que nunca fazer e quando transferir para um humano.
• Dados de apoio atualizados, como política de troca, prazos e horários.
• Limites de ação: o que o agente pode apenas consultar e o que exige aprovação.

A Anthropic tem material específico sobre como escrever ferramentas para agentes, e a lição central é que descrições ambíguas e retornos excessivos geram erros que parecem falta de inteligência, mas são falta de projeto. Antes de culpar a arquitetura, vale revisar as ferramentas. Se você está começando pelo canal, o texto sobre como integrar IA no WhatsApp da empresa mostra o ponto de partida.

Também é comum que o problema seja um prompt inchado, com regras de dez assuntos diferentes. Reorganizar as instruções, cortar o que é redundante e mover regras fixas para código resolve mais casos do que criar um agente por assunto.

Quais sinais mostram que dividir em vários agentes compensa?

Existem motivos reais para separar. Eles têm em comum o fato de serem observáveis: você consegue apontar o problema em testes ou no registro de execuções, não apenas sentir que o sistema ficou confuso.

• Contexto sobrecarregado: o agente precisa de documentos e instruções tão diferentes entre si que misturar tudo piora as respostas. A janela de contexto tem limite, e a Anthropic descreve subagentes com contexto limpo como uma das formas de lidar com tarefas longas, desde que cada um devolva um resumo enxuto.
• Permissões que não devem se misturar: uma parte do trabalho lê dados sensíveis (financeiros, de saúde, de crédito) e outra conversa com o público externo. Separar os agentes reduz o estrago se alguém tentar manipular a conversa por meio de uma injeção de instruções.
• Trabalho paralelo: várias subtarefas independentes, como analisar diversos documentos ao mesmo tempo, que ficam lentas se feitas em sequência por um só agente.
• Revisão independente: uma etapa produz e outra confere com critérios diferentes, por exemplo um rascunho de resposta e uma checagem de política. Isso não elimina a revisão humana onde ela é necessária.
• Modelos diferentes para tarefas diferentes: parte do fluxo é simples e pode usar um modelo menor, e parte exige raciocínio mais forte. O custo e a latência justificam a separação.
• Donos e ritmos de mudança distintos: equipes diferentes são responsáveis por partes diferentes e precisam alterar, testar e publicar de forma independente.
• Falha persistente: depois de ajustar ferramentas, instruções e dados, as avaliações continuam mostrando o mesmo tipo de erro numa fatia específica de tarefas.

Um sinal sozinho nem sempre basta. Dois ou três juntos, confirmados em teste, formam um argumento sólido.

E os motivos que parecem bons, mas não são?

Alguns argumentos aparecem muito em reuniões e não sustentam a decisão:

• Fica mais organizado no desenho: organização no diagrama não é organização na execução. Cada seta é uma passagem de informação que pode perder detalhes.
• Cada área quer o seu agente: isso é uma decisão de governança, não de arquitetura. Um agente pode servir várias áreas com permissões por tipo de solicitação.
• O prompt está grande: primeiro corte, reorganize e mova regras fixas para código.
• É o que se vê nos exemplos de demonstração: demonstrações escondem custos de operação, como depuração, avaliação e monitoramento.

Cenário ilustrativo: distribuidora de materiais elétricos

Imagine uma distribuidora que atende lojistas pelo WhatsApp. O agente consulta estoque, informa o status de entrega, envia segunda via de boleto e abre solicitações para o time comercial. São quatro ferramentas, todas de consulta ou de registro simples, e uma regra clara de transferência para um vendedor quando o pedido envolve negociação.

Nesse estágio, um agente único é suficiente. O registro mostra cada ferramenta chamada, e as falhas se concentram em poucos pontos que se corrigem ajustando a descrição das ferramentas.

Meses depois, a empresa quer incluir a análise de pedidos de limite de crédito, que exige ler dados financeiros do cliente e documentos enviados. Agora há dois sinais reais: dados sensíveis que o agente de atendimento não deveria enxergar e um contexto muito diferente (documentos e política de crédito). A divisão passa a fazer sentido: o agente de atendimento continua sem acesso aos dados de crédito e apenas registra o pedido em uma fila. Um segundo agente, interno, prepara a análise e entrega um resumo para a pessoa do financeiro decidir.

Observe o que não mudou: a decisão final continua com um humano, e a passagem entre os dois agentes é uma fila com formato definido, não uma conversa livre.

Guia de decisão: o que fazer antes de adicionar um segundo agente

Use esta sequência como roteiro de revisão.

• Passo um: descreva o processo atual, quem faz o quê hoje e onde estão os dados. Sem esse mapa, qualquer arquitetura é palpite.
• Passo dois: implemente o menor fluxo possível com um agente e poucas ferramentas, com acesso somente de leitura onde der.
• Passo três: crie um conjunto de casos de teste reais, inclusive os difíceis, e defina o que conta como sucesso. A Anthropic e a OpenAI publicam guias de avaliação que ajudam a estruturar isso.
• Passo quatro: registre cada chamada de ferramenta e cada decisão, para saber onde o agente erra.
• Passo cinco: classifique as falhas. São de ferramenta, de instrução, de dado ou de contexto? Corrija a causa mais barata primeiro.
• Passo seis: só se o erro persistir e se encaixar em um dos sinais da lista (contexto, permissão, paralelismo, revisão independente, custo, propriedade), desenhe a divisão.
• Passo sete: ao dividir, defina o formato exato da passagem entre agentes, o que cada um pode acessar e quem responde por cada parte.
• Passo oito: reavalie ponta a ponta. Se o resultado não melhorou de forma que você consiga mostrar, desfaça a divisão.

Quais são os custos escondidos de dividir cedo demais?

Cada agente adicional traz um conjunto de despesas que não aparece no desenho inicial.

Primeiro, a perda de informação nas passagens. O que um agente resume para o outro nunca é tudo, e erros pequenos se acumulam. Segundo, a depuração: quando a resposta final está errada, é preciso descobrir em qual agente o erro nasceu. Isso exige registro estruturado e rastreamento, e conceitos de observabilidade como os do OpenTelemetry ajudam a organizar o que registrar.

Terceiro, o gasto. Mais agentes significam mais chamadas e mais tokens, e a latência cresce quando os passos são sequenciais. Quarto, os laços: agentes que delegam entre si podem entrar em ciclos, por isso limites de passos, tempo e gasto são ainda mais importantes, como discutimos em agente de IA em loop infinito.

Quinto, as validações. Cada fronteira entre agentes é um ponto onde entradas e saídas precisam ser verificadas, tema que detalhamos em guardrails para agentes de IA. Por fim, a LGPD: cada agente que trata dados pessoais entra no mapeamento do tratamento, então mais agentes significam mais itens para documentar e justificar.

Como o método mapear, limitar, pilotar e transferir se aplica?

A decisão entre um ou vários agentes cabe dentro do método que usamos. Em mapear, o processo e a linha de base atual mostram se o fluxo é estreito o bastante para um agente só. Em limitar, definimos quais dados e quais ações cada agente pode ter, e é aí que a necessidade de permissões separadas aparece com clareza. Em pilotar, um fluxo real roda com registro e uma métrica de sucesso combinada, e o registro indica se as falhas pedem divisão ou apenas ajuste de ferramentas (para estruturar a medição, veja como medir um piloto de automação com IA). Em transferir, a equipe recebe o sistema com a documentação do que cada parte faz, e a decisão é expandir, ajustar ou parar.

Perguntas frequentes

Um sistema multiagente é mais inteligente do que um agente só? Não necessariamente. Dividir o trabalho não aumenta a capacidade do modelo, apenas muda como o contexto, as permissões e as tarefas são distribuídas. O ganho aparece quando a divisão resolve um problema medido, como contexto sobrecarregado ou necessidade de isolar dados sensíveis.

Posso manter um agente único e ainda ter revisão humana? Sim, e é um desenho comum e recomendável. O agente executa as ações de baixo risco, e as de maior risco, como descontos, reembolsos ou mudanças de cadastro, ficam em uma fila de aprovação com o motivo registrado. A revisão humana não depende do número de agentes.

Como saber se meu problema é de contexto ou de ferramenta? Olhe o registro das execuções que falharam. Se o agente chamou a ferramenta errada, passou parâmetros ruins ou interpretou mal o retorno, o problema está na descrição ou no formato da ferramenta. Se ele esqueceu instruções, confundiu regras de assuntos diferentes ou perdeu informações em conversas longas, o problema é de contexto, e reorganizar ou dividir pode ajudar.

Um sistema multiagente muda algo para a LGPD? Muda o tamanho do mapeamento, não o princípio. Cada agente que acessa dados pessoais precisa constar no registro do tratamento, com finalidade, base legal e acesso mínimo. Separar agentes pode até ajudar a limitar o que cada um enxerga, desde que isso esteja documentado e testado. Para orientações oficiais, vale acompanhar a ANPD.

Fontes

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• Anthropic: Effective context engineering for AI agents
• Anthropic: Demystifying evals for AI agents