Tempo de leitura: 7 minutos
Olá, é um prazer inenarrável estar mais uma vez escrevendo este post.
Um agente de IA pode fazer nove chamadas de ferramenta, consultar políticas corretamente e ainda assim deixar o sistema em um estado errado. Foi justamente esse tipo de falha que a Microsoft e a Hugging Face decidiram medir com o ThinkingBox, um novo ambiente de avaliação para agentes que executam tarefas empresariais.
O projeto foi apresentado em 3 de outubro de 2026 e já está disponível por meio do Hugging Face. A proposta parece simples, mas muda a pergunta central dos testes: em vez de avaliar apenas se o agente respondeu bem ou usou a ferramenta correta, o ThinkingBox verifica o que realmente ficou registrado no banco de dados. E essa diferença pode separar uma demonstração convincente de um sistema confiável em produção.
ThinkingBox avalia o resultado deixado pelo agente
Imagine uma cliente esperando há quinze dias por um eletrodoméstico de US$ 745, preso em uma ocorrência de transporte. Um agente consulta o pedido, verifica o rastreamento, busca a política de reembolso, abre um chamado e registra o histórico. No fim, porém, encerra o ticket como resolvido, embora o status correto fosse “em espera”, aguardando a resolução do problema com a transportadora.
Para um avaliador interessado apenas nas chamadas de ferramenta, o atendimento pode parecer bem-sucedido. Para o banco de dados, não. O ThinkingBox considera o estado final dos registros e os efeitos colaterais produzidos durante a execução. Assim, uma resposta educada não compensa uma alteração incorreta, um efeito extra ou uma ação obrigatória que deixou de ser realizada.
Essa abordagem é especialmente relevante para agentes que passam nos testes, mas falham em produção. Em ambos os casos, a questão é parecida: o sistema parece funcionar quando observado superficialmente, mas não entrega o resultado operacional esperado.
Um agente acertar uma vez não significa que ele seja confiável
O ThinkingBox-Bench reúne 507 tarefas empresariais distribuídas entre varejo, seguros automotivos, viagens, neobancos e consultoria. Cada tarefa é executada 20 vezes de forma independente, sempre com um ambiente inicial limpo.
Essa repetição permite separar três perguntas diferentes. O pass@1 indica a proporção de tentativas bem-sucedidas. O pass@20 mostra se uma tarefa foi resolvida pelo menos uma vez em vinte tentativas. Já o indicador observado de 20/20 conta quantas tarefas foram concluídas corretamente em todas as vinte execuções.
A diferença entre essas métricas é o ponto central do estudo. Um agente pode demonstrar que sabe realizar uma tarefa, mas ainda ser inconsistente demais para cuidar de registros reais sem supervisão. É a diferença entre “consegue fazer” e “podemos depender dele”.
Os resultados mostram uma distância entre capacidade e consistência
Na análise apresentada, 12 modelos foram avaliados em uma ablação com 121.680 tentativas válidas. Destas, 79.853 falharam nas verificações executáveis. Em 67,24% dos casos malsucedidos, o agente terminou sem erro aparente, usou uma ferramenta que alterava o estado e não informou uma falha final. Ainda assim, a verificação encontrou problemas no resultado.
Entre as falhas identificadas, 77,61% envolveram valores incorretos em campos, 43,30% produziram efeitos extras não desejados e 25,36% deixaram de executar efeitos obrigatórios. As categorias podem se sobrepor, mas o padrão é claro: uma execução limpa não garante que o sistema tenha feito o que deveria.
O estudo também mostra que cobertura e consistência podem apontar para direções diferentes. O Kimi-K3 resolveu pelo menos uma vez 93,89% das tarefas, mas concluiu todas as 20 tentativas em apenas 13,41% delas. O Claude Opus 5, por outro lado, resolveu pelo menos uma vez 79,09% das tarefas, mas alcançou 20/20 em 47,53% dos casos.
Isso não transforma um modelo no vencedor absoluto. Significa que a escolha depende do tipo de operação. Para uma tarefa exploratória, a capacidade de acertar em alguma tentativa pode ser suficiente. Para atualizar registros financeiros, pedidos ou apólices, a consistência tende a ser muito mais importante.
O custo de uma resposta certa pode esconder o custo da confiabilidade
O ThinkingBox também compara custo e desempenho. Para isso, o estudo calcula o custo estimado por tentativa bem-sucedida e, separadamente, o custo por tarefa confiável — aquela que passou nas 20 execuções.
Essa distinção muda a leitura dos números. Um modelo barato pode apresentar bom custo por resposta correta porque acerta com frequência, mas se falhar em várias repetições talvez seja caro quando a empresa precisar de supervisão, reprocessamento ou correção manual.
Segundo os dados publicados, o GPT-5.4 teve o menor custo estimado por tarefa confiável entre os modelos com tarefas aprovadas em todas as 20 tentativas, com US$ 6,80 por tarefa confiável. O GPT-6 Astra ficou em US$ 7,45, enquanto o Claude Opus 5.5 chegou a US$ 7,80. Esses valores são índices comparativos baseados no experimento, não uma previsão de uma conta real de produção.
O principal problema aparece no uso das ferramentas
As assinaturas de falha ajudam a indicar onde os agentes mais tropeçam. Cerca de 79,9% das falhas foram classificadas como problemas de uso de ferramentas. Em seguida apareceram atualizações incorretas de estado, com 10,3%, resoluções incompletas para o usuário, com 7%, e ausência de uma ação que alterasse o estado, com 2,9%.
Na prática, muitos agentes parecem chegar perto da solução, mas não conseguem se recuperar de erros de ferramenta, pré-condições não atendidas ou consultas vazias. Isso sugere que melhorar o tratamento de erros e a lógica de novas tentativas pode ser tão importante quanto trocar o modelo de linguagem.
Para empresas, há uma consequência direta: o sistema não deveria confiar apenas no resumo final produzido pelo agente. É mais seguro verificar o estado dos registros antes de confirmar uma operação, limitar as ferramentas disponíveis ao necessário e exigir aprovação humana para mudanças difíceis de reverter.
Como o benchmark funciona
O ThinkingBox combina um ambiente de execução, chamado ThinkingBox, com o conjunto de tarefas ThinkingBox-Bench. Cada cenário define o estado inicial do sistema, o objetivo do usuário, as ferramentas MCP disponíveis, as políticas do domínio e as verificações que serão aplicadas ao estado final.
As tentativas ocorrem em sessões isoladas. O banco de dados é reinicializado, e duas execuções da mesma tarefa não compartilham registros ou estados armazenados em cache. Ao final, o sistema identifica o que realmente mudou e compara os efeitos com o resultado esperado.
A maior parte das tarefas é avaliada diretamente pelo estado do sistema: 477 das 507 tarefas usam essa abordagem. Outras 30 também incluem critérios binários relacionados à resposta, necessários quando o requisito não pode ser representado por um valor claro no banco de dados.
ThinkingBox já pode ser executado pelo OpenEnv
A Microsoft e a Hugging Face disponibilizaram o ThinkingBox por meio da interface OpenEnv. O ambiente e o conjunto de dados podem ser usados para testar agentes em tarefas empresariais simuladas, com resultados binários de aprovação ou reprovação.
A configuração exige Linux ou WSL, Python 3.11 ou superior, uv, Docker, uma cópia da versão indicada dos dados do ThinkingBox e endpoints para o agente, o usuário simulado e o avaliador. Também é necessário iniciar componentes como o Typesense, os servidores MCP e o servidor OpenEnv.
O projeto foi desenhado para avaliação, mas a mesma interface pode ser usada em fluxos de treinamento separados do benchmark. Como os cenários públicos são reconstruções sintéticas, os resultados não representam clientes ou operações reais. Eles servem para testar se um agente consegue transformar instruções em mudanças corretas e repetíveis em sistemas estruturados.
O que o ThinkingBox muda na avaliação de agentes
A principal contribuição do ThinkingBox não é apenas criar mais um ranking de modelos. O valor está em deslocar a avaliação da aparência da execução para o resultado verificável.
Um agente pode falar como se tivesse concluído uma tarefa, produzir chamadas de ferramenta válidas e terminar sem mensagens de erro. Mesmo assim, o registro final pode estar errado. Por isso, avaliações mais úteis precisam observar o estado produzido, repetir as tarefas e informar claramente se estão medindo a melhor tentativa ou a consistência em todas as tentativas.
Para quem desenvolve agentes empresariais, a lição é prática: não basta perguntar se o modelo sabe fazer uma tarefa. É preciso verificar se ele a conclui corretamente, se repete o resultado com estabilidade e se consegue se recuperar quando uma ferramenta falha. O banco de dados, nesse caso, é menos impressionável do que a resposta final — e provavelmente está mais perto da verdade.
