L’agente dice «fatto». Il database non è d’accordo

AI / AGENTI / AFFIDABILITÀ

Un agente AI può eseguire nove chiamate tool corrette, non ricevere errori, chiudere la conversazione con sicurezza e avere comunque lasciato il sistema nello stato sbagliato. È una frase che dovrebbe stare appesa sopra ogni dashboard dove un workflow agentico viene giudicato dalla scritta verde «completed».

Il problema non è nuovo. È solo diventato molto più visibile con ThinkingBox-Bench v1.0, il benchmark pubblicato da Microsoft e Hugging Face per valutare agenti che lavorano dentro processi aziendali stateful. Qui non basta che il modello dica di aver finito, né che la sequenza delle tool call sembri plausibile. A decidere se il task è riuscito è soprattutto ciò che resta nel backend.

La risposta finale di un agente è una dichiarazione. Lo stato del sistema è la prova.

Il benchmark che guarda dopo l’agente

ThinkingBox-Bench contiene 507 task eseguibili distribuiti in cinque domini: retail ed e-commerce, viaggi e hospitality, assicurazioni auto, supporto di una neobank e attività IT/HR in consulenza. Ogni tentativo parte da un ambiente pulito e isolato, con uno stato iniziale noto, un insieme controllato di tool e un utente simulato che può fornire informazioni solo quando l’agente le chiede.

La differenza importante è nel giudice. L’agente vede conversazione e strumenti; il valutatore conserva una vista separata dello stato e, a fine esecuzione, confronta database ed effetti prodotti con il risultato atteso. Il dataset ufficiale chiarisce anche un dettaglio interessante: lo stato finale atteso non è semplicemente una fotografia precalcolata. Il runtime ricostruisce il golden state applicando le interazioni attese sulla stessa implementazione dei tool, poi confronta hash stabili dello stato.

È un cambio di prospettiva più importante di quanto sembri. Molti sistemi di valutazione si fermano a ciò che l’agente ha detto o alla correttezza formale delle chiamate. Ma un CRM non vive nella trascrizione. Un ordine non è rimborsato perché il modello ha scritto «rimborso completato». Un ticket non è in attesa perché l’agente ha usato il verbo giusto. Conta il record che rimane quando la conversazione è finita.

Quando «nessun errore» non significa «task riuscito»

Il joint post Microsoft/Hugging Face porta un esempio quasi didattico. Un agente gestisce il caso di un elettrodomestico in ritardo: recupera ordine e tracking, consulta profilo e policy, verifica i ticket, ne apre uno, documenta il caso. Nove tool call. Nessun disastro apparente. Poi chiude il ticket come risolto, anche se l’eccezione del corriere è ancora aperta e lo stato richiesto era hold.

Questo tipo di errore è esattamente quello che una valutazione centrata sulla traiettoria rischia di perdonare. Nell’ablazione descritta dagli autori, su 121.680 trial validi di 12 modelli, 79.853 non superano i check eseguibili. E il dato che interessa davvero è un altro: il 67,24% di quei fallimenti termina comunque in modo pulito, dopo almeno una mutazione dello stato e senza un errore finale del tool. Fra questi fallimenti, i controlli rilevano valori errati nel 77,61% dei casi, effetti extra nel 43,30% ed effetti richiesti mancanti nel 25,36%; le categorie possono sovrapporsi.

Tradotto in progettazione: l’assenza di eccezioni non è una condizione di successo. È solo l’assenza di eccezioni.

Una volta non basta: il problema della ripetibilità

ThinkingBox esegue ogni task 20 volte da uno stato pulito. Questo permette di separare tre domande che nelle demo vengono spesso mischiate. pass@1 misura quanto spesso un tentativo riesce. pass@20 misura su quanti task almeno uno dei venti tentativi trova una traiettoria corretta. Il successo osservato 20/20 misura invece quanti task vengono completati correttamente in tutte e venti le esecuzioni registrate.

La differenza non è accademica. Nei risultati pubblicati da Microsoft, GPT-5.4 guida il benchmark con il 65,36% pass@1. Arriva al 91,12% pass@20: su gran parte dei task, prima o poi, trova quindi una strada che funziona. Ma i task superati in tutte le 20 esecuzioni sono il 25,25%. È la distanza fra «può riuscirci» e «posso affidargli questo processo senza trattare ogni run come una scommessa».

Il retry aumenta la probabilità di vedere almeno un successo. Non trasforma automaticamente un comportamento instabile in un processo affidabile.

