Agentes de IA raramente falham de forma abrupta. Eles falham silenciosamente, e pesquisas mostram por quê

Agentes baseados em grandes modelos de linguagem já respondem a chamados de suporte, consultam bancos de dados e planejam viagens. Quando algo dá errado, geralmente retornam uma resposta confiante e um código de sucesso. Um conjunto crescente de pesquisas explica por que essas falhas são difíceis de detectar e como as equipes de engenharia estão aprendendo a medi-las.

Uma falha que parece um sucesso

Softwares tradicionais tendem a falhar de forma evidente. Uma função lança uma exceção, um servidor retorna um código de erro e um painel de monitoramento fica vermelho. Um agente de IA se comporta de outra maneira. Ele funciona em um ciclo: um modelo de linguagem lê uma instrução, decide chamar uma ferramenta, como uma API de busca ou um banco de dados, lê o resultado e decide o que fazer em seguida. Cada etapa pode dar errado, embora todas as solicitações de rede da cadeia sejam concluídas com sucesso.

Considere um caso comum. Uma ferramenta de previsão do tempo falha e retorna o texto “serviço indisponível” em meio a uma resposta que, de resto, parece normal. O modelo lê esse texto, pede desculpas educadamente ou, pior, produz uma previsão plausível com base nos dados de treinamento. O usuário recebe uma resposta fluente. Os registros do servidor mostram uma solicitação bem-sucedida, com latência normal. Nada em uma infraestrutura convencional de monitoramento registra que algo deu errado.

Os provedores de modelos descrevem essa mesma lacuna em sua própria documentação. O guia da API Gemini do Google observa que o modelo “não executa a função por conta própria”. Ele apenas propõe o nome de uma função e seus argumentos; quem executa a chamada é o aplicativo do desenvolvedor. Portanto, o aplicativo é a única parte do sistema que vê o resultado real. O guia de engenharia da Anthropic sobre como criar agentes destaca um ponto relacionado: os agentes precisam de uma “verdade de referência” fornecida pelo ambiente a cada etapa, como os resultados das ferramentas, para avaliar o próprio progresso. Quando uma ferramenta informa uma falha como texto comum, essa referência está errada, e o agente não tem como perceber.

Esse não é um problema novo, mas apenas uma versão mais aguda de um problema antigo. Em 2015, engenheiros do Google liderados por D. Sculley descreveram a “dívida técnica oculta” em sistemas de aprendizado de máquina. Eles argumentaram que a maior parte dos riscos de um sistema de aprendizado de máquina em produção está fora do código do modelo, em dependências de dados, configurações e código de integração. Os agentes acrescentam uma nova camada a essa lista. Instruções e descrições de ferramentas são configurações capazes de alterar o comportamento de um sistema sem que seu código mude.

Pequenas alterações, grandes efeitos

Quanto impacto pode ter uma pequena alteração em uma instrução? Em um artigo apresentado na ICLR 2024, Melanie Sclar, da University of Washington, e seus colegas alteraram apenas a formatação de instruções com poucos exemplos: separadores, espaçamento e uso de maiúsculas. O significado permaneceu o mesmo. Ainda assim, o desempenho na mesma tarefa variou em até 76 pontos de acurácia no LLaMA-2-13B. A sensibilidade não desapareceu com modelos maiores, mais exemplos ou ajuste por instruções.

Os autores recomendam apresentar uma faixa de desempenho para formatos de instrução plausíveis, em vez de um único número. Para as equipes de engenharia, a lição prática é mais simples: uma alteração em uma instrução é uma alteração no código. Ela precisa de um histórico de versões e deve ser testada antes de chegar aos usuários.

O mesmo vale para as descrições das ferramentas, que o modelo lê como parte da instrução. O guia da Anthropic recomenda dedicar às definições das ferramentas “tanta atenção à engenharia de instruções” quanto à instrução principal. O guia descreve um agente de programação que cometia erros repetidamente ao lidar com caminhos relativos de arquivos. Quando a ferramenta passou a exigir caminhos absolutos, o modelo a utilizou sem erros. O modelo não mudou. Mudou apenas a descrição que ele leu.

Um único sucesso prova pouco

Uma segunda linha de pesquisa analisa a consistência. O benchmark τ-bench, publicado por Shunyu Yao e colegas da Sierra e apresentado na ICLR 2025, simula conversas de atendimento ao cliente nas quais um agente precisa usar ferramentas e seguir regras de negócio. Os autores introduziram uma métrica chamada pass^k: a probabilidade de um agente resolver corretamente a mesma tarefa em todas as k tentativas.

Os resultados foram preocupantes. Um agente GPT-4o resolveu cerca de 61% das tarefas de varejo em uma única tentativa. Quando precisava concluir a mesma tarefa com sucesso oito vezes seguidas, a taxa caía para cerca de 25%. Uma demonstração que funciona uma vez diz pouco sobre o comportamento de um sistema na milésima execução.

Onde os sistemas multiagentes falham

Muitas equipes agora encadeiam vários agentes: um planeja, outro executa e um terceiro verifica o trabalho. Um estudo de 2025 da UC Berkeley, “Por que os sistemas multiagentes de LLM falham?”, analisou mais de 1.600 rastros de execução anotados em sete frameworks multiagentes populares. Os autores, liderados por Mert Cemri, criaram uma taxonomia chamada MAST, com 14 modos de falha divididos em três grupos: problemas de projeto do sistema, desalinhamento entre agentes e verificação de tarefas.

