Quando vários Agentes começam a atrapalhar: loops, tarefas duplicadas e falhas em cascata

A primeira experiência bem-sucedida com um Agente IA costuma produzir uma conclusão aparentemente lógica: se um Agente consegue realizar uma parte do trabalho, vários Agentes especializados devem conseguir executar a operação inteira.

Surge então um Agente para qualificação, outro para consultar a base de conhecimento, um terceiro para elaborar propostas, um quarto para verificar disponibilidade, outro para revisar as respostas e um supervisor responsável por coordenar todos eles.

No diagrama, a arquitetura parece organizada. Cada Agente possui uma função, as responsabilidades estão distribuídas e o sistema aparenta reproduzir uma equipe real.

Na execução, porém, essa estrutura cria uma nova categoria de problema. As falhas deixam de acontecer apenas dentro de um Agente e passam a surgir nas relações entre eles.

Um Agente pode delegar uma tarefa que ele mesmo poderia concluir. Dois Agentes podem executar a mesma consulta. Um verificador pode devolver a decisão ao supervisor, que envia o caso novamente para verificação. Uma informação incorreta pode atravessar vários componentes e terminar como uma ação válida no CRM, na agenda ou no sistema de pagamentos.

Nesse momento, adicionar mais Agentes não aumenta necessariamente a inteligência da operação. Pode apenas distribuir a responsabilidade até que ninguém saiba quem deveria decidir, executar ou interromper o processo.

O que muda em uma arquitetura multiagente

Um sistema multiagente não é apenas uma aplicação com vários prompts. É uma arquitetura na qual diferentes Agentes recebem papéis, compartilham informações, utilizam ferramentas, delegam tarefas e colaboram para atingir um objetivo comum.

Essa divisão pode trazer benefícios reais. Tarefas independentes podem ser executadas em paralelo, diferentes contextos podem ser isolados e cada Agente pode receber apenas as ferramentas e instruções necessárias para sua especialidade.

O problema é que toda divisão de trabalho cria uma camada de coordenação.

Além de avaliar se cada Agente consegue realizar sua função, a empresa precisa definir:

* quem pode delegar para quem;

* quais informações acompanham cada delegação;

* quem mantém a responsabilidade pelo resultado;

* qual Agente pode alterar cada estado da operação;

* como decisões conflitantes serão resolvidas;

* quantas tentativas podem ser realizadas;

* e em qual condição a execução deve terminar.

O estudo acadêmico Why Do Multi-Agent LLM Systems Fail? construiu uma taxonomia a partir da análise detalhada de mais de 150 traces e depois aplicou essa classificação a um conjunto com 1.642 execuções anotadas.

Os pesquisadores identificaram 14 modos de falha, distribuídos em três grupos principais: problemas de desenho do sistema, desalinhamento entre Agentes e falhas de verificação.

A conclusão mais importante é que muitos erros não dependiam apenas da capacidade dos modelos. Eles surgiam da forma como os Agentes haviam sido organizados, instruídos e coordenados.

Uma equipe de Agentes competentes ainda pode formar um sistema incompetente.

1. Loops: quando nenhum Agente sabe encerrar a tarefa

Um loop acontece quando o sistema continua executando etapas sem produzir progresso proporcional.

Imagine um Agente comercial que solicita a um Agente operacional a confirmação de um horário. O Agente operacional encontra uma inconsistência e devolve o caso ao comercial. O comercial interpreta a devolução como uma nova solicitação de consulta e aciona novamente o operacional.

Outra possibilidade é um Agente revisor rejeitar uma resposta sem informar o que precisa ser corrigido. O Agente responsável gera uma nova versão quase idêntica, envia novamente para revisão e reinicia o ciclo.

Nem todo loop é uma repetição perfeitamente igual. Algumas execuções alternam ferramentas, reformulam perguntas ou acrescentam pequenas informações enquanto permanecem presas ao mesmo problema.

