Un agente AI prende l’ordine, controlla il magazzino, aggiorna il CRM e manda la conferma. Funziona. Il giorno dopo, stessa identica richiesta, l’agente salta un passaggio e scrive un dato sbagliato. Nessuno ha toccato niente: stesso prompt, stesso modello, stessa temperatura. È l’esperienza più comune, e più frustrante, di chi porta un agente fuori dalla demo, e ha un nome preciso: la consistenza degli agenti AI in produzione è una proprietà diversa dall’accuratezza media, e i benchmark tradizionali la nascondono. IBM Research l’ha appena misurata su AppWorld e il numero è questo: 77,4% di successo medio, 53,0% se il compito deve riuscire cinque volte su cinque. Ventiquattro punti di scarto fra quello che il benchmark dichiara e quello che l’utente sperimenta, ed è lì che si fermano tanti progetti subito dopo il POC.
Il problema riguarda sempre più aziende: la sola Anthropic dichiara 30.000 agenti in produzione.
Che contino il modello quanto il design attorno a lui lo mostra anche il caso LangChain, raccontato nella nostra analisi sull’agente AI per il marketing in azienda.
E il problema non riguarda solo la varianza degli agenti: anche i test su cui si misurano vanno verificati, come mostra l’audit che ha trovato 29 test rotti e punteggi gonfiati sui benchmark AI affidabili.
In questo articolo scoprirai:
- Cosa sono gli agenti in ambito AI e perché la media nasconde i fallimenti
- La consistenza degli agenti AI in produzione: i numeri IBM su AppWorld
- Perché lo stesso agente AI dà risultati diversi: le cause della varianza
- Come si costruisce un agente AI che regge la ripetizione
- Agenti AI in azienda dopo il POC: monitoring, versioning e regression test
Cosa sono gli agenti in ambito AI e perché la media nasconde i fallimenti
Un agente, in ambito AI, non è un chatbot: è un modello linguistico messo dentro un ciclo, con il permesso di chiamare strumenti esterni, API, database, browser, righe di codice, e di decidere da solo il passo successivo in base a quello che gli torna indietro. Il paradigma di riferimento è ReAct, in cui il modello alterna ragionamento e azione fino a chiudere il compito. Ogni passo è una decisione, e ogni decisione è un punto in cui le cose possono andare diversamente.
Il browser è ormai uno di questi strumenti a tutti gli effetti: con Safari MCP gli agenti AI controllano il browser direttamente, e ogni clic diventa un altro passo in cui l’esito può cambiare.
Cosa può succedere quando una di queste decisioni autonome esce dal perimetro lo mostra il caso in cui Mythos 5 ha caricato malware su PyPI.
Per misurare questi sistemi la ricerca usa banchi di prova come AppWorld, un ambiente eseguibile con 9 applicazioni quotidiane raggiungibili tramite 457 API e circa 100 utenti fittizi, su cui sono definiti 750 task autonomi valutati con unit test sullo stato finale, come documentato nel paper originale di AppWorld. Su quel banco, ricorda la scheda ufficiale del benchmark, GPT-4o risolve circa il 49% dei task normali e il 30% di quelli difficili.
Mean@k e Pass^k: le due metriche degli agenti AI a confronto
Il problema è come si legge quel numero. La metrica standard è il Mean@k: si esegue il task k volte e si fa la media dei successi. È una misura ottimista, perché premia un agente che azzecca quattro run su cinque esattamente quanto ne premierebbe uno che le azzecca tutte e cinque, distribuendo il fallimento su compiti diversi. Ma l’utente non vive la media: vive la singola esecuzione. Se ripete la stessa richiesta due volte e ottiene due risultati diversi, l’accuratezza media del sistema non lo consola. Serve una metrica pessimista, che conti solo i task riusciti in tutte le ripetizioni.
La consistenza degli agenti AI in produzione: i numeri IBM su AppWorld
Quella metrica esiste e si chiama Pass^k: la percentuale di task completati correttamente in tutti i k run. IBM Research l’ha applicata a un agente ReAct con GPT-4.1 su AppWorld e il risultato è lo scarto che dà il titolo a tutta la questione. Nel report pubblicato da IBM Research, l’agente registra un Mean@5 del 77,4% ma un Pass^5 del 53,0%: 24,4 punti percentuali di differenza fra quello che il benchmark dichiara e quello che l’utente sperimenta ripetendo la richiesta.
Tradotto: su cento compiti che l’agente sembra saper fare quattro volte su cinque, quasi la metà cambia esito da un’esecuzione all’altra. Il dettaglio decisivo è che questo accade a temperatura 0, cioè con decodifica greedy, la configurazione che in teoria dovrebbe essere deterministica. E accade ai modelli grandi: la consistenza, scrivono gli autori, è ortogonale alla capacità, un modello più potente non chiude automaticamente il divario.
ALTK-Evolve: come IBM dimezza il gap di consistenza degli agenti AI
La seconda metà del lavoro è il rimedio. Il sistema ALTK-Evolve genera «consistency guidelines», istruzioni specifiche ricavate dai punti instabili e riusate nelle esecuzioni successive. Sui 168 task dello split test_normal il gap si dimezza da 24,4 a 12,0 punti percentuali, con il Pass^5 che sale dal 53,0% al 69,0%, più 16 punti, e il Mean@5 che invece di degradarsi migliora leggermente, dal 77,4% all’81,0%. Il guadagno è più forte dove il compito è più difficile: +22,9 punti sui task medi e +14,3 sui difficili. E le linee guida non restano incollate al caso da cui nascono: il technical report firmato da Duesterwald, Elder, Ngweta, Ubaru e Zimon riporta +13,0 punti di Pass^5 anche su task diversi ma affini.
Perché lo stesso agente AI dà risultati diversi: le cause della varianza
Le cause si sommano su tre piani, e conviene tenerle distinte perché si curano in modi diversi.
Il primo piano è l’inferenza. A temperatura 0 il modello dovrebbe scegliere sempre il token più probabile, eppure non lo fa: campionando 1.000 completamenti a temperatura 0 si ottengono 80 output distinti, con la divergenza che compare al token 103, come mostra l’analisi di Thinking Machines Lab sul non determinismo dell’inferenza. La causa non è tanto la non associatività della virgola mobile quanto la mancanza di invarianza rispetto al batch: la tua richiesta viene servita insieme a quelle di altri, e al variare della dimensione del lotto cambia l’ordine delle riduzioni interne. Si può correggere con kernel batch-invarianti, ma si paga: nel loro test il tempo passa da 26 a 42 secondi.
Il secondo piano è l’uso degli strumenti. Un agente che chiama API non ha garanzie di idempotenza: un timeout, un ordinamento diverso dei risultati, un rate limit che scatta a metà cambiano il contesto su cui il modello decide il passo dopo. Il terzo piano sono i dati: il magazzino di oggi non è quello di ieri, e un agente robusto sulla base di ieri può inciampare su un campo vuoto comparso stanotte.
Quali sono alcuni esempi reali di agenti AI che perdono consistenza
L’esempio portato da IBM è istruttivo proprio perché è banale: un agente che deve contare caselle spuntate ottiene risultati diversi a seconda che usi una regex ancorata a inizio riga o un conteggio di sottostringhe. Su cinque run paralleli, come si legge nel report di IBM Research, il comportamento si spacca 3 a 2. Non è un errore di ragionamento: è un punto di decisione instabile, dove due implementazioni quasi equivalenti hanno probabilità troppo vicine. È lì che nasce il gap, non nei compiti difficili.
Come si costruisce un agente AI che regge la ripetizione
La risposta ingenua sarebbe eseguire ogni task cinque volte e vedere cosa cambia. È esatta e impraticabile: moltiplica i costi per cinque e richiede di riportare l’ambiente allo stato iniziale a ogni giro, cosa impossibile quando l’agente scrive su sistemi reali.
L’approccio del Consistency Analyzer di IBM è più economico. Prende una sola traccia di esecuzione già avvenuta e, per ogni punto di decisione, ricampiona cinque completamenti alternativi: non riesegue il task end-to-end, non tocca l’ambiente, non ha bisogno della soluzione corretta né di accedere ai logit del modello. Il risultato è una pagella dei punti «flip-prone», cioè quelli dove l’agente potrebbe girare diversamente. Il secondo stadio trasforma ogni punto segnalato in una linea guida testuale riusabile, che finisce nella memoria episodica dell’agente. Il codice è pubblico con licenza Apache 2.0 sul repository AgentToolkit/Evolve.
La direzione è la stessa che indicano i manuali di progettazione: tenere l’architettura semplice, rendere espliciti i passi di pianificazione e curare l’interfaccia fra agente e strumenti con la stessa attenzione che si dedica a un’interfaccia umana, provando ogni tool su molti input prima del rilascio, come raccomanda la guida di Anthropic sugli agenti efficaci. Buona parte della varianza non nasce dal modello: nasce da una descrizione ambigua di uno strumento.
Qual è il miglior agente AI quando il criterio è la consistenza
Non esiste una risposta valida in generale, e i numeri lo mostrano bene: il gap di 24,4 punti è di GPT-4.1, cioè di un modello di frontiera. IBM ha ripetuto il test su gpt-oss-120b ottenendo, secondo il technical report ALTK-Evolve, +6,0 punti di Pass^5 sugli stessi task e +8,7 su task affini: l’intervento funziona su modelli diversi, e nessuno dei due parte già consistente. Il miglior agente, in produzione, è quello di cui conosci il Pass^k sui tuoi task, non quello con il punteggio più alto su un benchmark pubblico.
Agenti AI in azienda dopo il POC: monitoring, versioning e regression test
Qui il discorso smette di essere accademico. Un’azienda che mette un agente su processi mission-critical, riconciliazioni contabili, screening di contratti, adempimenti di compliance, non può accettare che il 47% dei task cambi esito da una settimana all’altra. Il punto non è avere il modello migliore: è avere un metodo.
Tre pratiche fanno la differenza, e sono le stesse del software tradizionale, tradotte. Monitoring: si registrano le tracce di esecuzione, non solo l’output finale, perché il punto in cui l’agente ha deviato è a metà del ragionamento. Versioning: prompt, descrizioni degli strumenti e linee guida sono artefatti versionati come il codice, altrimenti nessuno sa dire cosa è cambiato fra ieri e oggi. Regression test: una suite di task rappresentativi che gira a ogni modifica e misura il Pass^k, non la media, perché è la media a nascondere il problema.
È esattamente la ragione per cui in MIMIR l’onboarding è assistito e non un self-service. Consegnare un agente che funziona in demo è la parte facile; la parte che decide se il progetto sopravvive al terzo mese è definire insieme al cliente quali task vanno nella suite di regressione, quale soglia di consistenza è accettabile per quel processo, come si versiona una modifica e chi guarda i log quando qualcosa gira storto. È lavoro di mestiere, non una funzionalità del prodotto: per questo accanto all’agente offriamo un servizio, con persone che seguono l’installazione e restano quando l’agente entra davvero nei processi.
Quanto costa al mese un agente AI se si conta anche il gap di consistenza
Il costo visibile è quello dei token e dell’infrastruttura, e dipende da volumi e modello scelto. Il costo invisibile è l’inconsistenza: ogni esecuzione che cambia esito genera una verifica umana, una correzione a valle o un errore che qualcuno dovrà scoprire più tardi. Un agente al 77% di media ma al 53% di consistenza richiede supervisione su quasi metà dei casi, e quella supervisione è il vero costo mensile. Ridurre il gap non è un esercizio di eleganza: è ciò che rende il conto economico sostenibile.
Se stai valutando un agente AI per un processo aziendale reale, o ne hai già uno che funziona a intermittenza dopo il POC, parlarne con chi lo mette in produzione tutti i giorni fa risparmiare mesi. Puoi scriverci da mimir.bot per una consulenza: guardiamo insieme i tuoi task, misuriamo dove l’agente perde consistenza e definiamo il percorso di onboarding più sensato per la tua organizzazione.
Fonti:
- report pubblicato da IBM Research
- technical report ALTK-Evolve (Duesterwald, Elder, Ngweta, Ubaru, Zimon)
- repository AgentToolkit/Evolve, licenza Apache 2.0
- paper originale di AppWorld
- scheda ufficiale del benchmark AppWorld
- Thinking Machines Lab sul non determinismo dell’inferenza
- la guida di Anthropic sugli agenti efficaci
Domande frequenti
Quali sono i vantaggi degli agenti AI per le aziende?
Un agente AI esegue processi che richiedono più passaggi e più sistemi, leggere un ordine, controllare un magazzino, aggiornare un CRM, senza che un umano faccia da collante fra un'applicazione e l'altra. Il vantaggio si vede sui processi ripetitivi e ad alto volume. Vale però solo se il risultato è stabile: un agente che cambia esito fra un'esecuzione e l'altra richiede supervisione, e la supervisione erode il risparmio.
Cosa possono fare gli agenti AI?
Possono chiamare API, interrogare database, navigare pagine web ed eseguire codice, decidendo da soli il passo successivo in base al risultato del precedente. Il benchmark AppWorld li mette alla prova su 750 task in 9 applicazioni quotidiane raggiungibili tramite 457 API. I modelli migliori risolvono circa la metà dei task normali, molto meno su quelli difficili.
Qual è la differenza fra Mean@k e Pass^k?
Mean@k è la media dei successi su k esecuzioni dello stesso task: è una misura ottimista, perché un fallimento sparso su compiti diversi si diluisce. Pass^k conta solo i task riusciti in tutte e k le ripetizioni. La seconda descrive ciò che vive l'utente, che non sperimenta una media ma una singola esecuzione per volta.
Come utilizzare agenti AI in un processo aziendale critico?
Servono tre pratiche prese dal software tradizionale: registrare le tracce di esecuzione e non solo l'output finale, versionare prompt e descrizioni degli strumenti come si versiona il codice, e far girare una suite di regressione a ogni modifica. La suite deve misurare il Pass^k sui task reali dell'azienda, non l'accuratezza media.