A principal conclusão é que muitas falhas decorrem do projeto do sistema, e não apenas das limitações do modelo subjacente. Os agentes ignoram o papel que lhes foi atribuído, perdem o fio da conversa ou declaram uma tarefa concluída sem verificar o resultado. Essas falhas não deixam registros de erro. Só ficam visíveis quando alguém consegue ler o que cada agente realmente fez. A cobertura da Unite.AI sobre o paradoxo multiagente destaca um ponto relacionado do ponto de vista da arquitetura: acrescentar agentes pode amplificar um erro inicial, em vez de anulá-lo.

Tornando visível o que é invisível

A resposta da engenharia recorre aos sistemas distribuídos, nos quais há muito tempo se rastreiam solicitações que passam por vários serviços, usando uma técnica chamada rastreamento. Aplicada a agentes, cada solicitação do usuário se torna um rastro, e cada chamada de modelo ou de ferramenta se torna um “span” dentro dele. Um span registra sua entrada, sua saída, os tokens usados e quanto tempo levou. O órgão responsável pelos padrões do setor nessa área, OpenTelemetry, está elaborando convenções comuns para spans de IA generativa. Em 2026, essas convenções ainda estão classificadas como em desenvolvimento, então os nomes dos atributos ainda podem mudar.

Vários projetos de código aberto, como Langfuse, Arize Phoenix e AcruxCore, já aplicam essa ideia. O código-fonte é público, então as equipes podem inspecionar como um rastro é armazenado e executar o software em seus próprios servidores. Esses projetos registram chamadas de modelos e de ferramentas como spans de um único rastro e permitem que as equipes associem pontuações de qualidade a eles. A escolha da ferramenta importa menos do que um detalhe: um span de ferramenta precisa registrar o que ela realmente retornou, e não apenas se a solicitação de rede foi bem-sucedida. Sem isso, a falha da ferramenta meteorológica descrita acima continua invisível.

Pesquisas do setor indicam que o rastreamento já é comum, mas os testes ainda estão atrasados. O relatório sobre o estado da engenharia de agentes da LangChain entrevistou 1.340 profissionais no fim de 2025. A qualidade foi o obstáculo mais citado para colocar agentes em produção, mencionada por 32% dos entrevistados. 89% das organizações disseram ter alguma forma de observabilidade para seus agentes, e 62% dispunham de rastreamento detalhado de etapas individuais e chamadas de ferramentas. Apenas 52,4% realizaram avaliações offline com conjuntos de teste, e 37,3% avaliaram o tráfego em tempo real. A maioria das equipes consegue ver o que seus agentes fizeram. Menos equipes verificam se o que fizeram estava correto.

Avaliando respostas em escala

Os rastros mostram o que aconteceu. Não dizem se a resposta foi boa. Ler manualmente todas as conversas não é viável em grande escala, então as equipes recorrem cada vez mais a um segundo modelo como avaliador, numa abordagem conhecida como LLM como juiz. Um artigo da NeurIPS 2023, de Lianmin Zheng e colegas, constatou que modelos avançados, como o GPT-4, concordaram com as preferências humanas em mais de 80% das vezes — aproximadamente a mesma taxa de concordância entre as próprias pessoas.

O mesmo artigo documentou as limitações do método. Os modelos avaliadores preferem a resposta apresentada primeiro, favorecem respostas mais longas e podem privilegiar textos escritos por eles próprios. Portanto, as pontuações dos avaliadores são estimativas. Elas são úteis em grande escala, mas precisam ser verificadas com um pequeno conjunto de exemplos rotulados por pessoas, com a ordem das respostas aleatorizada.

Da prática à política

Esse trabalho de medição também está se tornando uma expectativa de governança. O Instituto Nacional de Padrões e Tecnologia dos EUA publicou seu Marco de Gestão de Riscos de IA em janeiro de 2023. Uma de suas quatro funções centrais, “Medir”, solicita que as organizações quantifiquem, acompanhem e documentem os riscos de IA ao longo do tempo. Para um agente, os rastros e as pontuações de avaliação são as evidências exigidas por essa função.

O que as equipes podem fazer agora

Isso ecoa o argumento apresentado nesta plataforma de que a confiabilidade é o verdadeiro teste da IA agêntica. A pesquisa acima acrescenta os detalhes de medição que sustentam esse argumento: a confiabilidade não é uma propriedade que se observa uma única vez, mas uma faixa que é preciso medir continuamente.

A pesquisa aponta para um pequeno conjunto de práticas, muitas das quais também são recomendadas pelos principais provedores de modelos. O guia prático da OpenAI para criar agentes orienta as equipes a “configurar avaliações para estabelecer uma linha de base de desempenho” antes de otimizar, e a transferir o controle para uma pessoa quando um agente ultrapassar um número definido de tentativas malsucedidas ou se deparar com uma ação de alto risco. A Anthropic recomenda “testes extensivos em ambientes isolados” antes que os agentes atuem por conta própria.

Na prática, isso significa adotar algumas medidas concretas. Mantenha os prompts e as descrições das ferramentas sob controle de versão, como código. Teste cada alteração de prompt com um conjunto de dados fixo e espere uma variedade de resultados, em vez de um único número. Execute cada caso de teste várias vezes, porque uma única execução oculta inconsistências. Registre as saídas das ferramentas nos rastros, para que uma ferramenta com falha não possa se esconder atrás de um código de sucesso. Trate as pontuações de avaliadores automatizados como estimativas e confira-as com pessoas.

Nenhuma dessas práticas exige um avanço nas capacidades dos modelos. Elas exigem que se trate um agente de IA pelo que ele é: um sistema probabilístico que precisa ser medido, porque raramente anunciará as próprias falhas.