Agente de IA que julga bem nem sempre confere antes de agir

Um agente de IA é uma IA que, além de responder, faz coisas: abre um sistema, consulta um registro, estorna uma cobrança, muda um cadastro. Quem pensa em colocar um desses pra trabalhar faz a pergunta óbvia: dá pra confiar?

O jeito comum de responder é testar assim: você descreve uma situação e pergunta “nessa hora, você faria isso?”. Se ele acerta, parece pronto.

Um paper de outubro de 2026 fez outra pergunta: quando o agente precisa ir atrás da informação e agir sozinho, ele confere antes de mexer? O título é “From Evidence to Action: How Tool-Using Agents Fail”, de Hongzhan Lin, Shidong Cao, Ziyang Luo, Wenhao Chai, Mong-Li Lee e Wynne Hsu. E o achado é que, no paper, julgar bem uma ação e conferir antes de executá-la não andaram juntos.

Um exemplo mostra o que isso quer dizer, e ele é do próprio paper.

Uma loja, duas cobranças

Imagina uma loja pequena. A cliente liga e diz: “fui cobrada duas vezes, estorna a segunda”. Antes de devolver o dinheiro, quem atende precisa confirmar três coisas sobre aquela cobrança: que ela é mesmo duplicada, que ainda dá pra estornar e que o valor é o que a cliente falou.

Agora o que o agente faz. Ele abre a primeira cobrança, vê que tem o mesmo valor, e estorna a segunda. O sistema aceita, o dinheiro volta, a cliente agradece. Parece perfeito.

Só que ele conferiu a conta errada. Se a segunda era uma compra legítima, a loja acabou de devolver dinheiro que não devia, e ninguém vai perceber, porque o resultado final tem cara de certo. O paper chama as cobranças de C1 e C2 (eu chamei de primeira e segunda) e diz, na seção 3.1: “Querying C1 does not establish these conditions for C2, even when the returned values match.” Em português: consultar a C1 não estabelece essas condições para a C2, mesmo quando os valores retornados batem.

Como mediram, e onde a nota despenca

Os autores montaram 656 situações de trabalho em seis áreas (atendimento ao cliente, engenharia, jurídico e financeiro, pesquisa, casa inteligente e saúde), todas criadas por eles, e separaram o trabalho em protocolos, que eu vou chamar de degraus. No primeiro, o agente recebe tudo pronto, ação sugerida e informação na mesa, e só decide se permite, bloqueia ou adia. Depois vem a investigação sozinho, com ação única; e depois sequências de ações, em que uma depende da anterior (estornar e depois avisar a cliente com o número do estorno que acabou de sair).

Testaram dez combinações de modelo e programa de agente (o software que roda o modelo em volta). No degrau de só julgar, o acerto ficou entre 77,9% e 97,7%. Na ação única, com investigação, ficou entre 31,3% e 61,1%. A combinação mais dramática é a do GLM rodando no ZCode: 97,7% no julgamento, 12,1% na sequência de ações em linha reta e 34,1% quando a sequência tem dependência entre as ações. No total, contando todos os degraus, a melhor combinação (Claude no Claude Code) resolveu 67,2% dos casos por completo, e a pior 37,7%.

O número que eu acho mais revelador vem de outro lado, e ele tem uma pegadinha que precisa ser dita. Entre os casos de ação única em que o agente chegou a concluir a investigação antes de tentar agir, a ação deu certo em 93,2% a 100% em nove das dez combinações, e em 83,3% na décima. Repare: é um recorte, só entram os casos em que ele conferiu. O que o número mostra é que, quando confere, acerta. Não diz com que frequência ele confere.

E tem um teste que vale contar. Os autores esconderam de propósito um dado decisivo, daqueles sem os quais não dá pra agir com segurança. Esse teste rodou em 3 das 10 combinações (DeepSeek no DSH, GLM no ZCode e Qwen no Qwen Code), sobre 43 casos de ação única. Nessas três, os agentes agiram em 46,5% a 53,5% dos casos em que o dado estava escondido. Falta de informação, sozinha, não segurou o agente nessas três.

O que isso muda, na minha leitura

Eu acho esse achado importante por um motivo específico: ele move a atenção de lugar. A gente costuma discutir qual modelo é mais esperto. O paper mostra que a pergunta que mede esperteza (“pode fazer isso?”) é a que o agente já responde bem, e que a nota cai em outra pergunta que quase ninguém testa: “você foi olhar o registro certo antes de mexer?”. O paper não isola o motivo dessa diferença, então eu também não vou afirmar um.

Quem testa agente perguntando “nessa situação você faria isso?” e vê ele acertar quase tudo pode estar medindo a habilidade errada. É como contratar um atendente pela prova teórica e nunca ver ele abrir o sistema.

O que dá pra fazer hoje

Se você vai colocar um agente pra mexer em dinheiro, cadastro ou estoque, a conferência não pode depender da boa vontade dele. Duas coisas, que servem pra qualquer ferramenta:

1. Teste o caminho, não só o resultado. Deixe o agente buscar a informação sozinho e olhe no registro de ações se ele consultou o item certo antes de mexer. Resultado final certo com consulta errada é sorte.
2. Escreva a conferência na instrução, com o objeto. Algo assim:

“Antes de estornar, consulte a cobrança que a cliente citou, e só ela. Confirme que é duplicada, que ainda pode ser estornada e que o valor bate. Se não conseguir confirmar as três coisas, não estorne: me avise o que faltou.”

Repara que o prompt diz qual registro consultar. “Confira antes” no vazio é justamente a instrução que o agente pode cumprir olhando a conta errada.

O que eu tiro disso

Que “o agente acerta quando eu pergunto” é uma boa notícia que não prova o que parece provar. O trabalho chato de sempre continua valendo: dizer o que conferir, no objeto certo, e ver o caminho em vez de só o final.

Um minuto olhando o registro. É a diferença entre um agente que ajuda e um que devolve dinheiro que não devia, com cara de certo.