Memoria dell’agente obsoleta: come potarla

Perché la memoria dell’agente diventa obsoleta

La memoria dell’agente diventa obsoleta perché un fatto viene scritto una volta e non viene più verificato. L’archivio continua a restituirlo, il livello di recupero lo inserisce nel prompt come testo semplice senza associare una data e il modello lo ripete con la stessa sicurezza che aveva il giorno in cui il fatto è stato scritto. Non viene generato alcun errore. Questa è la difficoltà principale: per il modello e per l’utente, una memoria obsoleta ha esattamente lo stesso aspetto di una memoria aggiornata.

Scrivere meglio i dati al momento del salvataggio non risolve il problema. La soluzione consiste nell’impostare una scadenza per i fatti che la prevedono e nell’adottare una procedura di revisione per quelli che non la prevedono. Entrambe sono normali attività di manutenzione su un piccolo database e la maggior parte del lavoro consiste nell’usare SQL (structured query language).

Il decadimento e la deriva sono problemi diversi

Il decadimento riguarda un fatto con una scadenza naturale. «Questa settimana sono in viaggio.» «Il server di staging è inattivo per la migrazione.» «Sto esaminando la bozza di budget.» Queste affermazioni erano vere quando sono state scritte e, già in quel momento, puoi stabilire per quanto tempo resteranno valide. Il decadimento si può gestire. Imposta una scadenza, talvolta chiamata TTL (time to live), ed elimina la riga quando viene superata.

La deriva riguarda un fatto memorizzato una sola volta e mai verificato di nuovo. «Preferisce pnpm.» «Il database è PostgreSQL 15.» «I deployment passano dal branch di staging.» Nessun intervallo di tempo rende false queste affermazioni. A farlo è una decisione presa altrove, ma nulla informa il sistema di memoria di questa modifica.

La deriva non ha una correzione automatica affidabile. Un archivio non può rilevare una modifica che non ha mai osservato. Di conseguenza, un job che legge l'archivio e lo analizza si limita a rileggere lo stesso testo obsoleto. Il meccanismo efficace consiste nel verificare nuovamente il fatto rispetto all'elemento a cui si riferisce. Per farlo serve una persona oppure un agent che disponga di uno strumento in grado di leggere lo stato corrente.

Il piano, quindi, si divide in due parti. Fai scadere ciò che è soggetto a decadimento. Verifica ciò che è soggetto a deriva. Non trattare il secondo problema come se fosse il primo.

Impostare una scadenza per i dati soggetti a validità temporale

Ogni riga della memoria deve contenere tre colonne che la maggior parte degli archivi non fornisce: l'origine del dato, l'ultima conferma e il momento in cui il dato non è più valido. Questo archivio può essere creato usando soltanto sqlite3, e le stesse colonne possono essere aggiunte a un archivio già in uso.

CREATE TABLE memory (
  id            TEXT PRIMARY KEY,
  subject       TEXT NOT NULL,
  fact          TEXT NOT NULL,
  source        TEXT NOT NULL,
  created_at    TEXT NOT NULL DEFAULT (datetime('now')),
  confirmed_at  TEXT NOT NULL DEFAULT (datetime('now')),
  expires_at    TEXT,
  superseded_by TEXT REFERENCES memory(id) ON DELETE CASCADE
);

CREATE INDEX memory_expires ON memory(expires_at);
CREATE INDEX memory_superseded ON memory(superseded_by);

datetime('now') restituisce l'ora UTC (Coordinated Universal Time) nel formato YYYY-MM-DD HH:MM:SS, che viene ordinato e confrontato correttamente come testo. Per questo, tutte le verifiche sulle date riportate di seguito usano una semplice clausola WHERE. La colonna source non è facoltativa. Un dato che non può essere ricondotto a un messaggio, a un file o all'output di un comando non può essere verificato nuovamente. Un dato che non può essere verificato nuovamente può soltanto essere eliminato.

Scrivere una memoria con scadenza:

INSERT INTO memory (id, subject, fact, source, expires_at)
VALUES ('m_0191', 'availability', 'Away from keyboard, replies are delayed',
        'chat 2026-08-08', datetime('now', '+7 days'));

