Memoria persistente per l’AI: le soluzioni che si usano

Ogni conversazione con un modello di intelligenza artificiale inizia da zero. Chiudi la chat, la riapri il giorno dopo, e il modello non sa più chi sei, cosa stai facendo, quali decisioni avete già preso insieme. È il difetto strutturale che rende l’AI generativa uno strumento potente ma smemorato: brillante nella singola sessione, inutilizzabile come collaboratore continuativo se non gli costruisci attorno un’architettura di memoria.

Il tema è diventato centrale negli ultimi mesi, e attorno ad esso si è formata una piccola industria di soluzioni: knowledge base collegate via protocollo MCP, file di contesto versionati con Git, sistemi di memory nativi integrati direttamente nei modelli. Non sono equivalenti, non risolvono lo stesso problema, non servono agli stessi utenti. Vale la pena metterli in fila.

Perché i modelli AI non ricordano (e cosa significa davvero)

Un modello linguistico non ha memoria persistente per come la intendiamo umanamente. Ha una finestra di contesto, la quantità di testo che può “vedere” in una singola richiesta, e una volta chiusa la sessione quel contesto scompare. È come parlare con qualcuno affetto da amnesia anterograda: nella conversazione ricorda tutto, appena esci dalla stanza dimentica.

Non è un bug: è come sono costruiti i modelli. La “memoria” percepita in strumenti come ChatGPT o Claude viene simulata riportando testo nella finestra di contesto a ogni interazione. Il problema pratico, per chi usa l’AI come strumento di lavoro, è duplice: il contesto si frammenta tra strumenti diversi (una cosa in ChatGPT, una in Claude, una in Cursor), e le informazioni rilevanti (decisioni prese, preferenze di scrittura, glossari, dati aziendali) vanno riportate ogni volta.

Le soluzioni per costruire una memoria persistente vanno tutte nella stessa direzione: creare un archivio esterno consultabile dal modello, in modo che le informazioni rilevanti rientrino nella finestra di contesto quando servono. Cambia il “dove” e il “come”, non il principio.

Knowledge base in Obsidian collegate via MCP

La soluzione che sta emergendo con più forza tra professionisti e piccoli team è la knowledge base testuale in Markdown, tipicamente costruita con Obsidian, esposta ai modelli AI tramite il protocollo MCP (Model Context Protocol) rilasciato da Anthropic a fine 2024.

MCP è uno standard aperto che permette a un’applicazione client (Claude Desktop, editor come Cursor, IDE vari) di collegarsi a server locali che espongono dati e strumenti. Nella pratica: installi un server MCP che punta alla tua cartella Obsidian, e il modello può leggere, cercare e, se lo autorizzi, modificare le note.

Cosa serve per partire

1. Obsidian installato in locale con un vault dedicato alla knowledge base (una singola cartella con file .md).
2. Un client MCP-compatibile. Il più diffuso è Claude Desktop, ma anche Cursor e altri editor supportano MCP.
3. Un server MCP per Obsidian. In circolazione ce ne sono diversi open source: obsidian-mcp, mcp-obsidian e simili, installabili tipicamente via npm o pip.

Configurazione tipica (Claude Desktop)

Su Claude Desktop, la configurazione avviene modificando il file claude_desktop_config.json. Struttura di esempio:

{
  "mcpServers": {
    "obsidian": {
      "command": "npx",
      "args": [
        "-y",
        "obsidian-mcp-server",
        "/percorso/assoluto/al/tuo/vault"
      ]
    }
  }
}

Dopo il riavvio dell’applicazione, il modello ha accesso a strumenti come “cerca note”, “leggi nota”, “crea nota”. A quel punto puoi chiedere in linguaggio naturale: “Cerca nelle mie note tutto quello che ho scritto sul cliente X e riassumi le decisioni prese”, e il modello attinge alla knowledge base come farebbe un collaboratore che ha letto il tuo archivio.

A chi serve davvero

Questa soluzione è pensata per chi già lavora con appunti testuali strutturati: consulenti, professionisti indipendenti, piccoli team che documentano processi e decisioni in modo scritto. Non è per chi ha i dati sparsi tra Notion, Google Drive, email e WhatsApp senza un archivio testuale centralizzato. Il presupposto è che una knowledge base scritta esista già, o che tu sia disposto a costruirla.

File di contesto versionati con Git

Un approccio più leggero, molto diffuso tra chi lavora con AI su codice, è il file di contesto: un documento (o più documenti) di testo puro, versionato con Git insieme al progetto, che viene caricato manualmente o automaticamente all’inizio di ogni sessione. È il principio che guida strumenti come Claude Code, dove un file CLAUDE.md nella root del progetto viene letto automaticamente dal modello.

