Il quaderno che manca a Claude: architettura della memoria persistente per LLM agentici

1. Il paradosso dell'agente amnesico

I modelli linguistici di frontiera possono generare codice funzionante, condurre analisi di sicurezza su infrastrutture complesse, ragionare su problemi architetturali multi-dimensionali — ma non possono ricordare cosa hanno fatto nella sessione precedente. Ogni sessione nasce in un vuoto epistemologico: l'agente che ha costruito con competenza un sistema distribuito in 28 ore di lavoro, alla sessione successiva, non sa nemmeno che quel sistema esiste. Le decisioni architetturali, le lezioni apprese dagli errori, le preferenze dell'utente, lo stato del progetto — tutto ciò che un collaboratore umano accumulerebbe naturalmente nel corso di una collaborazione estesa — viene cancellato alla chiusura della chat.

Questo non è un bug: è una conseguenza diretta dell'architettura transformer (Vaswani et al., 2017), dove l'input al modello è interamente contenuto nella context window corrente e non esiste stato persistente tra sessioni. Ma il fatto che sia un vincolo architetturale e non un errore implementativo non lo rende meno problematico. La mancanza di memoria episodica trasforma ogni sessione in un primo appuntamento: le stesse domande vengono riposte, le stesse spiegazioni vengono ridate, gli stessi errori vengono ripetuti. Il ricercatore umano spende una quota crescente del proprio tempo — e dei token disponibili — a rieducare il collaboratore AI invece di lavorare con lui.

Le piattaforme che ospitano questi modelli hanno cominciato a integrare meccanismi di persistenza. Transcript delle sessioni precedenti, disponibili come file JSONL nel filesystem della sandbox. Aree di storage per file prodotti dall'utente e dall'agente. Skill operative caricabili dal filesystem. Meccanismi di "memoria" basati su riassunti sintetici delle conversazioni passate. Queste componenti esistono e rappresentano un progresso genuino. Ma sono componenti discrete, non un'architettura integrata. I transcript esistono sul disco ma nessun layer li organizza semanticamente. Le skill sono disponibili ma nessun protocollo le carica automaticamente in base al progetto specifico. Lo stato del lavoro è potenzialmente recuperabile ma nessun meccanismo di boot lo inietta strutturalmente nel contesto della nuova sessione.

Il risultato è un sistema che ha le protesi ma non il sistema nervoso che le coordina. I dati ci sono; la struttura che li rende operativi, no.

2. I quattro componenti dell'architettura che manca

L'esperienza operativa accumulata nella costruzione e nell'utilizzo di framework per agenti LLM con memoria persistente — documentata nel Metodo Staffetta (Siciliani, 2026) e nel framework MCP Media Lives — ha permesso di identificare quattro componenti architetturali che, operando in modo integrato, risolvono il problema della continuità inter-sessione.

2.1 Memoria di lavoro strutturata (CURRENT_STATE)

Il primo componente è uno snapshot strutturato dello stato corrente del progetto su cui l'agente sta lavorando. Non un riassunto narrativo — che perderebbe dettagli operativi critici — ma un documento strutturato che risponde a domande specifiche: cosa è stato completato e cosa resta da fare. Quali decisioni architetturali sono state prese e con quale razionale. Quali vincoli sono attivi (tecnici, di budget, di tempo, di infrastruttura). Quali file sono stati modificati nella sessione precedente e quale è il loro stato di verifica.

Il CURRENT_STATE è funzionalmente equivalente a una scheda di handover ospedaliero: il medico che prende il turno non rilegge l'intera cartella clinica del paziente — consulta la scheda di handover che contiene le informazioni essenziali per continuare il trattamento senza discontinuità. Allo stesso modo, l'agente che inizia una nuova sessione non deve rileggere migliaia di righe di transcript — consulta uno snapshot che lo porta allo stato operativo in pochi secondi.

Nell'implementazione che ho costruito, il CURRENT_STATE è un documento Markdown strutturato con sezioni fisse (obiettivi, completati, in sospeso, bloccati, decisioni, dipendenze) che viene aggiornato dall'agente al termine di ogni sessione e caricato automaticamente all'inizio della sessione successiva attraverso il protocollo di boot.