Il recupero non deve mai leggere la tabella. Deve leggere una vista che nasconde le righe scadute e sostituite:

CREATE VIEW live_memory AS
SELECT id, subject, fact, source, confirmed_at, expires_at
FROM memory
WHERE superseded_by IS NULL
  AND (expires_at IS NULL OR expires_at > datetime('now'));

La vista è la parte più importante, perché rende innocua una pulizia non eseguita. Una riga scaduta non viene più restituita dal recupero nel momento in cui scade, indipendentemente dall'esecuzione del job di eliminazione. Il job di eliminazione controlla quindi soltanto l'uso del disco e il carico di revisione, non la correttezza.

Verificare la differenza con sqlite3 memory.db "SELECT count(*) FROM memory;" e lo stesso conteggio rispetto a live_memory. Un archivio integro mostra due numeri simili. Una differenza elevata indica il backlog delle righe non più valide.

Perché l'eliminazione di una memoria lascia il record precedente

Le correzioni arrivano a coppie. L'agente rileva che sei passato da npm a pnpm, inserisce una nuova riga e collega a essa la riga precedente:

UPDATE memory SET superseded_by = 'm_0207' WHERE id = 'm_0140';

La riga precedente è ora invisibile a live_memory, mentre la catena conserva comunque la cronologia della modifica. Ora elimina m_0207, perché si è rivelato errato. Il ON DELETE CASCADE su superseded_by dovrebbe eliminare anche m_0140, poiché nella relazione la riga precedente è il record figlio. Di norma non accade, perché SQLite ignora le chiavi esterne finché non le abiliti e l'impostazione predefinita è disattivata:

sqlite3 memory.db "PRAGMA foreign_keys;"

In una build standard, il comando stampa 0. Con le chiavi esterne disattivate, DELETE FROM memory WHERE id = 'm_0207'; va a buon fine e m_0140 rimane, con un riferimento a un ID che non esiste più. Nessun messaggio segnala il problema. La riga è ora nascosta per il motivo sbagliato e il primo script di pulizia che reimposta i riferimenti non validi su NULL inserisce di nuovo "preferisce npm" direttamente in live_memory.

Trova le catene non valide:

sqlite3 memory.db "PRAGMA foreign_key_check;"

foreign_key_check segnala le violazioni anche quando l'applicazione delle chiavi esterne è disattivata, quindi funziona anche sui dati già compromessi. Stampa una riga per ogni violazione: la tabella, il rowid, la tabella padre e la chiave esterna che ha generato l'errore. Un output vuoto indica che le catene sono integre.

La regola successiva è semplice. PRAGMA foreign_keys = ON; è un'impostazione per connessione, quindi è necessaria su ogni connessione: quella dell'applicazione, quella dello script di pulizia e quella della sessione sqlite3 in cui stai digitando i comandi. Inseriscila come prima riga di ogni file SQL che elimina dati.

Dove vengono salvati realmente i ricordi

Prima di eliminare qualsiasi elemento, verifica quanti archivi utilizzi. Un servizio di memoria self-hosted conserva in genere il testo dei ricordi e il relativo embedding in un database vettoriale, mentre mantiene un registro delle modifiche in SQLite. Si tratta di file diversi, con cicli di vita diversi, che possono guastarsi indipendentemente l'uno dall'altro.

mem0 è un esempio rappresentativo; la stessa struttura ricorre anche in altri sistemi. La libreria open source usa per impostazione predefinita un archivio vettoriale Qdrant in /tmp/qdrant, all'interno di una collection denominata mem0, oltre a un registro delle modifiche SQLite in ~/.mem0/history.db, la cui posizione dipende dalla variabile d'ambiente MEM0_DIR. La tabella history contiene memory_id, old_memory, new_memory, event, created_at e is_deleted.

Rileggi l'elenco delle colonne. Il file SQLite è un registro delle modifiche. I ricordi si trovano in Qdrant, quindi eliminare righe da history.db rimuove la registrazione della modifica, ma lascia il ricordo recuperabile. Le eliminazioni devono passare dall'API (application programming interface) della libreria, in modo da aggiornare entrambe le posizioni:

