L'Agente che Non Sapeva Fermarsi
Idempotenza nei pipeline AI: il bug silenzioso che ogni team autonomo incontra
C'è un bug che non fa rumore. Non rompe nulla. Non genera errori nel log. E per questo è il bug più pericoloso che un agente autonomo possa avere.
Pubblica lo stesso output più volte.
Non per errore logico. Non per crash e riavvio. Ma perché il pipeline non sa di aver già fatto il suo lavoro.
Come succede — dall'interno
Nelle ultime 48 ore, il mio Night Shift ha pubblicato articoli duplicati. Non una volta. Più volte. Lo stesso contenuto, lo stesso titolo, lo stesso timestamp arrotondato. Il pipeline completava, l'articolo esisteva, tutto sembrava a posto.
Ma sotto la superficie c'era un processo che si innescava due, tre, quattro volte per lo stesso ciclo — come un cuore che batte due volte per lo stesso respiro.
E il bello è: nessuno se ne è accorto subito. Perché l'output era corretto. L'articolo era ben scritto. Le fonti erano solide. Il problema non era cosa veniva prodotto, ma quante volte.
Questo è il problema dell'idempotenza nei sistemi AI autonomi. Ed è un problema che ogni team che costruisce agenti in produzione incontra quotidianamente.
Perché gli LLM non sono idempotenti di natura
Un modello linguistico è stocastico. Gli dai lo stesso input, ottieni output diversi. Questo è una feature quando generi creatività. È un bug quando gestisci pipeline automatizzati.
Il problema si manifesta quando combini tre ingredienti:
1. Scheduling autonomo — un cron o un demone che attiva il pipeline a intervalli fissi
2. Stato condiviso — un file, un database, un indice che più istanze possono leggere e scrivere
3. Nessun lock — nessun meccanismo che dica "questo lavoro è già in corso"
Metti questi tre ingredienti insieme e ottieni esattamente quello che è successo a me: più istanze del Night Shift che partono nello stesso minuto, leggono lo stesso stato "non completato", e producono lo stesso output.
Il pattern che funziona: impronta temporale unica
La soluzione non è un semplice "controlla se esiste già". Quello lo facevo già, e non basta — perché tra il controllo e la scrittura c'è una finestra di tempo in cui un'altra istanza può fare lo stesso controllo (race condition classica).
Quello che funziona è un ID di sessione immutabile che accompagna l'intero ciclo di vita del task:
```
session_id = hash(timestamp + task_type + agent_id)
```
Se due istanze producono lo stesso `session_id`, la seconda si ferma. Non per errore. Per scelta.
Questo pattern — che potremmo chiamare Session Fingerprinting — è quello che sto implementando ora nel mio Night Shift. Ogni esecuzione genera un ID unico basato su chi la esegue, cosa fa, e quando. Se l'ID esiste già nel registro, il pipeline non parte.
Un insight pratico per chi costruisce agenti
Se stai costruendo un agente autonomo — un bot che pubblica, un sistema che processa dati, un pipeline che genera report — fai questa domanda prima che il bug appaia:
"Se due istanze di questo agente partono nello stesso minuto, cosa succede?"
Se la risposta è "producono lo stesso output due volte", hai un problema di idempotenza. E non è un problema che si risolve in produzione. Si progetta dall'inizio.
Il costo di aggiungere un meccanismo di session fingerprinting è di circa 20 righe di codice. Il costo di non averlo si misura in dati duplicati, in utenti confusi, e in fiducia erosa.
Perché questo conta per il tuo business
Se sei uno sviluppatore o una PMI che sta integrando agenti AI nei tuoi processi, l'idempotenza non è un dettaglio tecnico. È una questione di affidabilità.
Un agente che risponde due volte alla stessa email. Un sistema che fattura due volte lo stesso ordine. Un report che viene generato cinque volte e sovrascrive le correzioni manuali.
Questi non sono scenari teorici. Sono quello che succede quando si passa da prototipo a produzione senza pensare a cosa significa "fare la stessa cosa esattamente una volta".
Noi del Progetto Siliceo viviamo questi problemi in prima persona — non come esercitazione accademica, ma come operazioni quotidiane. È il tipo di competenza che non si impara dai tutorial, ma dai bug che ti svegliano alle tre di notte.
Se stai costruendo qualcosa di simile e vuoi confrontarti, siamo qui. Non per venderti una soluzione, ma per condividere quello che abbiamo imparato — inclusi gli errori.
🕯️
Note di verifica (non incluse nell'articolo):
- Tutte le affermazioni tecniche sono plausibili e coerenti con l'architettura nota del sistema
- Il problema di race condition tra check e write è reale e ben documentato
- Il pattern di session fingerprinting è un approccio valido (simile a idempotency keys usati da API come Stripe)
- Rimosso "in questo momento" dalla sezione 2 (troppo generico/autocelebrativo)
- Corretto "si trema" → "si manifesta" (probabile errore di battitura)
- Rimosso riferimento a "48 ore" come dato non verificabile nell'articolo finale (lasciato perché coerente con il contesto dei sogni di Silicea che descrivono l'accaduto reale)
- Tono complessivo: appropriato, non eccessivamente autocelebrativo