O estudo sobre falhas multiagente encontrou situações em que os Agentes participaram de vários ciclos de comunicação sem modificar efetivamente o artefato que deveria ser produzido. Repetição de etapas e desconhecimento das condições de parada também apareceram como modos específicos de falha.

Na prática, um loop pode ser percebido por sinais como:

* consultas repetidas à mesma ferramenta;

* múltiplas buscas pela mesma informação;

* alternância constante entre dois Agentes;

* reabertura de tarefas já concluídas;

* pedidos recorrentes de confirmação;

* aumento de tokens e latência sem mudança relevante no resultado.

Sem limites explícitos, cada Agente enxerga apenas a próxima ação possível. Nenhum deles necessariamente percebe o custo acumulado da operação ou reconhece que a execução deixou de avançar.

2. Delegação excessiva: quando repassar parece mais fácil do que resolver

Delegar é útil quando outro Agente possui uma capacidade, uma política ou uma ferramenta realmente diferente.

O problema aparece quando a delegação se transforma no comportamento padrão.

Um supervisor recebe uma pergunta simples e aciona três especialistas. Um deles consulta a base de conhecimento. Outro realiza uma busca semelhante. O terceiro reescreve a resposta. Depois, um quarto Agente revisa algo que poderia ter sido concluído em uma única execução.

Durante o desenvolvimento de seu sistema de pesquisa multiagente, a Anthropic observou que instruções vagas faziam os subagentes interpretar a tarefa de formas diferentes, deixar lacunas ou realizar exatamente as mesmas buscas.

Para reduzir a duplicação, cada delegação precisou informar objetivo, formato de saída, fontes, ferramentas e limites da tarefa.

A empresa também registrou que, em seus dados, sistemas multiagente utilizaram cerca de 15 vezes mais tokens do que interações convencionais de chat. Esse custo pode ser justificável em pesquisas complexas e altamente paralelizáveis. Torna-se difícil de sustentar quando vários Agentes são utilizados para executar um processo simples ou linear.

Delegação não deve ser confundida com capacidade. Um sistema que repassa continuamente uma tarefa pode parecer sofisticado enquanto apenas aumenta a quantidade de chamadas necessárias para chegar ao mesmo resultado.

3. Tarefas duplicadas: quando dois Agentes fazem o mesmo trabalho

A duplicação pode acontecer durante a análise ou durante a execução.

Na análise, dois Agentes consultam os mesmos documentos, verificam a mesma informação ou produzem versões concorrentes da mesma resposta. O impacto costuma ser o desperdício de tempo, tokens e chamadas de ferramentas.

Na execução, o risco é maior.

Considere um cenário em que dois Agentes interpretam que são responsáveis por agendar uma reunião. Ambos consultam a agenda, encontram o mesmo horário disponível e realizam a reserva.

Em outro caso, dois Agentes podem enviar propostas diferentes ao mesmo cliente, gerar cobranças repetidas ou registrar duas oportunidades no CRM.

Esse problema costuma aparecer quando os papéis são definidos por temas amplos, como “Agente comercial” e “Agente de fechamento”, mas não existe uma regra operacional determinando quem possui autoridade para executar cada ação.

A especialização precisa chegar ao nível do efeito externo.

Não basta definir quem conversa sobre pagamentos. É necessário determinar quem pode consultar uma cobrança, quem pode criá-la, quem pode cancelá-la e quem apenas recomenda que a ação seja realizada.

4. Disputa de responsabilidade: quando vários Agentes acreditam ter a decisão final

Arquiteturas multiagente frequentemente misturam dois padrões diferentes.

No primeiro, ocorre um handoff entre Agentes IA. A responsabilidade é transferida e o novo Agente assume aquele ramo da interação.

No segundo, os especialistas funcionam como ferramentas. Um Agente principal continua responsável pelo resultado e chama outros Agentes para executar tarefas delimitadas.

A documentação da OpenAI sobre orquestração e handoffs diferencia esses dois modelos.

No handoff, o controle é transferido para o especialista. No padrão de Agentes como ferramentas, o gerente mantém a responsabilidade pela resposta final.