La logica è semplice: invece di ripetere a ogni sessione “usa questo stile, segui questa convenzione, il progetto ha questi vincoli”, scrivi tutto in un file di testo e lasci che sia il modello a leggerlo. Aggiornato il file, aggiornata la “memoria” della sessione successiva.

Come si costruisce un file di contesto utile

Un buon file di contesto contiene almeno queste sezioni:

• Descrizione del progetto: cosa è, chi lo usa, obiettivi.
• Convenzioni operative: stile di scrittura, standard di codifica, tono di voce, formattazione preferita.
• Vincoli e divieti: cosa NON deve fare il modello (es. non usare certi strumenti, non inventare dati, non modificare certi file).
• Decisioni prese: scelte architetturali o editoriali già consolidate, per non doverle rimettere in discussione ogni volta.
• Glossario: termini interni, sigle, nomi propri che il modello deve riconoscere.

Il file va tenuto sotto controllo versione (Git) come qualsiasi altro artefatto del progetto. Ogni modifica diventa un commit, ogni progetto ha il suo file, e la “memoria” del modello evolve con il progetto stesso. Su questo approccio applicato in modo sistematico, è utile la lettura del setup operativo di Claude Code descritto da Simone Coglitore.

Limiti dell’approccio

Il file di contesto risolve il problema della continuità dentro un progetto, non tra progetti diversi. Se lavori su dieci clienti in parallelo, ogni progetto avrà il suo file: non c’è una memoria trasversale. Il file cresce, e superata una certa dimensione (indicativamente qualche migliaio di parole) inizia a consumare una fetta significativa della finestra di contesto, riducendo lo spazio disponibile per il lavoro effettivo.

La memory nativa dei modelli (ChatGPT, Claude, Gemini)

Le grandi piattaforme conversazionali hanno introdotto negli ultimi mesi funzionalità di memoria nativa: informazioni salvate dal modello stesso, disponibili nelle sessioni successive senza che l’utente le riporti manualmente.

ChatGPT ha una funzione “Memory” attivabile dalle impostazioni: il modello annota informazioni ritenute rilevanti (preferenze, contesto professionale, progetti in corso) e le richiama automaticamente. Claude ha introdotto Projects, cartelle dove file e istruzioni restano persistenti tra conversazioni. Gemini ha meccanismi analoghi legati all’account Google.

Cosa risolvono e cosa no

Sono soluzioni comode per uso personale continuativo: eviti di ripetere sempre le stesse cose sul tuo ruolo, sulle tue preferenze, sui progetti in corso. Sono meno adatte quando la knowledge base è consistente (centinaia di documenti), quando servono controllo e versioning, o quando il contenuto è sensibile e non vuoi che venga memorizzato dal provider.

Restano due questioni sul tavolo: il controllo (le memorie native sono un archivio opaco, non un file che leggi e correggi) e la privacy (le informazioni vengono conservate sui server del provider). Per un uso professionale in cui la knowledge base include dati di clienti o informazioni riservate, il buon senso e in molti casi il GDPR spingono verso soluzioni locali.

Quale soluzione per quale esigenza

Non c’è una risposta universale. Un modo pragmatico di orientarsi è partire dall’uso reale:

• Uso personale, poche informazioni ricorrenti: la memory nativa di ChatGPT o Claude Projects basta. Zero configurazione, ritorno immediato.
• Lavoro su codice o su un progetto strutturato: file di contesto versionato in Git (es. CLAUDE.md, .cursorrules). Trasparente, controllabile, versionato.
• Knowledge base ampia, uso professionale continuativo: Obsidian + MCP. Richiede investimento iniziale nella struttura del vault, ma diventa un asset di lungo periodo.
• Team con dati aziendali strutturati: qui il discorso si complica e serve un’architettura ad hoc, tipicamente basata su RAG (retrieval-augmented generation) e database vettoriali. Non è materiale da configurazione fai-da-te.

Le tre soluzioni si combinano, non si escludono. Un professionista può usare la memory nativa per il quotidiano generico, file di contesto per ogni progetto attivo, e una knowledge base Obsidian collegata via MCP come archivio strutturale. Il valore emerge dall’architettura complessiva, non dal singolo strumento. Su come innestare l’AI dentro processi aziendali reali, senza subordinare il lavoro allo strumento, resta valido l’orientamento della guida pratica all’integrazione dell’AI nei processi aziendali.

Il vero collo di bottiglia non è tecnico

