ThinkingBox misura gli agenti sullo stato finale dei sistemi

Il 3 ottobre Microsoft e Hugging Face hanno pubblicato una nuova presentazione di ThinkingBox, un ambiente e benchmark per valutare agenti che lavorano su workflow aziendali con stato persistente. Il relativo paper, aggiornato il 1° ottobre, descrive 507 task in scenari come retail, assicurazioni auto, viaggi, neobank e supporto IT/HR.

Ogni task parte da uno stato iniziale definito, mette a disposizione strumenti compatibili con Model Context Protocol (MCP) e termina con check eseguibili sullo stato del backend. L'obiettivo non è stabilire se la risposta dell'agente sembra corretta, ma se database e modifiche prodotte corrispondono davvero al risultato richiesto.

L'esempio usato dagli autori riguarda un ticket di assistenza per una consegna bloccata. L'agente consulta ordine, tracking, profilo cliente e policy, apre il ticket e poi lo chiude come risolto. Il flusso appare ordinato, ma il corriere mantiene un'eccezione aperta: lo stato corretto del ticket avrebbe dovuto essere "hold", non "solved".

ThinkingBox tratta quindi la traiettoria dell'agente come una dichiarazione e lo stato finale come evidenza. Nei task con effetti strutturati, giudici deterministici confrontano ciò che è cambiato con lo stato atteso e rifiutano valori errati, azioni mancanti o modifiche aggiuntive non richieste.

I 507 task vengono ripetuti 20 volte da uno stato pulito. Il benchmark distingue il successo medio di una singola esecuzione, la capacità di risolvere un task almeno una volta e il numero di task completati correttamente in tutte e 20 le prove.

Questa distinzione cambia la lettura dei risultati. Nel report, Claude Opus 5.5 ottiene il 67,16% di pass@1 ma completa 241 task su 507 in tutte le 20 esecuzioni, il 47,53%. Kimi-K3 raggiunge almeno una volta 476 task su 507, ma ne completa solo 68 in tutte le 20 prove. Il benchmark non misura soltanto cosa un modello sa fare: misura quanto spesso lo stesso workflow resta corretto quando viene ripetuto.

In un'analisi comune a 12 modelli, gli autori riportano 121.680 trial validi. Di questi, 79.853 falliscono i check eseguibili. Il 67,24% dei fallimenti termina comunque normalmente, include almeno un'azione che modifica lo stato e non presenta un errore finale del tool.

Tra quei fallimenti, i check trovano valori di campo errati nel 77,61% dei casi, effetti aggiuntivi non richiesti nel 43,30% e azioni necessarie mancanti nel 25,36%; le categorie possono sovrapporsi. Un monitor che guarda soltanto eccezioni, tool call formalmente valide o il testo finale dell'agente può quindi classificare come riuscito un lavoro che il sistema di record mostra come incompleto o sbagliato.

Il punto utile per chi costruisce automazioni è separare l'esecuzione dalla verifica. Se un agente aggiorna CRM, ticketing, ordini o anagrafiche, il risultato può essere controllato leggendo lo stato autorevole dopo l'azione e confrontandolo con condizioni esplicite, invece di accettare come prova il messaggio finale del modello.

Gli autori suggeriscono anche di classificare gli errori di tool e sistema per applicare retry mirati, ridurre la superficie di strumenti al necessario e mantenere approvazione umana sulle modifiche difficili da invertire. ThinkingBox rende queste scelte misurabili perché ogni tentativo parte da uno stato isolato e restituisce effetti osservabili.

I 507 task modellano pattern aziendali, ma il post specifica che ogni workflow pubblico è una ricostruzione sintetica e non contiene clienti reali. Inoltre 477 task sono giudicati sullo stato, mentre 30 aggiungono una rubrica binaria sulla risposta quando un requisito non può essere espresso con un semplice valore nel database.

Il vantaggio è che ambiente, dataset e controlli sono ispezionabili. Il framework ThinkingBox è open source, il benchmark v1.0 è pubblicato separatamente e l'integrazione con OpenEnv permette di eseguire episodi e ottenere un esito pass/fail.

Per un'azienda questo non sostituisce una valutazione sui propri processi. Offre però un criterio concreto da trasferire nei test interni: definire prima lo stato finale corretto, poi verificare se l'agente lo raggiunge in modo ripetibile.