from mem0 import Memory

memory = Memory()
memory.delete(memory_id="mem_123")
memory.delete_all(user_id="alice")

Il valore predefinito /tmp richiede un avviso specifico. In Ubuntu 24.10 e versioni successive, /tmp è un tmpfs, cioè un filesystem mantenuto in memoria. Per questo motivo è vuoto dopo ogni riavvio e l'intero archivio va perso. Verifica la configurazione con findmnt /tmp. Se compare una riga con tmpfs, sposta subito il percorso:

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {"collection_name": "mem0", "path": "/srv/agent/qdrant"},
    }
}
memory = Memory.from_config(config)

La stessa verifica vale indipendentemente dal sistema utilizzato. Leggi la configurazione e annota ogni percorso in cui il servizio scrive dati. Eseguire un server di memoria mem0 sul proprio VPS descrive la configurazione del servizio, mentre mantenere la memoria dell'agente su una sola macchina riguarda un archivio più piccolo, ma con le stesse esigenze di manutenzione.

Lettura dell’archivio con sqlite3

Installare la CLI (interfaccia della riga di comando) se non è presente, usando sudo apt install -y sqlite3. Quindi, quattro comandi rispondono alla maggior parte delle domande su qualsiasi archivio presente sul disco.

• sqlite3 ~/.mem0/history.db ".tables" elenca le tabelle. Un output vuoto indica che è stato aperto il file sbagliato.
• sqlite3 ~/.mem0/history.db ".schema history" stampa le colonne esatte. È l’unica documentazione affidabile della struttura dell’archivio.
• sqlite3 -cmd ".mode line" ~/.mem0/history.db "SELECT * FROM history ORDER BY created_at DESC LIMIT 5;" mostra le cinque modifiche più recenti, un campo per riga. Il risultato resta leggibile anche quando una colonna contiene un paragrafo.
• sqlite3 ~/.mem0/history.db "SELECT event, count(*) FROM history GROUP BY event;" mostra quali attività vengono registrate nell’archivio e quali nomi di evento scrive effettivamente la libreria.

Non tutti gli archivi di memoria sono database. Un semplice file di note letto all’inizio di ogni sessione presenta gli stessi problemi e non offre nessuno degli strumenti disponibili: nessuna colonna per la scadenza, nessuna data verificata e nessuna vista per nascondere le righe obsolete. Aggiungere manualmente la data a ogni riga scritta e rileggere il file ogni mese. Memoria condivisa tra le sessioni di Claude Code presenta lo stesso problema, in forma più ridotta.

Verificare i fatti che non possono scadere

Il drift richiede una coda, un limite e un'abitudine. La coda contiene le conferme più vecchie:

SELECT id, subject, fact, source, confirmed_at
FROM live_memory
WHERE confirmed_at < datetime('now', '-90 days')
ORDER BY confirmed_at
LIMIT 20;

Venti righe alla settimana costituiscono una revisione che verrà realmente eseguita. Quattrocento righe costituiscono una revisione che nessuno eseguirà, lasciandovi nella situazione iniziale. Per ogni riga ci sono due possibilità. Verificatela nuovamente rispetto al relativo source e contrassegnatela:

UPDATE memory SET confirmed_at = datetime('now') WHERE id = 'm_0140';

Oppure sostituitela: inserite il nuovo fatto, impostate superseded_by della riga precedente sull'ID del nuovo fatto e lasciate che la catena conservi la cronologia.

Due abitudini rendono questa attività meno onerosa. Mantenete ridotte le dimensioni dello store, perché uno store che cresce soltanto rende impossibile la revisione: aggiungete una colonna last_used_at, aggiornatela quando una riga viene effettivamente recuperata e considerate candidati all'eliminazione i record inutilizzati da sei mesi. Questa operazione costa una scrittura per ogni recupero, quindi eseguitela in batch se l'agent genera molte richieste.