Le soluzioni descritte sono note, documentate, in molti casi gratuite. Il collo di bottiglia non è la tecnologia: è la disciplina di scrivere. Una knowledge base collegata via MCP funziona se dentro c’è qualcosa. Un file di contesto è utile se qualcuno lo aggiorna. La memory di ChatGPT diventa preziosa se le informazioni salvate sono corrette.

L’AI non trasforma un’organizzazione disordinata in un’organizzazione ordinata. Amplifica quello che c’è: se il materiale scritto esiste ed è strutturato, il modello lo usa e diventa utile. Se il materiale non esiste, nessuna configurazione MCP risolverà il problema. La memoria persistente dell’AI, alla fine, è la memoria scritta dell’organizzazione, con un livello di accesso in più. Su come questa impalcatura viene messa in produzione in una piccola realtà, offre spunti concreti la ricostruzione della pipeline modulare costruita con le Claude Skills e i casi d’uso concreti di Claude nel lavoro quotidiano.

Checklist di verifica prima di partire

1. Hai definito quale problema stai cercando di risolvere (continuità sul singolo progetto? archivio trasversale? preferenze personali)?
2. Il materiale scritto che vuoi rendere disponibile al modello esiste già in forma testuale, o va prodotto?
3. Hai valutato le implicazioni di privacy (soprattutto se il materiale include dati di clienti)?
4. Se scegli MCP: hai un client compatibile installato e testato (Claude Desktop o equivalente)?
5. Se scegli il file di contesto: è sotto controllo versione e c’è un responsabile del suo aggiornamento?
6. Hai deciso una convenzione per aggiornare la memoria (quando aggiungere, quando rimuovere, chi rivede)?
7. Hai testato che il modello legga effettivamente il contenuto atteso, con una richiesta mirata di verifica?

Domande frequenti

MCP è compatibile solo con Claude?

No. MCP è uno standard aperto rilasciato da Anthropic ma pensato per essere adottato da più applicazioni. Il supporto più maturo oggi è su Claude Desktop e in vari editor di sviluppo (Cursor, Zed, Windsurf), ma l’ecosistema si sta ampliando e altri provider hanno annunciato adesione al protocollo. La cosa importante da capire è che MCP definisce un modo standard di collegare fonti dati esterne a un modello: non è legato a un singolo fornitore.

Posso usare Notion invece di Obsidian?

Sì, esistono server MCP e integrazioni per Notion, Google Drive, database SQL e molti altri sistemi. Obsidian è particolarmente diffuso perché il vault è composto da file Markdown locali, semplici da versionare, indicizzare, migrare. Se la tua knowledge base è già in Notion, ha senso partire da lì con un connettore dedicato; se stai costruendo da zero, la scelta tra file locali e piattaforma cloud dipende da priorità di controllo, collaborazione e privacy.

La memory di ChatGPT è affidabile per uso professionale?

Dipende dal contenuto. Per preferenze generiche di lavoro e progetti personali funziona bene. Per informazioni riservate di clienti, dati aziendali sensibili o contenuti soggetti a GDPR, la memoria del provider è una scelta discutibile: non hai controllo granulare, non c’è versioning, e il materiale risiede sui server del fornitore. In questi scenari conviene una soluzione locale o un’architettura interna dedicata.

Serve saper programmare per usare MCP?

Per installare un server MCP esistente e configurarlo su Claude Desktop, no: basta seguire la documentazione, modificare un file JSON e riavviare l’applicazione. Per sviluppare un server MCP custom che si collega a sistemi aziendali proprietari, sì: serve competenza di sviluppo. La curva di ingresso per l’uso “consumer” è molto più bassa di quanto sembri dal nome del protocollo.

Quanto materiale posso caricare in una knowledge base collegata all’AI?

Non c’è un limite teorico alla dimensione dell’archivio: quello che conta è quanto materiale entra nella finestra di contesto in una singola richiesta. I server MCP tipicamente fanno ricerca e recupero mirato, restituendo al modello solo i documenti rilevanti per la query in corso. Questo permette di avere archivi molto ampi (migliaia di note) senza saturare il contesto, purché il sistema di ricerca funzioni bene.

Un punto di partenza, non di arrivo

Le soluzioni per dare memoria persistente all’AI sono in evoluzione rapida. Il quadro descritto qui è quello che si consolida oggi, ma sei mesi bastano perché emergano nuovi standard, nuovi client, nuove pratiche. Chi vuole muoversi in modo sensato parte dalla soluzione più semplice compatibile con il proprio bisogno, mette in produzione, osserva cosa funziona e cosa no, e stratifica solo quando la complessità è giustificata da un ritorno concreto. La memoria dell’AI è utile nella misura in cui è mantenuta: senza la disciplina di chi la aggiorna, resta un archivio morto collegato a un modello brillante.