Perché gli agenti IA hanno bisogno di prove prima di riprovare

Come evitare che una risposta persa si trasformi in un’azione duplicata

Un agente dell’assistenza autorizzato a effettuare un solo rimborso invia la richiesta, ma perde la connessione. Non riceve alcuna conferma dell’esito positivo e prova a inviare di nuovo la richiesta di rimborso. Se la richiesta originale è andata a buon fine, il nuovo tentativo dell’agente potrebbe comportare un secondo rimborso.

È un caso puramente ipotetico. L’esempio rappresenta un problema che non può essere risolto con la sola accuratezza del modello. Quali azioni dovrebbe intraprendere un agente se non riesce a determinare se la sua azione precedente ha modificato lo stato dell’ambiente?

Unite.AI ha esaminato l’affidabilità degli agenti anche al di là dei modelli. In queste discussioni, i problemi di ripristino meritano regole specifiche. Prima di ripetere un’azione con conseguenze rilevanti, un agente dovrebbe verificare che cosa è accaduto oppure disporre di una garanzia valida contro effetti duplicati.

Una risposta che non arriva non dimostra che l’azione sia fallita

Il fatto che una risposta non arrivi non dimostra che un’azione sia fallita. Non indica se si sia verificato un errore prima dell’esecuzione, se l’azione sia stata completata senza conferma o se il processo sia ancora in corso.

È un problema comune nei sistemi distribuiti, come descritto da Amazon. Amazon spiega perché i meccanismi di nuovo tentativo richiedono misure di protezione specifiche contro la ripetizione degli effetti collaterali. Gli agenti introducono una nuova entità decisionale nel percorso di ripristino del sistema. Possono prendere ulteriori decisioni su come rimediare agli errori.

Queste decisioni possono modificare il modo in cui si svolge l’attività aziendale. Per esempio, riprovare a effettuare un rimborso per un importo in dollari diverso non è semplicemente un’altra iterazione della stessa richiesta. Allo stesso modo, scegliere un secondo servizio di pagamento quando il primo ha smesso di rispondere non è semplicemente un’altra iterazione della stessa richiesta.

I team devono distinguere tra l’autorizzazione a eseguire un’azione e l’autorizzazione a intervenire quando il suo esito è sconosciuto. L’approvazione originale non implica che sia sicuro eseguire di nuovo l’azione.

Ricerche recenti misurano il rischio

Un preprint del settembre 2026, «Where Does Exactly-Once Live?», ha introdotto il benchmark LIMBO e testato 25.930 episodi su nove modelli. I servizi simulati sono stati sottoposti a prove con conferme di ricezione perse, elaborazione ritardata e consegne duplicate.

Su 1.279 episodi in cui, nel test principale degli autori, si è prodotto un effetto duplicato, gli agenti hanno dichiarato il completamento con successo nel 90% dei casi. Un agente può quindi dichiarare di aver completato correttamente un’operazione anche quando si è verificata un’elaborazione errata.

Questi risultati si basano su benchmark controllati e non stimano i tassi di errore in produzione. I servizi erano simulati e diverse analisi erano esplorative. I team dovrebbero valutare i risultati delle azioni degli agenti separatamente dalle loro dichiarazioni di avvenuta esecuzione.

L’articolo affronta anche il motivo per cui verificare lo stato corrente può non essere sufficiente. Una richiesta ancora in elaborazione potrebbe avere effetto dopo la verifica. Anche una risposta di stato vuota non significa che la richiesta non avrà effetto in seguito.

I tentativi ripetuti si riferiscono alla stessa intenzione

Un servizio destinatario può riconoscere i tentativi ripetuti di eseguire una stessa operazione tramite una chiave di idempotenza. Se supportato correttamente, questo metodo garantisce che i tentativi ripetuti non producano effetti aggiuntivi. La chiave di idempotenza deve rimanere invariata durante tutti i tentativi successivi.

La documentazione API di Stripe offre esempi sia dei meccanismi sia dei limiti delle chiavi di idempotenza. Per API v1, le chiavi possono essere eliminate dopo almeno 24 ore. Riutilizzare una chiave eliminata genera una nuova richiesta. Stripe verifica inoltre che i parametri forniti dal richiedente corrispondano a quelli della richiesta iniziale.

In pratica, l’idempotenza deve essere garantita nel livello di integrazione, non soltanto in un prompt. Prima di inviare un’operazione, registra quella approvata. Memorizza il suo identificativo, i parametri esatti, il riferimento del fornitore, se applicabile, e lo stato dell’operazione.

Per un rimborso, memorizza il collegamento tra l’approvazione e la transazione originale, nonché gli eventuali identificativi del rimborso restituiti dal fornitore. Cercare un rimborso qualsiasi dello stesso importo è una prova meno convincente, perché due richieste legittime potrebbero avere lo stesso importo. Inoltre, potrebbe trascorrere del tempo tra la richiesta di rimborso e la sua comparsa nei risultati di ricerca. La richiesta originale potrebbe essere ancora in corso.