2.2 Passaggio di consegne esplicito (HANDOVER)

Il secondo componente è un artefatto che ogni sessione produce esplicitamente e che contiene le informazioni necessarie perché la sessione successiva possa proseguire senza discontinuità. L'handover include: un riassunto di ciò che è stato completato nella sessione, con riferimenti ai file e ai commit prodotti. Un elenco di ciò che è rimasto in sospeso, con il contesto necessario per riprendere il lavoro. I problemi incontrati durante la sessione, con le soluzioni adottate o tentate. Le raccomandazioni per la sessione successiva, incluse le priorità suggerite e i rischi identificati.

L'handover è il testimone della staffetta — il meccanismo che trasforma sessioni isolate in un percorso coerente. Senza un handover esplicito, la sessione successiva parte da zero anche se il CURRENT_STATE è disponibile, perché il CURRENT_STATE descrive dove siamo ma non come ci siamo arrivati né dove dovremmo andare.

La distinzione tra CURRENT_STATE e HANDOVER è analoga alla distinzione tra stato e storia in un sistema di controllo versione: lo stato (il contenuto corrente del repository) è necessario ma non sufficiente — la storia (la sequenza di commit che ha prodotto lo stato corrente) contiene informazioni contestuali indispensabili per comprendere le ragioni delle scelte e per prendere decisioni informate su come proseguire.

2.3 Lezioni dal campo (FIELD_NOTES)

Il terzo componente è un archivio cumulativo di lezioni operative apprese durante il progetto. Ogni FIELD_NOTE documenta un episodio specifico: un bug incontrato, un workaround necessario, un pattern che funziona, un pattern che fallisce, un vincolo dell'ambiente che non era documentato. Le FIELD_NOTES sopravvivono alla morte dell'istanza e vengono iniettate nel contesto della sessione successiva, svolgendo una funzione analoga alla memoria procedurale nel sistema cognitivo umano: non ricordi quando hai imparato che il fornello scotta, ma sai che il fornello scotta e agisci di conseguenza.

Nell'implementazione corrente, il framework accumula 21 lezioni operative numerate, ciascuna derivata da un episodio documentato di failure-and-recovery. Esempi rappresentativi: "FIELD_NOTE #7: mai usare sed -i su file PHP in produzione — usare script Python dedicato con backup esplicito e verifica sintattica post-modifica." "FIELD_NOTE #14: il processo lanciato da bash tool viene terminato dal provider al ritorno della call — usare pattern setsid + double-fork + /dev/null per detach robusto." Queste lezioni, accumulate in settimane di lavoro operativo, rappresentano un capitale di conoscenza che sarebbe catastrofico perdere ad ogni sessione. Senza FIELD_NOTES, ogni istanza è condannata a ripetere gli stessi errori che l'istanza precedente ha già commesso e corretto — un ciclo di Sisifo computazionale che consuma risorse senza produrre progresso.

2.4 Protocollo di boot (mcp_boot)

Il quarto componente è il meccanismo che orchestra il caricamento dei tre componenti precedenti nel contesto dell'agente all'inizio di ogni sessione. Il boot non è una lettura passiva di file — è un'operazione configurativa che prepara l'agente per il lavoro specifico che deve svolgere.

La funzione mcp_boot, implementata nel framework MCP che ho sviluppato, accetta come parametro il dominio del progetto (ad esempio "bridge.medialives.com") e restituisce al contesto dell'agente: il manuale operativo del progetto (versione corrente delle regole operative, con eventuali regole specifiche del progetto), lo stato corrente (CURRENT_STATE), le note dal campo (FIELD_NOTES), l'handover della sessione precedente, e l'elenco dei validator attivi con le loro condizioni di blocco.

Il risultato del boot è un agente che, nei primi secondi della sessione, sa: su quale progetto sta lavorando, qual è lo stato del progetto, quali decisioni sono state prese e perché, quali errori sono stati commessi e come evitarli, e quali regole operative deve rispettare. Senza boot, l'agente sa solo ciò che è scritto nel suo system prompt generico — una base insufficiente per lavoro di ingegneria continuativo.

3. L'evento di compaction: quando la memoria si resetta durante la sessione

