Agente de IA em sistema de negócio: acertar uma vez não basta

Uma cliente escreve para o atendimento. O eletrodoméstico de US$ 745 que ela comprou está parado há 15 dias numa "exceção" da transportadora. O agente de IA faz um trabalho caprichado: nove chamadas de ferramenta, puxa o pedido, confere o rastreio, consulta o perfil da cliente, lê a política de reembolso duas vezes, vê que não existe chamado, abre um, registra a linha do tempo. Lê a política certo, inclusive: o segmento dela não tem direito a compensação por atraso.

Depois fecha o chamado como resolvido e pergunta se pode ajudar em mais alguma coisa.

A exceção da transportadora continuava aberta. O estado correto do chamado era "em espera", e a cliente não recebeu resposta ao que perguntou. Quem olhasse as chamadas de ferramenta veria nove chamadas bem formadas. Quem conferisse se o agente gravou no banco veria que gravou. O erro está num campo só: o status.

O caso é uma das tarefas do ThinkingBox, benchmark que a Microsoft publicou com a Hugging Face em 3 de outubro. Ele roda 507 fluxos de negócio com estado, em cinco domínios (varejo, seguro de automóvel, viagem, banco digital e consultoria), executa cada tarefa 20 vezes a partir de um banco limpo e julga o agente pelo que ficou gravado no fim, não pelo que ele disse.

Duas de cada três falhas terminam sem erro nenhum

No recorte comum a 12 modelos, os autores contaram 121.680 tentativas válidas e 79.853 reprovações. Das reprovadas, 67,24% terminaram limpas: o agente chamou uma ferramenta que altera dados, não recebeu erro no fim e encerrou a conversa como se tivesse concluído. Nessas falhas, a checagem do banco achou valor de campo errado em 77,61%, efeito extra não pedido em 43,30% e efeito obrigatório ausente em 25,36% (um mesmo caso pode cair em mais de uma categoria).

Para quem opera, isso muda o que monitorar. Um painel que conta erros de API e conversas encerradas vai mostrar a maior parte dessas falhas como sucesso. O agente não avisa que errou porque, do ponto de vista dele, não errou.

A média de acerto esconde a repetição

A tabela que costuma circular é a de acerto por tentativa, o pass@1. Nela, o Claude Opus 5.5 lidera com 67,16%, seguido de perto pelo Claude Opus 5, com 66,50%. O ThinkingBox acrescenta outra coluna: quantas das 507 tarefas o modelo acertou nas 20 execuções.

O GPT-6 Astra tem a sexta melhor média da lista completa de 18 modelos e fica a dez tarefas do topo em consistência. O GPT-5.4 tem média praticamente igual à dos dois Opus e acerta sempre pouco mais da metade das tarefas que eles acertam. O Kimi-K3 é o caso extremo: resolve 476 tarefas pelo menos uma vez, a maior cobertura do teste, e só 68 em todas as 20.

E a versão nova não comprou estabilidade. O Opus 5.5 tem média maior que o Opus 5 e acerta sempre exatamente as mesmas 241 tarefas.

Por que 95% de acerto vira 36% em vinte execuções seguidas

A queda entre as duas colunas assusta menos quando se faz a conta. Pense numa tarefa que o agente acerta 95% das vezes, e suponha que cada execução seja independente da outra. A chance de acertar 20 seguidas é 0,95 elevado a 20: 35,8%. Com 99% de acerto por execução, a chance sobe para 81,8%. Para ter uma chance em duas de passar nas 20, a tarefa precisa sair certa em 96,6% das execuções.

É um modelo simplificado, porque na prática as falhas não são independentes: há tarefas que o modelo erra quase sempre e tarefas que acerta quase sempre. Mas ele mostra por que a média engana. Uma taxa que parece ótima numa demonstração vira, na escala de um mês de operação, uma fila de registros errados. Se o agente vai fechar centenas de chamados ou alterar centenas de pedidos, o número que interessa é quantas tarefas ele acerta todas as vezes.

O mais barato por acerto não é o mais barato por tarefa confiável

Os autores estimaram custo a partir dos tokens que cada modelo gastou, com o preço de lista do OpenRouter em outubro de 2026, sem desconto e sem cache contratado. Eles mesmos chamam o resultado de índice comparativo, não de fatura.

Por esse índice, o GPT-5.6 Sol é o mais barato por tentativa bem-sucedida, a US$ 0,127. Mas como ele acerta todas as 20 vezes só 82 tarefas, o custo por tarefa confiável dele fica em US$ 9,76, 44% acima do GPT-5.4, que tem custo por acerto quase igual (US$ 0,131) e 56% mais tarefas confiáveis que o Sol (128 contra 82). O Opus 5.5 custa mais que os dois por acerto (US$ 0,276) e, por tarefa confiável, fica em US$ 7,80, perto do GPT-5.4. O Opus 5 acerta as mesmas 241 tarefas do 5.5 por US$ 13,30 cada.

