Por que mais agentes de IA nem sempre significa mais resultado
Multi-Agent é provavelmente o termo mais hypado no universo da inteligência artificial em 2025, e não é difícil entender o porquê. A ideia de ter vários agentes de IA trabalhando juntos, cada um cuidando de uma parte específica do problema, parece genial na teoria. E em alguns casos, realmente é. A Klarna, por exemplo, construiu uma arquitetura multi-agent usando LangGraph que lida com 2,3 milhões de conversas por mês — o equivalente ao trabalho de 700 atendentes humanos em tempo integral. O tempo de resolução caiu de 11 minutos para menos de 2, as consultas repetidas diminuíram 25%, a satisfação do cliente subiu 47% e o custo por transação de atendimento foi de 0,32 dólar para 0,19 dólar. A economia total projetada até o final de 2025 gira em torno de 60 milhões de dólares. Esse tipo de resultado faz qualquer líder de tecnologia querer replicar a estratégia imediatamente, mas a realidade é bem mais complexa do que parece à primeira vista.
O balde de água fria vem direto do Gartner, que prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o final de 2027. Não estamos falando de projetos pausados ou reduzidos em escopo — estamos falando de cancelamentos definitivos, motivados por custos fora de controle, valor de negócio nebuloso e controles de risco inadequados. Mesma tecnologia. Mesmo ano. Resultados completamente opostos. Essa estatística mostra que existe uma diferença enorme entre montar um protótipo divertido com três agentes conversando entre si e colocar um sistema multi-agent em produção que realmente entregue valor consistente para o negócio.
O efeito cascata: quando erros se multiplicam por 17 vezes
Em dezembro de 2025, uma equipe do Google DeepMind liderada por Yubin Kim testou rigorosamente a premissa de que mais agentes geram melhores resultados. Eles rodaram 180 configurações diferentes em 5 arquiteturas de agentes e 3 famílias de LLMs (Large Language Models). A descoberta deveria estar colada no monitor de todo time de IA:
Redes multi-agent sem estrutura amplificam erros em até 17,2 vezes comparado a um único agente como baseline.
Não é 17% pior. É dezessete vezes pior.
Quando agentes são jogados juntos sem uma topologia definida — o que o estudo chama de bag of agents — a saída de cada agente vira a entrada do próximo. Os erros não se cancelam. Eles se acumulam em cascata. Imagine um pipeline onde o Agente 1 extrai a intenção do cliente a partir de um ticket de suporte. Ele confunde uma disputa de cobrança com uma simples consulta sobre cobrança — uma diferença sutil, certo? O Agente 2 puxa o template de resposta errado. O Agente 3 gera uma resposta que trata do problema errado. O Agente 4 envia. O cliente responde irritado. O sistema processa a resposta irritada pela mesma cadeia quebrada. Cada loop amplifica a interpretação equivocada original. Esse é o efeito 17x na prática: não uma falha catastrófica e evidente, mas um acúmulo silencioso de pequenos erros que produz nonsense com cara de certeza.
O mesmo estudo encontrou um limiar de saturação: os ganhos de coordenação estabilizam a partir de 4 agentes. Abaixo desse número, adicionar agentes a um sistema estruturado ajuda. Acima dele, o overhead de coordenação consome os benefícios.
Esse não é um achado isolado. O estudo MAST (Multi-Agent Systems Failure Taxonomy), publicado em março de 2025, analisou 1.642 traces de execução em 7 frameworks open-source. As taxas de falha variaram de 41% a 86,7%. A maior categoria de falha: quebras de coordenação, responsáveis por 36,9% de todas as falhas registradas.
O problema da confiabilidade composta
Essa é a matemática que a maioria dos documentos de arquitetura simplesmente ignora, e que pode definir o sucesso ou fracasso do seu projeto.
Um único agente completa uma etapa com 99% de confiabilidade. Parece excelente, certo? Agora encadeie 10 etapas sequenciais: 0,99 elevado a 10 resulta em 90,4% de confiabilidade geral. Ainda aceitável.
Mas se cair para 95% por etapa — o que ainda é um número forte para a maioria das tarefas de IA — dez etapas resultam em apenas 59,9% de confiabilidade total. Vinte etapas? Meros 35,8%.
Você começou com agentes que acertam 19 de cada 20 vezes. Terminou com um sistema que falha quase dois terços das vezes. 😬
Os custos com tokens também se multiplicam nessa lógica. Um workflow de análise de documentos que consome 10.000 tokens com um único agente pode exigir 35.000 tokens em uma implementação com 4 agentes. Isso representa um multiplicador de 3,5x nos custos antes mesmo de contabilizar retentativas, tratamento de erros e mensagens de coordenação entre agentes.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
É por isso que a arquitetura da Klarna funciona e a maioria das cópias dela não funciona. A diferença não é a quantidade de agentes. É a topologia — a forma como os agentes são organizados e se comunicam entre si.
Três padrões de arquitetura multi-agent que funcionam em produção
Em vez de perguntar quantos agentes são necessários, a pergunta mais inteligente é: como eu definitivamente falharia ao construir um sistema multi-agent? A pesquisa responde com clareza. Encadeando agentes sem estrutura. Ignorando o overhead de coordenação. Tratando todo problema como um problema multi-agent quando um único agente bem configurado daria conta do recado.
Três padrões evitam esses modos de falha. Cada um serve a um formato diferente de tarefa.
Plan-and-Execute (Planejar e Executar)
Um modelo mais capaz cria o plano completo. Modelos mais baratos e rápidos executam cada etapa. O planejador cuida do raciocínio; os executores cuidam da ação.
Esse é essencialmente o que a Klarna roda. Um modelo de fronteira analisa a intenção do cliente e mapeia os passos de resolução. Modelos menores executam cada passo: puxar dados da conta, processar reembolsos, gerar respostas. O modelo de planejamento toca a tarefa uma única vez. Modelos de execução lidam com o volume. O impacto nos custos é significativo: direcionar o planejamento para um modelo capaz e a execução para modelos mais baratos pode reduzir custos em até 90% comparado a usar modelos de fronteira para tudo.
Quando funciona: tarefas com objetivos claros que se decompõem em etapas sequenciais. Processamento de documentos, workflows de atendimento ao cliente, pipelines de pesquisa.
Quando quebra: ambientes que mudam durante a execução. Se o plano original se torna inválido no meio do caminho, você precisa de checkpoints de replanejamento ou de um padrão completamente diferente.
Supervisor-Worker (Supervisor e Trabalhadores)
Um agente supervisor gerencia o roteamento e as decisões. Agentes trabalhadores lidam com subtarefas especializadas. O supervisor divide as requisições, delega, monitora o progresso e consolida os resultados.
A pesquisa do Google DeepMind valida esse padrão diretamente. Um plano de controle centralizado suprime a amplificação de erros 17x que redes bag of agents produzem. O supervisor atua como ponto único de coordenação, prevenindo situações onde, por exemplo, um agente de suporte aprova um reembolso enquanto um agente de compliance simultaneamente bloqueia o mesmo pedido.
Quando funciona: tarefas heterogêneas que exigem diferentes especializações. Suporte ao cliente com caminhos de escalação, pipelines de conteúdo com estágios de revisão, análise financeira combinando múltiplas fontes de dados.
Quando quebra: quando o supervisor se torna um gargalo. Se toda decisão passa por um único agente, você recriou o monolito do qual estava tentando escapar. A solução: dar aos trabalhadores autonomia limitada para decisões dentro do seu domínio e escalar apenas os casos extremos.
Swarm (Handoffs Descentralizados)
Sem supervisor. Agentes passam a bola uns para os outros com base no contexto. O Agente A cuida da triagem, identifica que é um problema de cobrança e transfere para o Agente B, especialista em cobrança. O Agente B resolve ou transfere para o Agente C, de escalação, se necessário.
O framework Swarm original da OpenAI era apenas educacional — eles deixaram isso explícito no README. O Agents SDK, versão de produção lançada em março de 2025, implementa esse padrão com guardrails: cada agente declara seus alvos de handoff e o framework garante que as transferências sigam os caminhos declarados.
Quando funciona: workflows de alto volume e bem definidos, onde a lógica de roteamento está embutida na própria tarefa. Suporte ao cliente via chat, onboarding em múltiplas etapas, sistemas de triagem.
Quando quebra: grafos de handoff complexos. Sem um supervisor, depurar por que o usuário acabou no Agente F em vez do Agente D requer ferramentas de observabilidade de nível de produção. Se você não tem tracing distribuído, não use esse padrão.
Qual framework multi-agent usar
Três frameworks dominam as implantações de sistemas multi-agent em produção neste momento. Cada um reflete uma filosofia diferente sobre como agentes devem ser organizados.
LangGraph utiliza máquinas de estado baseadas em grafos. Com 34,5 milhões de downloads mensais, oferece schemas de estado tipados que permitem checkpointing e inspeção precisos. É o que a Klarna roda em produção. A melhor opção para workflows com estado onde você precisa de intervenção humana no loop, lógica de ramificação e execução durável. O trade-off: curva de aprendizado mais íngreme que as alternativas.
CrewAI organiza agentes como times baseados em papéis. Com 44.300 estrelas no GitHub e crescendo, oferece a menor barreira de entrada: defina os papéis dos agentes, atribua tarefas e o framework cuida da coordenação. Deploya times aproximadamente 40% mais rápido que o LangGraph para casos de uso simples. O trade-off: suporte limitado para ciclos e gerenciamento de estado complexo.
OpenAI Agents SDK fornece primitivas leves — Agents, Handoffs e Guardrails. É o único framework importante com suporte igual para Python e TypeScript/JavaScript. Abstração limpa para o padrão Swarm. O trade-off: acoplamento mais forte com os modelos da OpenAI.
Um protocolo que vale conhecer: o Model Context Protocol (MCP) se tornou o padrão de facto para interoperabilidade de ferramentas de agentes. A Anthropic doou o protocolo para a Linux Foundation em dezembro de 2025, cofundado pela Anthropic, Block e OpenAI sob a Agentic AI Foundation. Mais de 10.000 servidores MCP públicos ativos existem hoje. Todos os três frameworks acima suportam o protocolo. Se você está avaliando ferramentas, compatibilidade com MCP é requisito básico.
Se está em dúvida sobre por onde começar, a combinação de Plan-and-Execute com LangGraph é a mais testada em batalha. Cobre a maior variedade de casos de uso. E mudar de padrão depois é uma decisão reversível — não precisa acertar de primeira.
Cinco modos de falha que matam projetos em produção
O estudo MAST identificou 14 modos de falha em 3 categorias. Os cinco abaixo representam a maioria das falhas em produção. Cada um inclui uma medida de prevenção específica que pode ser implementada antes do próximo deploy.
Decaimento de confiabilidade composta
Calcule a confiabilidade ponta a ponta antes de colocar em produção. Multiplique as taxas de sucesso por etapa ao longo de toda a cadeia. Se o número cair abaixo de 80%, reduza o comprimento da cadeia ou adicione checkpoints de verificação. A recomendação é manter cadeias com menos de 5 etapas sequenciais. Insira um agente de verificação na etapa 3 e na etapa 5 que valide a qualidade do output antes de passar adiante. Se a verificação falhar, direcione para um humano ou um caminho alternativo — não para uma retentativa da mesma cadeia.
Taxa de coordenação
Esse modo de falha responde por 36,9% de todas as falhas em sistemas multi-agent. Quando dois agentes recebem instruções ambíguas, eles interpretam de formas diferentes. Um agente de suporte aprova um reembolso enquanto um agente de compliance bloqueia. O usuário recebe sinais contraditórios. A prevenção exige contratos explícitos de entrada e saída entre cada par de agentes. Defina o schema de dados em cada fronteira e valide. Nada de estado compartilhado implícito. Se a saída do Agente A alimenta o Agente B, ambos precisam concordar com o formato antes do deploy, não em tempo de execução.
Explosão de custos
Os custos com tokens se multiplicam entre agentes — 3,5x em casos documentados. Loops de retentativa podem queimar mais de 40 dólares em taxas de API em minutos, sem nenhum output útil para mostrar. A prevenção inclui definir orçamentos rígidos de tokens por agente e por workflow. Implemente circuit breakers: se um agente exceder seu orçamento, interrompa o workflow e mostre um erro em vez de ficar retentando. Registre o custo por workflow completado para identificar regressões cedo.
Brechas de segurança
O OWASP Top 10 para Aplicações LLM encontrou vulnerabilidades de prompt injection em 73% das implantações de produção avaliadas. Em sistemas multi-agent, um agente comprometido pode propagar instruções maliciosas para todos os agentes a jusante. A prevenção exige sanitização de input em cada fronteira entre agentes, não apenas no ponto de entrada. Trate mensagens entre agentes com a mesma desconfiança que você aplicaria a input de usuário externo. Execute um exercício de red team contra sua cadeia de agentes antes do lançamento em produção.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Loops infinitos de retentativa
O Agente A falha. Retenta. Falha de novo. Em sistemas multi-agent, a falha do Agente A aciona o tratamento de erro do Agente B, que chama o Agente A novamente. O loop roda até o orçamento acabar. A prevenção: máximo de 3 retentativas por agente por execução de workflow. Backoff exponencial entre retentativas. Filas de dead-letter para tarefas que falham além do limite de retentativas. E uma regra absoluta: nunca permita que um agente acione outro sem uma verificação de ciclo na camada de orquestração.
Ferramenta versus trabalhador: a diferença de 60 milhões de dólares
Em fevereiro de 2026, o National Bureau of Economic Research (NBER) publicou um estudo pesquisando quase 6.000 executivos nos Estados Unidos, Reino Unido, Alemanha e Austrália. A descoberta: 89% das empresas não registraram nenhuma mudança na produtividade com IA. 90% dos gestores disseram que a IA não teve impacto no emprego. Essas empresas usavam IA em média 1,5 hora por semana por executivo.
A Fortune chamou isso de uma ressurreição do paradoxo de Robert Solow de 1987: você vê a era dos computadores em todo lugar, menos nas estatísticas de produtividade. A história se repetindo quarenta anos depois com uma tecnologia diferente e o mesmo padrão.
Os 90% que não viram impacto implantaram IA como ferramenta. As empresas que economizaram milhões implantaram IA como trabalhadores.
O contraste com a Klarna não é sobre modelos melhores ou mais poder computacional. É uma escolha estrutural. Os 90% trataram a IA como copiloto — uma ferramenta que assiste um humano no loop, usada 1,5 hora por semana. As empresas com retornos reais, como Klarna, Ramp e Reddit via Salesforce Agentforce, trataram a IA como força de trabalho: agentes autônomos executando workflows estruturados com supervisão humana nos pontos de decisão, não em cada etapa.
Isso não é uma lacuna tecnológica. É uma lacuna de arquitetura. O custo de oportunidade é impressionante: o mesmo orçamento de engenharia produzindo zero ROI de um lado versus 60 milhões em economia do outro. A variável não é quanto você gasta. É como você estrutura.
Como escolher o caminho certo para o seu cenário
A decisão entre usar um agente único ou uma arquitetura multi-agent não deveria ser guiada pelo hype, e sim por critérios técnicos e de negócio bem definidos. Pergunte primeiro se o problema que você está tentando resolver requer múltiplas especialidades distintas que não podem ser combinadas em um único prompt ou contexto. Se a resposta for não, comece simples.
Pergunte também qual é o orçamento aceitável de custos operacionais por requisição e qual é a latência máxima tolerável pelo usuário final. Cada agente adicional no sistema aumenta ambos os indicadores. Sem clareza sobre esses limites desde o início, o projeto corre sério risco de se tornar mais um na estatística dos 40% do Gartner.
Invista em observabilidade desde o dia zero. Antes de escrever o primeiro agente, defina como você vai monitorar cada chamada ao modelo de linguagem, cada troca de mensagem entre agentes e cada decisão de roteamento. Ferramentas como LangSmith e plataformas de tracing distribuído criam a camada de visibilidade que é essencial para identificar erros, otimizar performance e controlar custos em produção. Sem isso, você está pilotando no escuro — pode funcionar por um tempo, mas quando a turbulência chegar, e ela vai chegar, você não vai ter instrumentos para navegar. 🧭
Adote uma mentalidade de evolução gradual. Comece com o mínimo de agentes necessários, meça resultados reais — não apenas métricas técnicas, mas impacto no negócio — e adicione complexidade somente quando os dados justificarem.
40% dos projetos de IA agêntica serão cancelados até 2027. Os outros 60% vão para produção. A diferença não vai ser qual LLM escolheram ou quanto gastaram em computação. Vai ser se entenderam os padrões de arquitetura corretos, rodaram a matemática de confiabilidade composta e construíram seus sistemas para sobreviver aos modos de falha que derrubam todo o resto.
A Klarna não implantou 700 agentes para substituir 700 humanos. Ela construiu um sistema multi-agent estruturado onde um planejador inteligente roteia trabalho para executores baratos, onde cada handoff tem um contrato explícito e onde a arquitetura foi desenhada para falhar de forma controlada em vez de entrar em cascata. Os mesmos padrões, os mesmos frameworks e os mesmos dados de falha estão disponíveis para qualquer equipe. O que você constrói com isso é a única variável que resta. 🎯