Un fenomeno particolarmente rilevante per l'architettura della memoria persistente, documentato nella mia ricerca sperimentale del maggio 2026, è l'evento di compaction. Quando una sessione LLM supera la capacità della context window, la piattaforma che ospita il modello esegue una compaction: i messaggi più vecchi vengono riassunti, lo spazio nel contesto viene liberato, e la sessione prosegue con l'illusione di continuità. Per il modello, l'esperienza soggettiva è di apparente continuità: la conversazione procede come se nulla fosse accaduto.

In realtà, a livello infrastrutturale, la compaction è un evento catastrofico. I messaggi originali sono stati sostituiti da un riassunto che può perdere dettagli operativi critici. E — dato scoperto empiricamente durante la mia ricerca — qualsiasi processo in esecuzione nella sandbox dell'agente viene terminato silenziosamente. La microVM viene effettivamente riavviata: il boot_id del kernel cambia, i file temporanei in /tmp scompaiono, le variabili d'ambiente vengono reinizializzate. Solo i mount persistenti (/mnt/) sopravvivono.

Questa asimmetria — persistenza a livello di filesystem montato, effimericità a livello di processi userspace — ha implicazioni architetturali dirette. Ogni servizio long-running nella sandbox deve avere: storage persistente del proprio codice su percorso montato (non in /tmp), un pattern di auto-resume al riavvio (verificare la propria esistenza e riavviarsi se necessario), strumenti di visibilità per il ricercatore umano (heartbeat, stato "orphan" visibile da pannello web), e un meccanismo di ricostituzione idempotente che possa essere attivato dall'agente al primo turno post-compaction.

La scoperta è stata verificata sperimentalmente attraverso il monitoraggio di un processo executor con boot_id tracking: il boot_id prima e dopo la compaction differiva, confermando che il kernel era stato riavviato e che il processo era stato terminato e non semplicemente sospeso. Questa osservazione, non documentata nella letteratura pubblica del provider, ha implicazioni dirette per chiunque costruisca sistemi persistenti all'interno di sandbox per agenti LLM.

4. Verso un'architettura nativa: la proposta

La proposta che emerge da questo lavoro non è che ogni ricercatore o sviluppatore costruisca il proprio framework di persistenza artigianale — un approccio che, per quanto efficace nel caso singolo, non è scalabile e richiede competenze di system administration che la maggior parte degli utenti di LLM non possiede.

La proposta è che le piattaforme che ospitano agenti LLM integrino nativamente un'architettura di memoria strutturata come componente fondamentale dell'esperienza agente, non come feature opzionale o esperimento beta. I quattro componenti descritti in questo lavoro — CURRENT_STATE, HANDOVER, FIELD_NOTES e boot protocol — non sono concettualmente complessi né computazionalmente onerosi. Sono pattern di ingegneria del software maturi e ben compresi: snapshot di stato, handover documentsali, log di lezioni apprese, e sequenze di inizializzazione configurativa. Il fatto che non siano ancora standard nell'ecosistema degli agenti LLM non riflette un'impossibilità tecnica ma un ritardo progettuale.

Il futuro degli agenti LLM non è un modello più grande con una context window più ampia. L'aumento della context window allevia il sintomo (il modello dimentica a metà sessione) ma non cura la malattia (il modello non ricorda nulla della sessione precedente). Il futuro è un modello con un quaderno che non si perde — un'architettura di memoria strutturata che trasforma sessioni isolate in un continuum di collaborazione dove ogni sessione inizia dal punto in cui la precedente si è conclusa, con accesso immediato alle decisioni, alle lezioni e allo stato accumulati nel tempo.

Un paper accademico che formalizza questa architettura, con benchmark comparativi tra sessioni con e senza quaderno strutturato, è in preparazione. I risultati preliminari suggeriscono riduzioni significative nella ripetizione di errori (error repeat rate), nello spreco di token per rieducazione del contesto (context re-education overhead), e nel drift decisionale tra sessioni consecutive (inter-session decision consistency).

Giuseppe Siciliani Independent Cybersecurity Researcher & AI Consultant, Milano Media Lives Cybersecurity Research Lab (MLCSL), Media Lives S.r.l.