Estudo mostra que 67% das falhas de agentes ocorrem sem erro aparente

O problema: chamada de ferramenta não é resultado

A Microsoft, em parceria com a Hugging Face, lançou o ThinkingBox, um sandbox e benchmark para avaliar agentes de IA em fluxos de trabalho corporativos com estado. A tese central: respostas finais e chamadas de ferramenta válidas são apenas proxies - um agente pode soar correto enquanto grava o valor errado no banco de dados. Só os registros deixados para trás encerram a questão.

O artigo abre com um exemplo: uma cliente com um eletrodoméstico de US$ 745 parado há 15 dias num centro de distribuição em Nashville. O agente faz nove chamadas de ferramenta corretas, lê a política corretamente, mas fecha o ticket como 'resolvido' quando o estado exigido era 'em espera' - e a exceção da transportadora continua aberta. Um avaliador que checa chamadas veria sucesso; o banco de dados discorda.

A dimensão da falha silenciosa

Em uma ablação com 121.680 tentativas válidas em 12 modelos de LLM, 79.853 tentativas falharam nas verificações executáveis. Desses fracassos, 67,24% terminaram de forma limpa, invocaram uma ferramenta de mudança de estado e não reportaram erro - ou seja, falharam sem qualquer sinal aparente. Entre eles, as checagens de estado encontraram valores de campo errados em 77,61%, efeitos extras não intencionados em 43,30% e efeitos exigidos ausentes em 25,36% (categorias com sobreposição).

Um sucesso não é confiabilidade

Cada uma das 507 tarefas de negócio roda 20 vezes independentes, sempre a partir de um backend limpo idêntico. O benchmark reporta três métricas: pass@1 (taxa habitual), pass@20 (tarefas resolvidas ao menos uma vez - amplitude) e observado 20/20 (tarefas passadas em todas as tentativas - consistência).

No pass@1, Claude Opus 5.5 lidera com 67,16%, seguido de perto por Claude Opus 5 (66,50%). Mas a consistência muda o quadro: apenas três modelos retêm a maior parte do desempenho após 20 repetições - GPT-6 Astra (78%), Claude Opus 5.5 e Opus 5 (71% cada). GLM-5.1, Kimi-K2.6 e DeepSeek-V4-Pro retêm cerca de 8%.

Kimi-K3, o melhor modelo de pesos abertos, tem a maior amplitude: resolve 93,89% das tarefas ao menos uma vez (476 de 507), mas apenas 13,41% em todas as 20 tentativas. Claude Opus 5 inverte o perfil: menos amplitude (79,09%), mas 47,53% de consistência - 173 tarefas a mais resolvidas de forma consistente que o Kimi-K3. Um modelo mais novo também não resolve o problema: Claude Opus 5.5 supera o Opus 5 no pass@1, mas passa em exatamente as mesmas 241 tarefas nas 20 tentativas.

O domínio importa: varejo tem média de 59,52% de pass@1 entre os modelos listados, contra 33,83% em seguro automotivo; Claude Opus 4.6 vai de 68,62% em varejo a 8,30% em seguro auto.

O preço da consistência

Usando preços de tabela do OpenRouter, os autores calculam o custo por tentativa bem-sucedida. Três modelos formam a fronteira de Pareto: GPT-5.6 Sol (US$ 0,127 por sucesso, o mais barato), GPT-5.4 (US$ 0,131) e Claude Opus 5.5 (US$ 0,276). Claude Opus 5 é dominado em ambos os eixos pelo Opus 5.5.

Para precificar confiabilidade, calculam o custo por tarefa dependente (campanha de 20 execuções ÷ tarefas passadas 20/20): GPT-5.4 é o mais barato (US$ 6,80, mas só 128 tarefas), GPT-6 Astra alcança 231 tarefas a US$ 7,45 e Claude Opus 5.5 atinge 241 tarefas a US$ 7,80 - nenhum domina os outros. A forma mais barata de acertar uma vez não é a mais barata de acertar sempre.

Assinaturas de falha

Cerca de quatro em cada cinco falhas (79,9%) são de manuseio de ferramentas, não de raciocínio: os agentes chegam longe no fluxo, mas não recuperam de erros de ferramenta, pré-condições falhas ou buscas vazias - um problema de retry e recuperação de erros antes de ser um problema de modelo. As recomendações incluem verificar o estado terminal antes de commitar (não o resumo do modelo), classificar erros de ferramenta para retries direcionados, reduzir a superfície de ferramentas e exigir aprovação humana em mudanças difíceis de reverter. Os autores ressalvam que não mediram o ganho dessas práticas no benchmark.

Como funciona e disponibilidade

Cada tarefa define estado inicial do backend, objetivo do usuário, ferramentas MCP disponíveis, política do domínio e verificações executáveis sobre o estado final. Cada tentativa recebe uma sessão MCP isolada, com estado recém-inicializado. Juízes determinísticos comparam o que realmente mudou com o estado final exigido, aceitando qualquer trajetória que produza o resultado correto. 477 das 507 tarefas são avaliadas apenas pelo estado; 30 adicionam rubricas de resposta. O modelo não vê o estado dourado nem as assertions.

O ambiente está disponível no Hugging Face via OpenEnv, com código sob MIT, dados sob CDLA-Permissive-2.0 e resultados verificáveis por commits e releases fixados. Os autores destacam que a parte mais útil não é o leaderboard, mas o ambiente em si: reproduzir tarefas, inspecionar falhas limpas e reportar métricas de repetição definidas explicitamente. Todas as tarefas públicas são reconstruções sintéticas baseadas em padrões reais de agentes corporativos; os clientes não são reais.