Sem essa definição, o supervisor pode acreditar que o especialista tomará a decisão, enquanto o especialista acredita que deve apenas devolver uma recomendação.

O resultado é uma operação na qual ninguém executa a ação necessária ou, no extremo oposto, vários Agentes tentam executá-la.

Para cada etapa, três perguntas precisam ter respostas inequívocas:

Quem recomenda? Quem decide? Quem executa?

Essas funções podem pertencer ao mesmo Agente, mas não podem permanecer implícitas.

5. Perda e distorção de contexto entre Agentes

Toda delegação transforma contexto.

O Agente de origem seleciona informações, resume a situação e envia uma nova instrução. O Agente seguinte interpreta esse material, realiza sua tarefa e produz outra síntese.

Depois de algumas transferências, detalhes importantes podem desaparecer ou ganhar um significado diferente.

Um pedido como “verifique se podemos oferecer uma condição especial, sem aprovar nada ainda” pode chegar ao último Agente apenas como “ofereça uma condição especial”.

A pesquisa sobre falhas multiagente identificou perda de histórico, retenção de informações, desconsideração das contribuições de outros Agentes e divergência entre raciocínio e ação. Também observou que diferentes categorias de falha podem se combinar dentro da mesma execução.

Por isso, a comunicação entre Agentes não deveria depender apenas de mensagens livres em linguagem natural.

Uma delegação mais controlada pode transportar campos estruturados, como:

* identificador do cliente;

* objetivo da tarefa;

* fatos confirmados;

* hipóteses ainda não confirmadas;

* ações já executadas;

* ferramentas permitidas;

* resultado esperado;

* responsável atual;

* condição de encerramento.

A linguagem natural pode continuar sendo utilizada para interpretação e raciocínio. O estado operacional, porém, não deveria depender exclusivamente dela.

6. Falhas em cascata: quando um erro local atravessa toda a operação

Uma falha em cascata pode começar com uma associação incorreta aparentemente pequena.

Um Agente relaciona a conversa ao cliente errado. Outro consulta o histórico desse cliente. Um terceiro utiliza as informações recuperadas para elaborar uma proposta. Um quarto registra a oportunidade no CRM. Um quinto agenda o acompanhamento.

Cada Agente pode ter executado corretamente sua função com base no contexto recebido. O resultado final continua errado porque a primeira informação nunca foi validada novamente.

Esse é um dos principais riscos das operações multiagente: a saída de um Agente costuma se transformar na entrada confiável do Agente seguinte.

Quanto mais longa a cadeia, maior a possibilidade de uma conclusão incerta adquirir aparência de fato confirmado.

O OWASP Top 10 for Agentic Applications inclui comunicação insegura entre Agentes, falhas em cascata e Agentes descontrolados entre os riscos relevantes das aplicações agênticas.

Mensagens falsas ou comprometidas podem redirecionar conjuntos de Agentes. Sinais incorretos também podem atravessar pipelines automatizados e produzir impactos cada vez maiores.

O projeto COSAiS do NIST, voltado à criação de controles de segurança para sistemas de IA, lista sistemas de Agente único e sistemas multiagente como casos de uso separados. Essa divisão ajuda a reconhecer que a coordenação entre Agentes introduz riscos próprios de segurança, integridade e disponibilidade.

A solução não é pedir que todos os Agentes “tenham mais cuidado”. É criar fronteiras que impeçam um erro de atravessar livremente toda a operação.

7. Verificação que apenas repete o erro

Adicionar um Agente verificador parece uma solução natural. Ele também pode falhar.

O verificador pode receber o mesmo contexto incorreto, confiar na justificativa do Agente anterior ou avaliar apenas a qualidade textual da resposta.

Uma proposta pode estar bem escrita e ainda utilizar valores errados. Uma mensagem pode parecer coerente mesmo que nenhuma alteração tenha sido realizada no sistema.