È un punto che si collega bene a un tema che ho già affrontato parlando di agenti AI che non si limitano più a conversare ma agiscono. Quando il software modifica sistemi reali, la domanda non può essere soltanto se il modello è abbastanza intelligente da trovare una soluzione. Serve capire quanto è ripetibile il comportamento e quali controlli impediscono a una run sbagliata di diventare un incidente.

Il collo di bottiglia spesso non è il ragionamento

Un altro risultato utile riguarda la natura dei fallimenti. Nel post Microsoft la classificazione delle trace fallite attribuisce in media il 77,5% dei casi al tool usage: errori dello strumento, precondizioni fallite o lookup senza risultato seguiti da un recupero inefficace. Un altro 12,1% riguarda modifiche di stato sbagliate; il 2,5% arriva al punto di non eseguire proprio la mutazione richiesta. Solo il 7,9% viene ricondotto alla qualità della risposta finale.

Quindi, prima di sostituire il modello con quello più grosso disponibile perché «l’agente sbaglia», varrebbe la pena guardare il loop. Capisce davvero l’esito di ogni tool? Distingue un errore transitorio da una precondizione non soddisfatta? Se una ricerca restituisce zero record, cambia strategia o continua come se avesse trovato ciò che cercava? Verifica la mutazione dopo averla richiesta?

È lo stesso errore concettuale che compare nei chatbot aziendali quando confondiamo autonomia tecnica e responsabilità del sistema: ci concentriamo sul testo perché è la parte che vediamo, mentre il rischio vero si sposta nelle capacità, nelle policy e negli effetti.

Un agente operativo ha bisogno di read-back, non di fiducia

La lezione più trasferibile di ThinkingBox non è copiare il benchmark in produzione. È copiare il principio di verifica. Se un agente modifica qualcosa di importante, il workflow dovrebbe possedere una definizione osservabile del risultato corretto e controllarla dopo la mutazione.

• Stato iniziale esplicito. Sapere da dove parte il task evita di confondere effetti precedenti con il lavoro della run corrente.
• Tool surface minima. Ogni capacità aggiuntiva aumenta lo spazio delle traiettorie e degli effetti indesiderati.
• Precondizioni verificabili. Un’azione dovrebbe fallire in modo leggibile quando il contesto non consente di eseguirla correttamente.
• Read-back dopo le mutazioni. Non basta ricevere HTTP 200: bisogna rileggere ciò che conta e confrontarlo con l’obiettivo.
• Completion report basato su evidenze. Il worker può spiegare che cosa ha fatto, ma il sistema deve poter verificare almeno le proprietà critiche in modo indipendente.

Questo approccio costa più di un prompt con scritto «verifica attentamente il risultato». Però sposta l’affidabilità dal comportamento sperato del modello all’architettura del processo. Ed è esattamente dove dovrebbe stare.

Il benchmark non dimostra che un modello è affidabile in assoluto

Serve anche una cautela. I 507 workflow sono ricostruzioni sintetiche di pattern aziendali, non una fotografia di tutte le applicazioni reali. Le percentuali pubblicate valgono per quella release, quei task, quelle configurazioni e quei modelli. Non autorizzano a dire che un modello con un certo pass@1 avrà la stessa probabilità di successo sul nostro ERP, né che venti run siano il numero magico per ogni processo.

Il valore sta nella domanda che il benchmark costringe a fare: che cosa stiamo misurando quando diciamo che un agente funziona? Se la risposta è «ha prodotto una buona frase finale», stiamo misurando un’interfaccia. Se la risposta è «ha chiamato i tool giusti», stiamo misurando una traiettoria. Se invece controlliamo lo stato terminale, gli effetti collaterali e la ripetibilità, cominciamo a misurare il lavoro.

La demo finisce quando l’agente dice done. Il sistema no

È facile costruire una demo convincente di un agente: una richiesta, qualche tool call, una risposta finale pulita. È molto più difficile costruire un sistema che sappia dimostrare di aver lasciato il mondo nel modo corretto, venti volte di seguito, senza effetti extra.

ThinkingBox rende questa differenza misurabile. Per chi costruisce agenti in produzione, però, la conclusione utile è più semplice del benchmark: non chiedere al componente che esegue il lavoro di essere anche l’unica autorità che certifica di averlo fatto bene. Il messaggio «completato» può restare. Ma dovrebbe arrivare dopo il read-back, non al posto del read-back.