La risposta diretta: una demo riuscita non dimostra nulla sull'affidabilità di un agente IA, perché la domanda giusta non è se ha completato l'attività una volta, ma se la completa correttamente ogni volta. In uno studio pubblicato da Microsoft il 20 agosto 2026, il modello più forte ha ottenuto il 65,36% quando ogni attività veniva eseguita una volta, ma ha superato tutti e venti i tentativi solo nel 25,25% delle attività. Quel divario è esattamente la distanza tra un agente che ti impressiona in una riunione e un agente a cui puoi affidare i dati dei clienti.

Che cosa ha costruito davvero Microsoft

Lo strumento si chiama Thinkingbox, un ambiente di test open source rilasciato con licenza MIT su GitHub. L'idea è semplice e ingegnosa: invece di collegare gli strumenti direttamente all'agente, li definisci come server compatibili con MCP, esegui l'agente all'interno di una sessione isolata con il proprio database di supporto e registri la traccia completa dell'esecuzione.

Il punto essenziale sta nel modo in cui valuta. Il framework non legge ciò che l'agente ha detto di aver fatto; controlla che cosa è effettivamente cambiato nel database al termine dell'attività. Questa distinzione non è un dettaglio tecnico. Gli agenti sono bravissimi a scrivere un riepilogo convincente di un lavoro mai avvenuto, e qualsiasi valutazione basata sulla trascrizione della conversazione misura la qualità della prosa, non la qualità dell'esecuzione.

Su questo ambiente il team ha costruito un benchmark chiamato Thinkingbox-bench, che contiene 507 flussi di lavoro vincolati da policy in cinque ambiti: retail ed e-commerce, viaggi e ospitalità, assicurazioni auto, supporto IT interno presso una neobanca e supporto IT e HR presso una società di consulenza. Ogni attività è stata eseguita venti volte su dodici modelli, sia proprietari sia a pesi aperti.

Perché quel numero conta per un imprenditore

Immagina di affidare a un agente la gestione delle richieste di reso del tuo negozio. Un tasso di successo del 65% sembra accettabile sulla carta. Nella pratica significa che un terzo delle richieste si conclude con un esito sbagliato: un rimborso emesso due volte, un ordine chiuso senza reintegrare le scorte o un'eccezione concessa a un cliente a cui la tua policy non la consente.

Peggio ancora, gli errori di questo studio non erano blocchi evidenti. L'articolo descrive esplicitamente molti errori come terminati in modo pulito e con passaggi che sembravano validi, mentre lo stato finale del sistema era comunque sbagliato. Nessun messaggio di errore, nessuna interruzione, niente che si accenda su una dashboard di monitoraggio. Solo un log che si legge normalmente e dati che sono diventati sbagliati in silenzio.

Un errore che ferma il sistema è fastidioso ma visibile. Un errore che completa il flusso e lascia i tuoi dati sbagliati è quello che ti costa davvero, perché lo scopri un mese dopo durante la riconciliazione.

Questo spiega anche una frequente fonte di delusione. Il progetto pilota supera la prova perché ha eseguito l'attività una volta su dati puliti. L'operatività reale è la stessa attività migliaia di volte su uno stato accumulato e disordinato, ed è esattamente lì che emerge la differenza tra il 65% e il 25%.

Cosa fare prima di adottare qualsiasi agente

  • Pretendi esecuzioni ripetute, non una sola demo. Fai di venti esecuzioni consecutive della stessa attività sugli stessi dati il tuo criterio di accettazione. Un fornitore che si rifiuta ti sta dicendo qualcosa.
  • Misura lo stato dei dati, non il testo della risposta. Definisci in anticipo come dovrebbe apparire il record nel tuo database dopo l'attività e confronta la realtà con quello. Non accontentarti di leggere il riepilogo dell'agente stesso.
  • Testa le policy, non solo le attività facili. La maggior parte del tuo lavoro non è libera; è vincolata da regole: finestre di reso, limiti di credito, eccezioni per clienti prioritari. Un agente che ha successo senza vincoli può crollare alla prima condizione reale.
  • Costruisci il set di test con i tuoi casi. Prendi venti casi reali degli ultimi mesi, compresi quelli strani che hanno confuso il tuo personale, e trasformali in una suite fissa da eseguire su qualsiasi modello prima di adottarlo e dopo ogni aggiornamento.
  • Concedi autorità per gradi. Inizia con un agente che propone ma non esegue, poi lascia che svolga operazioni a basso impatto, quindi amplia il suo ambito man mano che si accumula uno storico reale di misurazioni. L'autorità va guadagnata con i dati, non con le impressioni.

Come lo gestiamo in Origami

Quando costruiamo un sistema che include un agente IA, trattiamo l'agente come qualsiasi altro componente software: riceve una suite di test automatizzati, controlli di verifica che esaminano lo stato del database dopo ogni operazione e un chiaro punto di passaggio a una persona quando viene superata una soglia di confidenza. Il modello in sé resta un'impostazione sostituibile e non qualcosa saldato nel codice, perché il miglior modello di oggi potrebbe non essere il migliore fra tre mesi.

La conclusione da trarre da questo studio non è che gli agenti siano inutilizzabili. È che il metro con cui li giudicavamo era sbagliato. Gli agenti di oggi sono strumenti potenti all'interno di un ambito ben definito e misurato di continuo, e molto deboli quando si affida loro un processo delicato sulla base di una demo convincente. La differenza non sta nel modello; sta nella disciplina ingegneristica che lo circonda.

Fonti