65% uma vez, 25% sempre: a Microsoft correu 507 tarefas de agente vinte vezes cada
By Surya Pratap
27 de agosto de 2026
12 min de leitura
IA e tecnologia
27 de agosto de 2026
12 min de leitura
O número da demonstração e o número do produtoHover to exploreA Microsoft publicou na semana passada um benchmark com o título menos ambíguo de que há memória: «One Success Isn't Reliability», ou seja, um sucesso não é fiabilidade.
O artigo (arXiv 2608.19741, 20 de agosto de 2026) apresenta o Thinkingbox, um sandbox de código aberto para agentes que trabalham em fluxos de negócio com estado, mais um benchmark de 507 tarefas que o acompanha. Ambos estão no GitHub.
O resultado de destaque são dois números do mesmo modelo sobre as mesmas tarefas:
65,36% de pass@1. 25,25% de pass^20.
Certo à primeira tentativa cerca de duas em cada três vezes. Certo nas vinte tentativas cerca de uma em cada quatro. Se alguma vez demonstrou um agente com sucesso e depois o viu descarrilar à frente de um cliente, essa distância é a explicação completa, e alguém finalmente a mediu.
Quase todos os benchmarks de agentes avaliam a transcrição. O agente chamou as ferramentas certas? Disse que tinha terminado? A mensagem final parecia correta?
O Thinkingbox avalia a base de dados.
Como corre de facto uma tarefa do Thinkingbox
Cinco elementos combinados que costumam ser testados em separado
Depois repete tudo vinte vezes, repondo o backend entre execuções.
Esse desenho é o contributo. Tudo o que há de interessante nos resultados decorre dessas duas escolhas: verificar o estado e repetir.
As 507 tarefas abrangem cinco domínios: retalho e comércio eletrónico (98 tarefas), viagens e hotelaria (104), seguros automóveis (100), TI interna de um neobanco (104) e apoio de TI e recursos humanos em consultoria (101).
Correram mais de uma dúzia de modelos, proprietários e de pesos abertos. A distribuição publicada:
O que importa olhar é a proporção, não a classificação. Ao longo da tabela, o pass^20 fica algures entre um terço e um décimo do pass@1. Seja qual for o número de exatidão que tenha visto citado para um agente, o número que os seus utilizadores experimentam com uso repetido é significativamente mais baixo, e este é o primeiro benchmark que vi a quantificar esse desconto.
Esta é a conclusão que eu punha num diapositivo.
O melhor modelo acertou pelo menos uma vez em cerca de nove em cada dez tarefas. Acertou nas vinte execuções em cerca de uma em cada quatro.
Ou seja, a população interessante não são nem as tarefas fiáveis nem as impossíveis. São as 334 tarefas — dois terços do benchmark — cujo resultado oscilava entre tentativas.
Porque é nessa faixa que a credibilidade morre
Uma tarefa que funciona sempre é uma funcionalidade. Uma tarefa que nunca funciona é uma limitação conhecida que se contorna no desenho. Uma tarefa que funciona quase sempre é aquela que vai demonstrar com sucesso, lançar com confiança e depois explicar a um cliente. Dois terços dos fluxos de negócio realistas caem nessa faixa para o melhor modelo disponível, o que significa que o resultado por omissão de construir uma demonstração é uma demonstração que funciona — e que não lhe diz quase nada.
Se alguma vez se perguntou porque os pilotos de agentes convertem tão mal para produção, esta é uma resposta mecânica. Os pilotos são curtos, supervisionados e de amostra pequena. Amostram as boas execuções.
Agora a parte com a consequência de engenharia mais direta.
80,88% das tentativas falhadas terminaram de forma limpa. A conversa terminou normalmente. As chamadas a ferramentas que alteram o estado executaram e devolveram sucesso. Nada rebentou. O estado final estava, simplesmente, errado.
A conclusão do próprio artigo é seca: os sinais ao nível da resposta e da chamada a ferramentas não são bons indicadores da conclusão da tarefa de ponta a ponta.
Desagregados, os modos de falha dominantes foram:
Leia os dois em conjunto e cai um pressuposto comum. A observabilidade de agentes da maioria das equipas consiste em seguir chamadas a ferramentas e inspecionar transcrições. Contra esta distribuição de falhas, isso apanha aproximadamente uma em cada cinco. As outras quatro são exatamente iguais aos sucessos — o mesmo fecho limpo, as mesmas chamadas válidas — e a única coisa que as distingue é o estado da base de dados no fim.
Esta é também a resposta honesta ao inquérito que tratámos ontem, em que 85,5% dos engenheiros diziam confiar no que o agente produz. Claro que confiam. Quatro em cada cinco falhas são invisíveis de onde eles estão.
O sucesso variou imenso por domínio: cerca de 52% de sucesso médio no retalho, contra cerca de 23% nos seguros automóveis.
É mais do dobro de diferença com os mesmos modelos e o mesmo arnês, e merece ser compreendido em vez de diluído numa média. Os fluxos de retalho tendem a ser mais curtos, mais tolerantes e menos sujeitos a política. Os de seguros são longos, condicionados por regras e cheios de passos em que um valor errado no início envenena em silêncio tudo o que vem a seguir.
A tradução prática para um fundador: o número do seu domínio não é o número do título. Se aquilo que automatiza se parece com um processo de sinistros — de vários passos, com barreiras de política, carregado de estado —, a mensagem do benchmark é que deve esperar a parte de baixo do intervalo, e que lhe convém descobri-lo antes do seu cliente.
Três ressalvas, porque um benchmark impressionante convida a ler demais.
Os modelos testados não são a fronteira atual. A tabela assenta no GPT-5.4 e na geração Claude 4.6. A fronteira mudou desde então: o GPT-5.6 e o Claude Opus 5 chegaram depois deste trabalho. Os números absolutos já são históricos. Se a proporção entre pass@1 e pass^20 melhora com modelos mais recentes é a pergunta verdadeiramente em aberto, e nada aqui lhe responde.
A posição no benchmark não é uma classificação de capacidade. O Claude Opus 4.6 pontua aqui abaixo do Claude Sonnet 4.6 (37,91% contra 58,45% de pass@1), o que deve deixar qualquer pessoa cautelosa antes de ler isto como uma tabela classificativa. O encaixe com o arnês, o formato do prompt e as convenções de chamada a ferramentas mexem nestes números. Tome a forma da conclusão como sólida e a ordem como própria deste arranjo.
É uma simulação. Backends isolados e um utilizador simulado são imensamente melhores do que casos de teste estáticos, e continuam a não ser o seu sistema de produção com os seus dados e os seus utilizadores. O sentido do erro é desconhecido: os fluxos reais podem ser mais fáceis porque os utilizadores esclarecem, ou mais difíceis porque a realidade é mais suja do que um simulador.
O terceiro cartão é o de melhor retorno. Não é um problema de modelo e não precisa de um prompt melhor. Se uma chamada a uma ferramenta falha e a sua orquestração deixa o agente continuar, construiu uma máquina de produzir respostas erradas com confiança — e o benchmark diz que isso explica três quartos do que corre mal.
A Microsoft construiu o benchmark de agentes que avalia o que interessa — o que mudou no sistema — e depois correu tudo vinte vezes para ver se se aguenta. Ambas as escolhas parecem óbvias em retrospetiva e nenhuma era o habitual.
Os resultados: o melhor modelo disponível na altura acertou à primeira em 65,36% das vezes e acertou sempre em 25,25%. Dois terços das tarefas oscilaram entre execuções. Quatro em cada cinco falhas terminaram de forma limpa, com chamadas válidas, e pareceriam sucessos em qualquer monitorização baseada em transcrições que tenha instalada.
Nada disto significa que os agentes não funcionem. Significa que uma demonstração não é prova, que a exatidão numa só execução era a métrica errada que se andava a citar, e que a observabilidade que a maioria das equipas construiu não consegue ver as falhas que realmente acontecem.
A solução não é exótica. Corra vinte vezes. Verifique a base de dados. Pare o agente quando uma ferramenta disser que não.
Fontes: arXiv 2608.19741, «One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows» · microsoft/thinkingbox no GitHub · As notas por modelo, a repartição das 507 tarefas, o valor de 80,88% de terminação limpa e as médias por domínio são os publicados no artigo e na análise que o acompanha; as ressalvas da secção 6 são minhas.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