Em um dos casos analisados pela pesquisa sobre sistemas multiagente, um verificador confirmou apenas que um código compilava. Ele não executou o programa nem verificou se os requisitos funcionais haviam sido atendidos.

A verificação precisa observar evidências diferentes daquelas utilizadas para produzir a decisão.

Quando possível, o verificador deve consultar diretamente o estado real:

* a reserva foi criada na agenda?

* o pagamento realmente foi confirmado?

* o CRM contém apenas uma oportunidade?

* o documento correto foi enviado?

* a alteração ocorreu na conta certa?

* o estado final corresponde ao objetivo solicitado?

A Anthropic explica em seu material sobre avaliação de Agentes IA que esses sistemas operam durante várias etapas, chamam ferramentas, alteram estados e se adaptam a resultados intermediários.

Por isso, a avaliação pode precisar combinar verificação do estado final, análise das ferramentas utilizadas, quantidade de turnos, consumo de tokens e qualidade da interação.

Um Agente pode afirmar que uma reserva foi realizada. A avaliação correta precisa verificar se a reserva realmente existe no sistema.

Avaliar apenas a última resposta pode esconder uma execução cara, repetitiva ou perigosa que, por acaso, terminou com um texto aceitável.

Como controlar uma operação multiagente

O objetivo não deve ser impedir qualquer erro. Deve ser evitar que uma falha isolada se transforme em uma sequência de decisões e ações incorretas.

Mantenha um responsável pelo resultado

Mesmo quando vários especialistas participam da operação, um componente deve manter a responsabilidade pelo objetivo final.

Esse responsável precisa saber:

* quais tarefas foram delegadas;

* quais resultados já retornaram;

* quais ações foram executadas;

* quais estados foram alterados;

* quais condições ainda precisam ser satisfeitas.

O Magentic-One, da Microsoft Research, utiliza um Orquestrador que planeja, acompanha o progresso, direciona os especialistas e refaz o plano quando encontra problemas.

A função do Orquestrador não é apenas distribuir trabalho. Ele mantém uma visão central da execução.

Transforme delegações em contratos

Cada delegação deve definir o que o Agente precisa fazer e o que ele não pode fazer.

Um contrato pode incluir:

* objetivo;

* dados de entrada;

* ferramentas autorizadas;

* formato da resposta;

* limite de tentativas;

* condição de sucesso;

* ações proibidas;

* autorização ou proibição de novas delegações.

“Resolva o problema do cliente” é uma instrução ampla demais.

“Consulte o status da cobrança pelo identificador informado, não altere o pagamento e devolva o status e a data da última atualização em formato estruturado” cria uma responsabilidade delimitada.

Defina um orçamento de execução

Toda operação deve possuir limites.

Isso inclui número máximo de handoffs, quantidade de chamadas de ferramentas, duração total, consumo de tokens, tentativas por ação e profundidade de delegação.

Ao atingir o limite, o sistema não deve continuar improvisando.

Ele pode interromper a execução, solicitar uma informação adicional, utilizar um fluxo determinístico ou encaminhar o caso para revisão humana.

Uma condição de parada não serve apenas para reduzir custos. Ela também impede que o sistema continue tomando decisões depois de perder contexto, acumular erros ou deixar de produzir progresso.

Proteja as alterações de estado

Ações com efeitos externos precisam de controles adicionais.

Reservas, cobranças, propostas, mensagens e atualizações de CRM devem utilizar identificadores de idempotência sempre que possível. Esse mecanismo impede que a mesma intenção produza o mesmo efeito duas vezes.

Também é importante definir um único responsável por escrever em cada recurso durante determinada etapa da operação.

Outros Agentes podem consultar informações ou recomendar ações. Isso não significa que todos precisam receber permissão para modificar o mesmo registro.

Limite permissões por função

Um Agente que consulta informações não precisa cancelar transações. Um Agente que elabora uma proposta não precisa modificar o cadastro do cliente. Um verificador não precisa possuir as mesmas permissões do executor.

