Due agenti AI possono modificare lo stesso file, entrambi ricevono una conferma di "successo", eppure solo una delle loro modifiche sopravvive. In un semplice test con cinque agenti concorrenti, quattro delle cinque scritture sono scomparse senza alcun errore o voce di log: una classica anomalia di "lost-update" che spreca i token pagati per il lavoro svanito.
Perché il problema è importante
Quando un agente AI scrive un risultato, il servizio sottostante addebita il costo per ogni token generato. Se la scrittura viene sovrascritta silenziosamente, il provider fattura comunque la computazione che ha prodotto l'output scartato. Nei pipeline multi-agente — swarm di agenti, worker paralleli per la pulizia dei dati o qualsiasi sistema in cui più bot condividono un file di piano o un blocco note — queste perdite nascoste possono trasformarsi in una significativa fuga di costi. L'anomalia minaccia anche l'integrità dei dati: i passaggi successivi potrebbero agire su informazioni incomplete o obsolete, portando a errori a cascata.
Come avviene l'anomalia
La causa principale è una race condition:
- Due (o più) agenti leggono la stessa versione di una risorsa, ad esempio un file di piano JSON.
- Ognuno esegue il proprio ragionamento o trasformazione basandosi su quello snapshot.
- Entrambi gli agenti emettono un'operazione di scrittura verso lo storage condiviso.
- Il sistema di storage accetta la seconda scrittura, sovrascrivendo la prima senza alcun rilevamento di conflitto.
- Entrambi gli agenti ricevono un "ACK" che conferma il successo della scrittura, anche se il primo contributo è andato perduto.
La conferma del sistema di storage prova solo che è avvenuta una scrittura; non garantisce che la scrittura sia sicura rispetto ad altri aggiornamenti concorrenti. Un log append-only, spesso pubblicizzato come salvaguardia, si comporta allo stesso modo: registra che è avvenuta una scrittura ma non impedisce a scritture successive di sovrascrivere quelle precedenti.
Cosa fa un gate compare-and-set
Un gate compare-and-set (CAS) aggiunge un controllo della versione prima che la scrittura venga accettata:
- Read: L'agente recupera il numero di versione corrente (o l'hash) del file.
- Compute: L'agente svolge il proprio lavoro, producendo una nuova versione del file.
- Write: L'agente invia il nuovo contenuto insieme alla versione che aveva originariamente letto.
- Validate: Lo storage layer confronta la versione fornita con quella corrente. Se differiscono, la scrittura viene rifiutata; altrimenti, procede e incrementa la versione.
Se la versione è cambiata, l'agente sa che la sua visione era obsoleta e deve riprovare l'intero ciclo — read, compute, write — utilizzando la nuova versione. Questo trasforma una sovrascrittura invisibile in un fallimento esplicito che può essere loggato, riprovato e contabilizzato.
Il prezzo della sicurezza
Il gate CAS non è gratuito. Nella stessa simulazione con cinque agenti:
| Scenario | Scritture tentate | Contributi riusciti | Costo dei token |
|---|---|---|---|
| Senza gate CAS | 5 | 1 | 5 unità |
| Con gate CAS | 5 | 5 (dopo i retry) | 9 unità |
Il gate aggiunge cicli extra di read-compute-write per gli agenti che incontrano un conflitto di versione, aumentando la spesa di token. Il compromesso è chiaro: senza il gate si perdono i dati silenziosamente; con il gate si paga un modesto sovrapprezzo ma si ottiene visibilità su ogni conflitto.
Quanto è comune il fallimento?
Anche con soli due agenti, il test ha mostrato una probabilità del 75% che una delle scritture andasse persa. Con cinque agenti, il tasso di perdita si è avvicinato al 100%. Questi numeri suggeriscono che l'assunzione "di solito va bene" sia pericolosa per qualsiasi workflow multi-agente in produzione.
Controargomentazione: quando saltare il gate
Se un sistema esegue un singolo agente per risorsa o impone una serializzazione rigorosa a un livello superiore, i controlli CAS extra potrebbero essere superflui. Tuttavia, il calcolo del rischio deve includere il costo nascosto della riesecuzione del lavoro fallito e il potenziale impatto a valle della mancanza di dati.
Cosa monitorare in seguito
- Supporto degli strumenti: Cercare API di storage che espongano numeri di versione o ETag e forniscano operazioni CAS atomiche out of the box.
- Metriche: Strumentare gli agenti per registrare quanto spesso una scrittura viene rifiutata a causa di un disallineamento della versione. Un tasso di conflitto in aumento segnala la necessità di scalare le risorse o riprogettare il workflow.
- Strategie di retry: Un semplice exponential back-off funziona bene, ma attenzione: i tentativi ripetuti aumentano il consumo di token. Bilancia i limiti di retry rispetto alla perdita di dati accettabile.
- Approcci ibridi: Alcuni team combinano un log append-only per l'auditabilità con un gate CAS per la coerenza, garantendo sia una registrazione di ciò che è accaduto sia la protezione contro le sovrascritture.
Conclusione
Le anomalie di tipo "lost-update" trasformano le pipeline AI basate su token in buchi neri che disperdono denaro. Un gate di versione "compare-and-set" aggiunge un modesto sovraccarico di token, ma trasforma la perdita silenziosa di dati in un evento visibile e riprovabile. In qualsiasi sistema in cui più agenti condividono lo stato — database, file di pianificazione o scratchpad — inserire un controllo di versione prima delle scritture è l'assicurazione più economica contro i costi nascosti e i workflow corrotti.