Un agente che dimentica tutto a fine sessione va istruito da capo ogni mattina. Prima o poi chi ne costruisce uno deve rispondere a una domanda semplice: dove finisce quello che impara, e come lo ritrova?
Le risposte più comuni sono tre: file di testo, un database vettoriale che cerca per significato, oppure un database classico. Qui vediamo a cosa serve ciascuna, dove si rompe e come scegliere. Quello che diciamo su prodotti e ricerche di altri l'abbiamo controllato sulle loro pagine il 16 ottobre 2026.
Cosa vuol dire memoria persistente per un agente
Un modello linguistico non tiene niente fra una chiamata e l'altra. Quello che «sa» del tuo progetto sta nella finestra di contesto, che si svuota quando la conversazione finisce. La memoria persistente è tutto ciò che sta fuori dalla finestra e in cui l'agente può scrivere adesso e leggere dopo.
I lavori sono due. Scrivere è facile. Il difficile è ritrovare: quando parte un compito nuovo, l'agente deve riportare dentro le poche cose giuste, non tutto, perché ogni token caricato toglie spazio al lavoro.
Il team di ingegneria di Anthropic descrive un modo di farlo in un articolo del 29 settembre 2025 e lo chiama recupero «just-in-time». L'agente tiene dei riferimenti leggeri, come percorsi di file o ricerche salvate, e carica i dati con gli strumenti solo quando servono. L'esempio è Claude Code: i file CLAUDE.md entrano all'inizio, mentre glob e grep gli fanno aprire gli altri file solo quando il compito lo chiede. Lo stesso articolo lo mette a confronto con l'altra strada diffusa, il recupero con embedding fatto prima che il modello parta.
Prima strada: i file
La memoria più semplice è una cartella. L'agente scrive note in Markdown e poi elenca la cartella, cerca per parole e apre quello che sembra utile.
Sembra troppo semplice. Ma i modelli sono addestrati tantissimo sul codice, ed elencare, cercare con grep e leggere file è una cosa che sanno già fare bene.
Anthropic ci costruisce sopra. La sua API ha uno strumento di memoria (memory tool) che lavora su una cartella chiamata /memories: Claude ci può vedere, creare, modificare, rinominare e cancellare file, e la documentazione dice che, quando lo strumento è attivo, Claude guarda la cartella prima di cominciare un compito. Lo strumento gira dal lato client, quindi dove stanno davvero quei «file» lo decide la tua applicazione: una cartella sul disco, un database, uno spazio cloud.
C'è anche un esperimento pubblico che vale la pena conoscere. Il 12 agosto 2025 Letta ha raccontato che un agente su GPT-4o mini, con i soli strumenti per i file (grep, search_files, open e close) e le conversazioni salvate come file, ha fatto 74,0% su LoCoMo, un benchmark di memoria conversazionale a lungo termine. Letta l'ha confrontato col 68,5% dichiarato per la variante a grafo di un sistema di memoria specializzato. Prendilo per quello che è: il test di un'azienda, con pochissimo lavoro sui prompt, e un confronto contestato. La parte utile è la conclusione di Letta: la memoria dipende più da come l'agente gestisce il contesto che dal meccanismo esatto con cui recupera.
I file sono anche l'unica opzione di questa lista che una persona può aprire e correggere con un editor di testo. Quando l'agente salva una cosa sbagliata, ti serve.
Dove si rompono: una cartella su un computer si raggiunge solo da quel computer. Due agenti che scrivono insieme possono sovrascriversi. E la ricerca per parole trova parole: se la nota dice «corriere» e l'agente cerca «spedizione», non la trova.
Seconda strada: il database vettoriale
Un database vettoriale trasforma ogni pezzo di testo in un embedding, una lista di numeri che lo mette vicino ai testi di significato simile. Una domanda trova i passaggi più vicini anche se usano parole diverse. È lo schema classico del RAG.
È lo strumento giusto quando le parole cambiano davvero da un testo all'altro: migliaia di ticket di assistenza, una montagna di documenti che nessuno ha scritto pensando alla ricerca.
I costi si vedono nell'uso di tutti i giorni. Ogni scrittura passa da un embedding, e anche ogni ricerca. Le note lunghe vanno spezzate in pezzi, e la misura dei pezzi cambia cosa trovi. Quando il recupero sbaglia è difficile capire perché: un vettore non si legge, e «questo passaggio ha punteggio 0,81» non dice granché. E la somiglianza è debole proprio dove gli agenti passano molto tempo, sulle stringhe esatte. Un codice d'errore, un nome host, un codice prodotto o un cognome si trovano per parola, non per significato.
Poi c'è un problema meno visibile. La memoria di un agente cambia di continuo, con decisioni ribaltate e note corrette, e ogni modifica vuol dire rifare l'embedding.
Terza strada: un database classico
La terza risposta riguarda meno il modo di cercare e più tutto quello che ci sta intorno. Un database ti dà cose che una cartella non ha:
- più persone e più agenti che scrivono insieme senza pestarsi;
- permessi controllati a ogni lettura e scrittura, invece che affidati alle buone maniere del modello;
- lo storico delle modifiche, così una scrittura sbagliata si annulla;
- un indice full-text che si aggiorna mentre scrivi, così la ricerca per parole resta veloce anche quando la memoria cresce.
Il problema è la forma. Se infili la memoria in tabelle rigide, una riga per ogni fatto, l'agente non scrive liberamente e una persona non la legge. La soluzione di solito è ibrida: testo libero salvato come documenti dentro un database, che si occupa di accessi, versioni e indice.
Quindi «file o database» è una scelta finta. Tieni le note come testo che capiscono sia l'agente sia la persona, mettile in un database per le garanzie, e aggiungi i vettori dopo, solo se la ricerca per parole non basta.
Come scegliere
Poche domande risolvono quasi tutti i casi.
- Chi legge la memoria oltre al modello? Se una persona deve controllarla o correggerla, tienila in un testo che si apre.
- Quanti agenti e quante persone ci scrivono? Un agente su una macchina può vivere con una cartella. Di più vuol dire un database sotto.
- Come sono le domande? Nomi, codici e date vanno meglio con la ricerca per parole. Domande vaghe su un archivio grande e disordinato vanno meglio coi vettori.
- Quanto è grande? Qualche migliaio di note sta comodo in un buon indice di parole. Milioni di documenti sono un altro problema.
- Quanto spesso cambia? Più cambia, più costa tenere aggiornati gli embedding.
Se devi scegliere un server già pronto invece di costruirlo, la nostra guida su cos'è un server MCP per la memoria copre le domande pratiche, e come funziona la memoria di Claude Code mostra la strada dei file nella sua forma più semplice.
Cosa abbiamo scelto per Cobrain, e perché
Cobrain è l'ibrido descritto sopra. Ogni nota è un file Markdown in cartelle che ordini tu, salvato in un database che applica i permessi a ogni lettura e scrittura, uguale per il sito e per le AI. Le note sono cifrate con una chiave per ogni brain. Ogni modifica tiene la versione precedente, e puoi esportare tutto come file normali.
Gli embedding li abbiamo lasciati fuori di proposito. Un brain tipico è pieno di identificatori esatti (nomi di clienti, codici d'errore, nomi host, date nei nomi dei file), e quelli si trovano per parola. Così la ricerca è un indice di parole che si aggiorna mentre scrivi. L'AI sceglie due o tre parole chiave, riceve un elenco breve di note con le righe che corrispondono, apre quella giusta e, quando le serve il quadro intero, carica tutta la cartella di un cliente o di un progetto. I passaggi sono spiegati in come cerca l'AI, e quanto costa in token sta nella pagina sui costi di contesto.
I vettori troverebbero di più in qualche caso? A volte sì. Preferiamo una ricerca che sappiamo spiegare, e aggiungere l'altra solo se domande vere continuano a tornare a vuoto.
Domande rapide
Cos'è la memoria persistente per gli agenti AI? Tutto ciò che sta fuori dalla finestra di contesto del modello e in cui l'agente può scrivere durante una sessione e leggere in una successiva: file, un database vettoriale, un database classico o un misto.
Un agente AI ha bisogno di un database vettoriale per la memoria? Non per forza. Gli agenti se la cavano bene con file e ricerca per parole, e la memoria di un progetto è piena di nomi e codici esatti. I vettori aiutano soprattutto su raccolte grandi di testi scritti in modo libero.
Cos'è il memory tool di Claude?
Uno strumento dell'API di Anthropic che fa vedere, creare, modificare, rinominare e cancellare a Claude dei file in una cartella /memories. Gira dal lato client, quindi dove stanno quei file lo decide la tua applicazione.
Meglio file o database per la memoria di un agente? Di solito tutti e due: note in testo leggibile, salvate in un database che si occupa di permessi, versioni, scritture contemporanee e indice di ricerca.