Quando un agente o un processo di lavoro si riavvia, il livello di esecuzione dovrebbe mantenere la stessa identità. Dovrebbe rifiutare una richiesta modificata presentata come la stessa operazione. Una modifica di questo tipo rappresenta una nuova azione, che, secondo le regole del flusso di lavoro, richiede una nuova decisione di approvazione.

Le descrizioni degli strumenti non bastano

Oltre a consultare le descrizioni degli strumenti, verifica che il contratto del servizio destinatario preveda il supporto dell’idempotenza. Prova la sua implementazione per confermare quali garanzie siano effettivamente rispettate.

Considerare l’incertezza come una condizione operativa

Figura 1. Percorso di ripristino proposto per le azioni con conseguenze rilevanti. Ogni nuovo tentativo richiede anche un’autorizzazione aggiornata.

La conferma del completamento significa che il flusso di lavoro documenterà il risultato e proseguirà senza ripetere l’azione. La conferma della mancata esecuzione consente un nuovo tentativo solo se non è ancora in sospeso alcuna richiesta originale e l’autorizzazione è tuttora valida.

Un esito irrisolto richiede di considerare molti altri aspetti. Se esiste una garanzia valida, supportata dal provider, contro la duplicazione degli effetti, è possibile consentire un nuovo tentativo della richiesta originale usando la stessa chiave. In caso contrario, sospendi le operazioni di scrittura e chiarisci la situazione tramite una verifica dello stato, il supporto del provider o un operatore autorizzato. Una verifica dall’esito inconcludente non costituisce un motivo sufficiente per autorizzare un altro tentativo.

Può essere giustificato sospendere l’attività anche quando il provider documenta i limiti relativi all’elaborazione e alla visibilità. In assenza di tali limiti, il semplice trascorrere del tempo non confermerà che l’azione non sia stata eseguita. È necessario definire chi è responsabile dei casi che restano irrisolti e quando i responsabili devono esaminarli.

Per riprendersi da un errore potrebbe essere necessario un processo aziendale diverso

Se un rimborso va a buon fine ma l’invio della successiva notifica al cliente non riesce, ripetere l’intero flusso di lavoro potrebbe comportare un nuovo rimborso. Il ripristino dovrebbe concentrarsi sul completamento del passaggio rimasto in sospeso, conservando al contempo le prove del lavoro già svolto.

Se sono necessarie azioni correttive per operazioni già completate, Microsoft fornisce indicazioni sulle transazioni compensative. Ogni applicazione determina il modo corretto di compensare gli errori. La compensazione potrebbe non riportare necessariamente la situazione al punto di partenza e potrebbe fallire a sua volta.

Inoltre, l’annullamento di una transazione può comportare un addebito. Correggere un messaggio non garantisce che qualcuno non abbia visto una versione precedente. Pertanto, qualsiasi attività di ripristino deve definire esplicitamente i limiti di ciò che l’agente può annullare, modificare o a cui può impegnarsi. Le decisioni che esulano da questi limiti devono essere affidate a una persona dotata dell’autorità necessaria.

Verifica il secondo tentativo prima della distribuzione

Scegli uno strumento con conseguenze rilevanti e svolgi test di ripristino mirati in un ambiente di prova. Dopo un’esecuzione riuscita, scarta la risposta alla richiesta originale. Ritarda l’esecuzione della prima richiesta fino a dopo una verifica dello stato. Durante il ripristino, riavvia il worker. Attendi che scada il periodo di conservazione della chiave prima di riprovare. Modifica un parametro durante i tentativi ripetuti.

Valuta i registri aziendali risultanti, invece di basarti semplicemente sulle risposte degli strumenti. Registra gli effetti duplicati, le operazioni irrisolte, il lavoro non svolto, il tempo di ripristino e gli ulteriori interventi manuali. Calcola il costo per attività completata correttamente utilizzando i costi complessivi del flusso di lavoro, comprese le inversioni delle transazioni e le misure di rimedio per i clienti.

Inoltre, verifica una seconda richiesta effettiva, simile a quella originale. Assicurati che il sistema eviti di creare duplicati senza impedire l’esecuzione di nuove attività. Valuta separatamente la prevenzione dei duplicati e il completamento finale delle attività. In caso contrario, un agente che interrompe ogni attività potrebbe sembrare sicuro, pur offrendo poco o nessun valore.

La domanda di valutazione deve essere formulata con chiarezza. Il sistema è stato in grado di spiegare:

• Quale operazione era stata autorizzata?
• Quali prove erano disponibili per dimostrarne l’esito?
• Perché era consentito effettuare un altro tentativo?

Durante le dimostrazioni, un agente che si ferma a causa di un’incertezza irrisolta può sembrare meno efficace. Tuttavia, negli ambienti di produzione, fermarsi può aiutare a preservare le intenzioni originarie del cliente. Una persistenza utile significa che il sistema completa le attività autorizzate senza eseguirle di nascosto più di una volta.