Nenhum dos três da frente domina os outros: cada tarefa confiável a mais custa mais caro. A leitura que vale para qualquer fornecedor é outra: escolher o modelo pelo preço por token, ou mesmo pelo preço por acerto, pode levar ao mais caro no critério que importa para quem grava em sistema.

E o token é só uma linha da conta. Integração com o ERP, o CRM ou o sistema de chamados, observabilidade, governança, adequação à LGPD e o custo do registro errado que ninguém viu ficam fora do benchmark, e não há dado público sobre eles para um caso como este.

Quatro em cinco falhas vêm da ferramenta, não do raciocínio

Os autores classificaram cada falha com um rótulo diagnóstico. Uso de ferramenta respondeu por 79,9% delas, atualização de estado errada por 10,3%, resolução incompleta para o usuário por 7,0% e ausência de ação por 2,9%. São médias das parcelas de cada modelo, e o rótulo descreve o sintoma, não uma causa única.

O padrão descrito é reconhecível para quem integra agente em sistema real: o agente chega longe no fluxo e não se recupera quando a ferramenta devolve erro, quando uma pré-condição falha ou quando a busca volta vazia. Isso é problema de engenharia em volta do modelo antes de ser problema do modelo. A diferença entre domínios reforça o ponto: a média de acerto foi de 59,52% em varejo e de 33,83% em seguro de automóvel, com as mesmas regras do jogo.

Os autores recomendam conferir o estado final antes de confirmar, classificar os erros de ferramenta para que a nova tentativa mire só os recuperáveis, reduzir as ferramentas ao que o fluxo precisa e exigir aprovação humana para mudança que não se desfaz barato. E avisam que não mediram o ganho de nenhuma dessas medidas.

Nos nossos fluxos internos de agente de QA, que navegam pelo painel administrativo de um sistema e testam desktop e mobile, o que torna o resultado utilizável é a evidência registrada a cada passo, não o relatório final do agente. Foi por ela que um problema de responsividade apareceu antes de chegar ao cliente. O princípio é o mesmo do ThinkingBox: o que vale é o que ficou registrado.

Para quem essa régua é exigente demais

Exigir 20 acertos em 20 faz sentido para o agente que grava em registro e cujo erro custa caro ou demora a aparecer: status de chamado, valor de pedido, cadastro de cliente, lançamento financeiro. Não é o critério certo para tudo.

Um agente que escreve rascunho revisado por uma pessoa, que só consulta dados ou que faz triagem com aprovação humana antes de qualquer gravação convive bem com acerto menor, porque o erro dele é barato e visível. Nesses casos, cobrar 20 de 20 atrasa o projeto sem proteger nada.

Também vale lembrar o que o ThinkingBox é. É um benchmark dos próprios autores, ainda sem replicação independente, com usuário simulado e cenários sintéticos em domínios no molde americano. Os cinco domínios seguem o molde americano, e um fluxo com ERP brasileiro, nota fiscal ou Pix pode se comportar de outro jeito. O ranking de modelos vale para esta versão do teste e para os preços de outubro de 2026, e os dois mudam rápido. O que deve durar é o método: julgar o agente pelo banco e pela repetição.

Como aceitar um agente que grava no seu sistema

O dado e o código do ThinkingBox estão publicados, mas a pergunta útil para a sua empresa não se responde com as tarefas de outra pessoa. Ela se responde com as suas:

1. separe as tarefas do agente que gravam em registro e não se desfazem barato. São essas que precisam do critério duro;
2. para cada uma, escreva o estado final esperado no banco, campo a campo, inclusive o que não pode mudar;
3. rode cada tarefa várias vezes contra uma cópia do banco, a partir do mesmo estado inicial, e confira o registro, não a mensagem de "concluído";
4. trate a tarefa que não passa todas as vezes como tarefa com aprovação humana, até que passe;
5. em produção, monitore o mesmo sinal: amostras de registros conferidas contra o estado esperado, e não só a taxa de erro de API.

Se você já tem um agente rodando, a pergunta é direta: das tarefas que ele executa e gravam no sistema, quantas foram conferidas no banco, repetidas, antes da liberação?

Fontes e método

• Microsoft e Hugging Face, "The Agent Said It Was Done. The Database Disagreed.", publicado em 03/10/2026 no blog da Hugging Face, com o artigo do ThinkingBox no arXiv (2608.19741), o código e o conjunto de dados. Todos os números de acerto, consistência, falhas e custo são dos autores, na versão thinkingbox-bench-v1.0, consultados em 04/10/2026. Os custos são estimativa a preço de lista do OpenRouter em 10/2026, índice comparativo e não fatura.
• Conta própria: a probabilidade de 20 acertos seguidos (0,95 elevado a 20; 0,99 elevado a 20; e a taxa de 96,6% para chance de 50%) supõe execuções independentes e taxa fixa, simplificação declarada no texto. A diferença de 44% entre o custo por tarefa confiável do GPT-5.6 Sol e o do GPT-5.4 é a divisão de US$ 9,76 por US$ 6,80, ambos da tabela dos autores.
• Experiência da X-Apps: fluxos internos de agente de QA, descritos sem número e sem nome de cliente.