Memoria persistente vs contesto effimero

Non tutto ciò che dici a un agente deve essere ricordato. Alcune informazioni sono stabili e utili nel tempo; altre appartengono solo al task corrente. Confondere questi livelli crea memoria sporca, istruzioni obsolete e rischi privacy.

Perché questa lezione conta

La memoria persistente sembra comoda: “ricordati come lavoro”. Ma se salvi dettagli temporanei, segreti o decisioni superate, le sessioni future peggiorano. La memoria va trattata come configurazione: corta, intenzionale, aggiornata.

Tre livelli

Memoria utente

Preferenze stabili:

• lingua preferita;
• tono delle risposte;
• stack ricorrenti;
• modo di ricevere riepiloghi.

Non dovrebbe contenere segreti o stato di progetto.

Memoria progetto

Regole stabili della repo:

• comandi;
• struttura;
• vincoli di deploy;
• pattern architetturali;
• policy di test.

Spesso è meglio versionarla in file, non affidarla solo alla memoria del tool.

Contesto di sessione

Informazioni temporanee:

• task corrente;
• file appena modificati;
• bug in analisi;
• decisioni non ancora confermate;
• output intermedi.

Queste vanno riassunte o scartate a fine lavoro.

Cosa non salvare mai

• API key;
• token;
• password;
• dati personali non necessari;
• informazioni soggette a NDA se non autorizzate;
• ipotesi non verificate presentate come regole.

Laboratorio guidato

Prendi dieci informazioni emerse in una sessione AI e classificale:

Informazione	Utente	Progetto	Sessione	Non salvare

Poi scrivi una policy:

Salviamo in memoria solo preferenze stabili.
Le regole di progetto vivono in AGENTS.md.
Lo stato del task resta nel riepilogo di sessione.
Segreti e dati personali non vengono salvati.

Output atteso

Una policy di memoria personale o di team, scritta in poche righe.

Deve rispondere a:

• cosa può essere ricordato;
• dove vive la memoria di progetto;
• quando aggiornare;
• cosa cancellare;
• cosa non salvare mai.

Checklist di verifica

• distinguo preferenza, regola e stato temporaneo;
• le regole di progetto sono versionate;
• non salvo segreti;
• so aggiornare o cancellare memoria obsoleta;
• il contesto di sessione non diventa verità permanente.

Errori comuni

Salvare troppo. Una memoria lunga e sporca peggiora le risposte.

Salvare ipotesi. Una diagnosi provvisoria non deve diventare regola futura.

Usare la memoria al posto della documentazione. Il team deve poter leggere le regole nella repo.

Collegamenti

• Modulo: Contesto e memoria nel progetto — lezione 25 del corso.
• Lezione precedente: MCP, tool servers e contesto strutturato.
• Prossimo modulo: Affidabilità: valutazione, sicurezza, costi.