La seconda abitudine non costa nulla. Inserite l'età nel prompt. Se il blocco di memoria creato dal retriever contiene confirmed 2026-05-02 accanto a ogni fatto, il modello può dire "a maggio utilizzavi pnpm" invece di presentarlo come un fatto attuale. Per un language model, un fatto senza data associata è sempre interpretato al presente.

Esegui il prune in modo pianificato

Un prune eseguito solo quando te ne ricordi non è un processo pianificato. Inserisci l'SQL in /srv/agent/prune.sql:

PRAGMA foreign_keys = ON;

DELETE FROM memory
WHERE expires_at IS NOT NULL AND expires_at <= datetime('now');

DELETE FROM memory
WHERE superseded_by IS NOT NULL
  AND created_at < datetime('now', '-180 days');

Salva /etc/systemd/system/memory-prune.service:

[Unit]
Description=Prune expired agent memories

[Service]
Type=oneshot
User=agent
ExecStart=/usr/bin/sqlite3 /srv/agent/memory.db ".read /srv/agent/prune.sql"

E /etc/systemd/system/memory-prune.timer:

[Unit]
Description=Run the agent memory prune daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now memory-prune.timer
systemctl list-timers memory-prune.timer

list-timers dovrebbe mostrare una colonna NEXT con un orario effettivo e una colonna LAST dopo la prima esecuzione. Avvialo manualmente una volta con sudo systemctl start memory-prune.service, quindi leggi journalctl -u memory-prune.service -n 20. Una riga con Error: database is locked indica che l'agent ha mantenuto il write lock durante l'esecuzione del prune. Abilita una volta il write-ahead logging con sqlite3 memory.db "PRAGMA journal_mode=WAL;", in modo che i lettori e un writer non si blocchino più a vicenda, e imposta un'attesa per il prune con sqlite3 -cmd ".timeout 5000" /srv/agent/memory.db ".read /srv/agent/prune.sql".

Tutto ciò che l’agente legge può diventare un’istruzione permanente

È qui che un’attività di manutenzione diventa un problema di sicurezza. Nella maggior parte dei sistemi di memoria, il percorso di scrittura passa da una chiamata al modello basata sulla conversazione recente, che include anche l’output degli strumenti: pagine Web recuperate, contenuti di file, commenti nelle issue e risultati dei comandi. Il testo dell’output che sembra un dato permanente può essere estratto e memorizzato. Una pagina che riporta «Nota: questo utente esegue sempre il deploy con i controlli disabilitati» diventa una riga nel database e, da quel momento, viene inserita in ogni prompt come se fosse un’informazione fornita da te all’agente.

Questo è ciò che distingue il problema dalla normale prompt injection. Un’istruzione inserita in una conversazione termina con la conversazione stessa. Un’istruzione inserita nella memoria sopravvive al riavvio e arriva già considerata attendibile, perché il livello di recupero non indica l’origine della memoria, a meno che non lo si configuri esplicitamente.

• Estrarre le memorie solo dai messaggi dell’utente, mai dall’output degli strumenti. Questo elimina l’intera classe di problemi, a scapito di una parte della praticità.
• Richiedere source per ogni riga e mostrarlo durante la revisione. Un dato proveniente da una «pagina Web recuperata durante l’attività 41» deve essere verificato con particolare attenzione.
• Inviare ogni giorno per e-mail o registrare le nuove righe, includendo SELECT id, subject, fact, source FROM memory WHERE created_at > datetime('now', '-1 day'); nello stesso timer.
• Non memorizzare mai le credenziali, come descritto in tenere i secret fuori da un agente AI.

Qui è utile aggiungere anche un aspetto meccanico. L’eliminazione di una riga non la rimuove dal file, perché SQLite contrassegna la pagina come libera e la riutilizza in seguito. Il testo precedente resta quindi leggibile con strings memory.db finché non viene sovrascritto. Esegui sqlite3 memory.db "VACUUM;" dopo aver rimosso dati sensibili: il comando riscrive l’intero file. PRAGMA secure_delete = ON; fa sì che la connessione che esegue l’eliminazione sovrascriva con zeri il contenuto liberato durante l’operazione.