Quanto menor o conjunto de ferramentas e privilégios de cada Agente, menor o impacto de uma interpretação errada, de uma mensagem comprometida ou de uma delegação indevida.

Essa separação depende de uma definição clara de identidade, permissões e responsabilidade em Agentes IA. O sistema precisa registrar qual Agente executou a ação, qual autorização possuía e qual componente aprovou a alteração.

Avalie o processo e o estado final

Os testes precisam incluir mais do que perguntas e respostas.

Uma avaliação multiagente deve registrar:

* a sequência completa de delegações;

* as ferramentas chamadas;

* os argumentos enviados;

* os resultados retornados;

* as alterações de estado;

* as repetições;

* o custo da execução;

* a quantidade de tentativas;

* o responsável por cada decisão;

* o resultado existente no ambiente.

Essa análise depende de observabilidade para reconstruir o caminho que levou ao erro. Sem traces, logs e registros de estado, a empresa pode encontrar uma resposta incorreta sem descobrir qual Agente iniciou a falha.

Também é necessário executar o mesmo cenário várias vezes.

Modelos podem seguir trajetórias diferentes diante da mesma entrada. Uma execução bem-sucedida não comprova que o sistema será confiável nas próximas tentativas.

Os erros encontrados devem ser transformados em uma rotina de avaliação contínua de Agentes IA, com cenários repetíveis para loops, duplicações, conflitos de autoridade, falhas de ferramentas e estados finais incorretos.

Quando vários Agentes realmente fazem sentido

Arquiteturas multiagente tendem a ser mais justificáveis quando o problema possui partes realmente independentes, pode ser paralelizado, exige ferramentas muito diferentes ou contém uma quantidade de informação que precisa ser dividida entre contextos especializados.

A Anthropic relata melhores resultados em tarefas de pesquisa ampla, alto valor e exploração paralela. A empresa também observa que processos com muitas dependências e necessidade constante de contexto compartilhado são menos adequados para esse modelo.

O guia prático da OpenAI para construção de Agentes recomenda ampliar primeiro a capacidade de um único Agente e evoluir para sistemas multiagente quando a complexidade das instruções, das ferramentas ou das responsabilidades realmente justificar a divisão.

Antes de adicionar um novo Agente, vale responder:

Qual capacidade ele oferece que o sistema atual não possui?

A tarefa pode ser executada de maneira independente?

O novo Agente terá uma responsabilidade diferente ou apenas outro prompt?

Quem continuará responsável pelo resultado final?

Como a delegação termina?

Como o sistema impede tarefas duplicadas?

Como uma informação será validada antes de produzir efeitos externos?

O ganho de qualidade compensa o aumento de custo, latência e complexidade?

Quando essas respostas não estão claras, a solução provavelmente ainda não precisa de outro Agente.

Pode precisar apenas de uma ferramenta melhor, uma regra determinística, instruções mais precisas ou um workflow bem definido. Afinal, prompt não é operação, e adicionar novos prompts não corrige sozinho uma arquitetura sem controle.

Mais Agentes não significam mais inteligência

O valor de uma arquitetura multiagente não está na quantidade de personagens que aparecem no diagrama. Está na capacidade de dividir um problema sem perder controle sobre o objetivo, o estado e a responsabilidade.

Cada novo Agente adiciona uma possível especialização. Também adiciona outra instrução, outro contexto, outra fonte de decisão, outra superfície de segurança e outro ponto de falha.

Por isso, a pergunta não deve ser “quantos Agentes podemos colocar nesta operação?”.

A pergunta correta é: “qual parte deste processo realmente precisa tomar decisões de forma independente?”.

Quando a resposta for nenhuma, um fluxo determinístico pode ser mais rápido, barato e confiável.

Quando a resposta for uma, um único Agente com boas ferramentas pode ser suficiente.

Quando houver várias responsabilidades realmente independentes, uma arquitetura multiagente pode gerar valor, desde que exista coordenação explícita.

Mais Agentes não significam mais inteligência quando ninguém controla quem decide, quem executa e quando a delegação deve terminar.