A resposta direta: uma demonstração bem-sucedida não prova nada sobre a confiabilidade de um agente de IA, porque a pergunta certa não é se ele concluiu a tarefa uma vez, mas se ele a conclui corretamente todas as vezes. Em um estudo que a Microsoft publicou em 20 de agosto de 2026, o modelo mais forte atingiu 65,36% quando cada tarefa foi executada uma vez, mas passou nas vinte tentativas em apenas 25,25% das tarefas. Essa diferença é exatamente a distância entre um agente que impressiona você em uma reunião e um agente a quem você pode confiar os dados dos seus clientes.

O que a Microsoft realmente construiu

A ferramenta se chama Thinkingbox, um ambiente de testes de código aberto lançado sob a licença MIT no GitHub. A ideia é simples e engenhosa: em vez de conectar as ferramentas diretamente ao agente, você as define como servidores compatíveis com MCP, executa o agente dentro de uma sessão isolada com seu próprio banco de dados de apoio e registra o rastro completo da execução.

O ponto essencial está na forma de avaliar. O framework não lê o que o agente disse que fez; ele inspeciona o que realmente mudou no banco de dados quando a tarefa terminou. Essa distinção não é um detalhe técnico. Os agentes são muito bons em escrever um resumo convincente de um trabalho que nunca aconteceu, e qualquer avaliação baseada na transcrição da conversa mede a qualidade do texto, não a qualidade da execução.

Sobre esse ambiente, a equipe construiu um benchmark chamado Thinkingbox-bench, com 507 fluxos de trabalho condicionados por políticas em cinco domínios: varejo e e-commerce, viagens e hotelaria, seguro de automóveis, suporte interno de TI em um banco digital e suporte de TI e RH em uma consultoria. Cada tarefa foi executada vinte vezes em doze modelos, tanto proprietários quanto de pesos abertos.

Por que esse número importa para o dono de um negócio

Imagine que você entrega a um agente a tarefa de processar os pedidos de devolução da sua loja. Uma taxa de sucesso de 65% parece aceitável no papel. Na operação, significa que um terço dos pedidos termina com um resultado errado: um reembolso emitido duas vezes, um pedido fechado sem repor o estoque ou uma exceção concedida a um cliente a quem sua política não a permite.

Pior ainda, as falhas deste estudo não foram travamentos óbvios. O artigo descreve explicitamente que muitas falhas terminaram de forma limpa e seguiram passos que pareciam válidos, enquanto o estado final do sistema continuava errado. Nenhuma mensagem de erro, nenhuma interrupção, nada acendendo em um painel de monitoramento. Apenas um log que parece normal e dados que, silenciosamente, ficaram incorretos.

Uma falha que para o sistema é incômoda, mas visível. Uma falha que conclui o fluxo e deixa seus dados errados é a que realmente custa caro, porque você só a descobre um mês depois, durante a conciliação.

Isso também explica uma fonte comum de decepção. O piloto é aprovado porque executou a tarefa uma vez com dados limpos. A operação real é a mesma tarefa milhares de vezes sobre um estado acumulado e bagunçado, e é exatamente aí que a diferença entre 65% e 25% aparece.

O que fazer antes de adotar qualquer agente

  • Exija execuções repetidas, não uma única demonstração. Faça do seu critério de aceitação vinte execuções consecutivas da mesma tarefa com os mesmos dados. Um fornecedor que se recusa está dizendo algo a você.
  • Meça o estado dos dados, não o texto da resposta. Defina com antecedência como o registro no seu banco de dados deve ficar após a tarefa e compare a realidade com isso. Não se contente em ler o resumo do próprio agente.
  • Teste políticas, não apenas tarefas fáceis. A maior parte do seu trabalho não é livre; ela é limitada por regras: prazos de devolução, limites de crédito, exceções para clientes prioritários. Um agente que tem sucesso sem restrições pode desmoronar diante da primeira condição real.
  • Monte o conjunto de testes com seus próprios casos. Pegue vinte casos reais dos últimos meses, incluindo os estranhos que confundiram sua equipe, e transforme-os em uma bateria fixa que você executa com qualquer modelo antes de adotá-lo e após cada atualização.
  • Conceda autoridade em etapas. Comece com um agente que propõe, mas não executa, depois deixe-o realizar operações de baixo impacto e então amplie seu escopo à medida que um histórico real de medições se acumula. A autoridade deve ser conquistada com dados, não com impressões.

Como lidamos com isso na Origami

Quando construímos um sistema que inclui um agente de IA, tratamos o agente como qualquer outro componente de software: ele recebe uma bateria de testes automatizados, verificações que inspecionam o estado do banco de dados após cada operação e um ponto claro de transferência para um humano quando um limite de confiança é ultrapassado. O modelo em si continua sendo uma configuração substituível, e não algo soldado ao código, porque o melhor modelo de hoje pode não ser o melhor daqui a três meses.

A conclusão que vale tirar deste estudo não é que os agentes sejam inutilizáveis. É que a régua com que os avaliávamos estava errada. Os agentes de hoje são ferramentas poderosas dentro de um escopo bem definido e medido continuamente, e muito fracos quando um processo sensível é entregue a eles com base em uma demonstração convincente. A diferença não está no modelo; está na disciplina de engenharia ao redor dele.

Fontes