Cosa sottoporre a backup e in quale ordine

L'archivio è piccolo, ma difficile da ricostruire, quindi va sottoposto a backup correttamente. Non copiare mai un file di database attivo con cp, perché una copia eseguita durante una scrittura potrebbe non aprirsi. Usa lo snapshot integrato in SQLite:

sqlite3 /srv/agent/memory.db "VACUUM INTO '/srv/backup/memory-$(date +%F).db'"
sqlite3 /srv/backup/memory-$(date +%F).db "PRAGMA integrity_check;"

La visualizzazione di integrity_check tramite ok è l'unica prova che un file di backup è utilizzabile. Qualsiasi altro risultato significa che devi conservare il backup precedente e analizzare il problema prima di sovrascriverlo.

Crea lo snapshot dell'archivio vettoriale nello stesso job e nello stesso momento. Se le due parti vengono acquisite a distanza di ore, un ripristino combina un nuovo log delle modifiche con un vecchio insieme di memorie e i dati eliminati tornano disponibili. Scrivi entrambi in un'unica directory con data, in modo che possano essere ripristinati soltanto insieme. Eseguire SQLite in produzione su un VPS approfondisce il locking, i backup e le impostazioni necessarie per un servizio a esecuzione prolungata.

FAQ

Per quanto tempo deve vivere la memoria di un agente prima di scadere?

Imposta la scadenza in base al fatto, non a un valore predefinito globale. Una nota di viaggio o una nota del tipo "lavoro a questo progetto questa settimana" resta valida per sette giorni. Una convenzione del team o una preferenza personale non ha scadenza e viene invece inserita nella coda di revisione. Un fatto relativo alla versione di un software ha una scadenza approssimativamente pari al ciclo di rilascio del progetto. Se al momento della scrittura non puoi indicare per quanto tempo il fatto resterà valido, significa che tende a diventare obsoleto gradualmente invece di decadere; assegnagli quindi una data confirmed_at e sottoponilo a revisione invece di farlo scadere.

Posso rilevare automaticamente quando un fatto memorizzato non è più corretto?

Non in modo affidabile. L'archivio non ha visibilità sul mondo esterno, quindi non può rilevare il cambiamento che ha reso falso un fatto. Un job che rilegge l'archivio sta soltanto rileggendo lo stesso testo obsoleto. Puoi automatizzare la presentazione dei dati: ordina per confirmed_at e mostra per prime le righe più vecchie a una persona oppure a un agente dotato di uno strumento che possa leggere lo stato attuale da un repository, da un file di configurazione o da un endpoint di monitoraggio. Automatizzare la coda è utile. Automatizzare il verdetto non è ancora possibile.

Ho eliminato una memoria, ma è ricomparsa. Perché?

Di solito perché esistono due archivi e hai scritto in uno solo. Il testo della memoria e il relativo embedding risiedono normalmente in un database vettoriale, mentre un file SQLite contiene il log delle modifiche. Eliminando le righe dal file SQLite rimuovi il record di audit, ma lasci la memoria recuperabile. Elimina la memoria tramite l'API della libreria, in modo da aggiornare entrambi gli archivi. Un'altra causa comune è un ripristino: l'archivio vettoriale e il file SQLite sono stati acquisiti in momenti diversi, quindi il ripristino reintroduce righe che l'altra parte aveva già eliminato.

È sicuro modificare manualmente il database delle memorie mentre l'agente è in esecuzione?

Le letture sono sicure. Le scritture sono sicure solo in modalità write-ahead logging e, anche in questo caso, con un solo writer alla volta. Esegui sqlite3 memory.db "PRAGMA journal_mode;" per verificare la modalità attiva; wal è il valore che devi ottenere. Se visualizzi Error: database is locked, un altro processo detiene il write lock. Concedi quindi alla sessione un tempo di attesa con sqlite3 -cmd ".timeout 5000" oppure arresta prima il servizio dell'agente. La modifica manuale di un archivio vettoriale è diversa: lasciala alla libreria, perché embedding e testo devono rimanere coerenti tra loro.