Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Ho già raccontato perché la memoria di un LLM non sta in un solo file, e perché il contesto è l'asset che il PM deve costruire. Erano articoli sul perché.
Questo parla del come. Aprirò il cofano del mio motore di contesto — il sistema che vive in una cartella 02-CONTEXT/ del mio vault — e seguirò una missione reale dall'inizio alla fine. A ogni tappa, spiegherò il blocco che entra in gioco: la missione, il focus, le direttive, il todo, la coda offline, e i tre tipi di memoria.
L'obiettivo: che uno sconosciuto che non ha mai visto questo sistema capisca come è organizzato, e soprattutto perché è organizzato così. Perché ogni cartella, ogni file, risponde a un problema che ho incontrato lavorando con un'IA su argomenti che durano settimane.
Il principio di partenza: il disco è la memoria
Una cosa da stabilire prima di tutto il resto. In questo sistema, il sistema di file è la memoria principale dell'IA. Non la conversazione.
Una conversazione con un LLM è volatile. Si chiude la scheda, tutto è perduto. La finestra di contesto è finita, e più la si riempie, più l'attenzione degrada — è il fenomeno del Lost in the Middle di cui ho parlato altrove. Quindi invece di tenere tutto nella conversazione, si scrive tutto su disco, in file suddivisi per natura di informazione. E a ogni sessione, si ricarica solo lo stretto necessario.
Un contesto è quindi una cartella. Una cartella = una missione. Non c'è nessuna memoria trasversale implicita tra due contesti: ciò che l'IA sa del progetto A non filtra verso il progetto B. Ogni missione ha la propria testa.
Ecco, semplificato, com'è fatto un contesto:
<contesto>/
├── 00_mission/ ← il quadro stabile: perché siamo qui, le regole
├── 01_active/ ← lo stato vivo: dove siamo, oggi
├── 02_checkpoints/ ← le foto di tappa
├── 03_sources/ ← la materia grezza
├── 04_notes/ ← le idee estratte, collegate tra loro
├── 05_memory/ ← la memoria consolidata
├── 06_index/ ← l'indice macchina, per orientare l'IA
└── 07_outputs/ ← i deliverable
La logica di archiviazione è semplice ma rigorosa: ciò che è stabile (la missione, le regole) è separato da ciò che cambia a ogni sessione (lo stato corrente), a sua volta separato dalla materia grezza (le fonti), da ciò che se ne estrae (le note) e da ciò che si produce (i deliverable). Niente è mescolato. Vedremo che questa separazione non è cosmetica: è lei che rende il ragionamento tracciabile nel tempo.
Per rendere tutto questo concreto, seguirò una missione che ho davvero condotto (un esempio semplice, per facilitare la lettura): PM016 — scrivere dei post LinkedIn a partire da tre articoli che ho pubblicato in una rivista di marketing. Una missione di produzione di contenuto, breve, ma che attiva la maggior parte dei blocchi.
Aprire un contesto: cosa carica l'IA, e cosa lascia su disco
Avvio una sessione. La prima cosa che fa l'IA non è leggere tutto. È leggere un file di configurazione: il manifesto di caricamento (load_manifest.json). Questo file le dice cosa caricare, e cosa lasciare invece su disco.
Contiene tre liste:
always_load— il nucleo, caricato ogni volta. La missione, lo scope, le direttive, i rischi, lo stato corrente, il piano, il focus, il todo, le decisioni, le contraddizioni, la scheda di ripresa, la sintesi.load_on_demand— tutto ciò che resta su disco e viene caricato solo se il compito lo richiede: le decine di fonti, le note atomiche, i diari di sessione.- Dei limiti di sicurezza: non più di 12 file attivi, circa 1200 righe massimo nella finestra di contesto del LLM.
È un vassoio da chirurgo. Gli strumenti essenziali sono già disposti; gli altri sono a portata di mano, ma non si copre il tavolo. Un esperto umano non rilegge tutto il suo fascicolo prima di ogni riunione — ha interiorizzato l'essenziale e va a cercare un documento preciso quando ne ha bisogno. Un LLM non può interiorizzare: ha solo ciò che gli si dà. Da qui l'importanza di dargli il sottoinsieme giusto, non tutto.
In pratica, l'apertura di un contesto avviene tramite un comando — scrivo /context_use pm016 — e l'IA esegue il manifesto: legge il nucleo, legge l'ultimo checkpoint, ed è operativa. Sa dove siamo senza che abbia dovuto rispiegare niente.
La missione e il focus: lo scopo non è la stessa cosa dell'attenzione
Zoom sulle due cartelle di testa — quella stabile e quella viva:
00_mission/ ← il quadro stabile
├── mission.md lo scopo (non cambia)
├── scope.md il perimetro
├── directives.md come deve lavorare l'IA
├── risks.md le minacce da monitorare
└── glossary.md il vocabolario della missione
01_active/ ← lo stato vivo (cambia a ogni sessione)
├── focus.md l'attenzione del momento
├── current_state.md dove siamo
├── current_plan.md dove andiamo
├── todo.md le azioni future
├── decisions.md ciò che è stato deciso
├── contradictions.md ciò che non torna ancora
├── resume_work.md la scheda di ripresa
└── offline.md la casella di posta
Ecco la prima sottigliezza, e probabilmente la più importante da capire.
Ci sono due file che sembrano «ciò su cui si lavora», ma che non hanno niente in comune.
Il primo è la missione (00_mission/mission.md). È lo scopo. È stabile. Per PM016, la missione si esprime in una frase: «scrivere dei post LinkedIn basati sui tre articoli che ho pubblicato nella rivista n°16». Questa frase non cambia per tutta la vita del contesto. È la rotta. Il file vive in 00_mission/, la cartella delle cose stabili.
Il secondo è il focus (01_active/focus.md). È l'attenzione del momento. Cambia a ogni sessione, a volte più volte in una sessione. Il focus è «oggi, lavoriamo sulla suddivisione delle idee dell'articolo 2 in post distinti». Non è lo scopo — è il sotto-problema su cui si punta il riflettore adesso. Il file vive in 01_active/, la cartella delle cose vive.
Perché separarli? Perché confondere lo scopo e l'attenzione è il modo migliore per deviare. Se l'IA prende il focus del giorno per lo scopo della missione, rischia di ridefinire tutta la missione attorno a un dettaglio. Al contrario, se ha solo lo scopo sotto gli occhi, è troppo vaga: «scrivi dei post LinkedIn» non dice su cosa ci si concentra in questo istante. La missione dà la direzione, il focus dà la profondità di campo. Si può rifare il focus dieci volte senza mai toccare la missione. È esattamente come un umano: il tuo ruolo (la tua missione) non cambia perché passi il pomeriggio su un compito preciso (il tuo focus).
Attorno alla missione, in 00_mission/, si trovano altri tre file strutturanti.
Lo scope delimita ciò che è nel perimetro e ciò che non lo è — la barriera contro la deriva del soggetto.
I rischi (risks.md) sono la griglia delle minacce che pesano sulla missione. Per PM016 è modesto; ma su una vera opportunità prodotto, questo file segue i quattro grandi rischi di Marty Cagan — valore, usabilità, fattibilità, viabilità business. L'idea: tenere costantemente sotto gli occhi le domande che possono far fallire il progetto, e spuntare ogni rischio man mano che un elemento lo illumina o lo aggrava. Una sezione vuota = un rischio ancora non documentato, quindi un punto cieco assunto.
Il glossario (glossary.md) fissa il vocabolario della missione, affinché le stesse parole mantengano lo stesso significato dall'inizio alla fine. È lo stesso riflesso del mio contesto condominio, dove avevo finito per esternalizzare tutti i termini tecnici e gli acronimi in un file dedicato: senza questo, ognuno — l'umano come l'IA — finisce per usare le stesse parole con significati diversi.
Un punto importante su tutti questi file, e forse il più controintuitivo del sistema: non si riempiono tutti insieme all'avvio. Si riempiono progressivamente, nel corso degli scambi. E «scambio» non significa solo «portare un documento». La maggior parte delle volte, significa parlare. Discuto con l'IA, penso ad alta voce, le do un contesto che ho in testa — ed è lei a mettere al posto giusto questo flusso: questo punto è un rischio di viabilità, questo termine merita una voce di glossario, questa frase delimita lo scope. Un rischio non scritto diventa una riga in risks.md perché l'ho menzionato parlando, non perché ho aperto il file per riempirlo. È qui che il contesto cessa di essere una cartella da classificare e diventa un segretario particolare che prende nota di ciò che penso ad alta voce.
Le direttive: codificare una conoscenza che l'IA non ha
Altro file del nucleo stabile: le direttive (00_mission/directives.md).
Una direttiva non parla del soggetto della missione. Parla del modo di lavorare. È la differenza tra gli ingredienti e la ricetta.
Un esempio tratto da un altro dei miei contesti, dove faccio trattare centinaia di mail di condominio: «quando due persone portano lo stesso cognome, usa il senso dell'email per indicare il loro nome e la loro azienda» (due prestatori avevano lo stesso cognome). Non è un'informazione sul condominio. È una regola di trattamento. Codifica una conoscenza che solo io possiedo, e che l'IA applica poi sistematicamente — senza dimenticare, senza stancarsi.
Per PM016, una direttiva tipica sarebbe: «ogni post deve difendere un'unica idea atomica, mai un riassunto dell'intero articolo». È un vincolo di produzione che stabilisco una volta, e che vale per i ventisette post.
Le direttive sono nel nucleo always_load: vengono quindi ricaricate a ogni sessione. Una regola stabilita in settimana 1 si applica ancora in settimana 6, senza che debba ripeterla. È cumulativo. Più una missione avanza, più le sue direttive si affinano, e più l'IA lavora come me.
Dettaglio d'uso: per aggiungere una direttiva nel corso della conversazione, basta che io prefissi il mio messaggio con alpha directive : ... e l'IA la consoliderà nel file. Esistono una manciata di parole chiave come questa (decision :, contradiction :, todo :, checkpoint, fine sessione) — scorciatoie per archiviare un'informazione nel file giusto senza dirlo esplicitamente. Sono solo comodità; il cuore del sistema sono i concetti, non le parole chiave.
Il todo: le azioni future non inquinano il ragionamento presente
Il todo (01_active/todo.md) è un file semplice ma che risolve un problema reale.
Quando si lavora su un argomento, idee di azioni future emergono continuamente. «Bisognerà verificare questo dato.» «Dovremmo declinare questo post in carosello.» «Ricordarsi di rileggere la versione inglese.» Se si lasciano queste azioni fluttuare nella conversazione, succedono due cose: o le si dimentica, o inquinano il ragionamento in corso tirando l'attenzione in tutte le direzioni.
Il todo è il posto dove posare queste azioni per non doverle più tenere in testa. È un backlog. Ogni compito ha un identificativo (T-NNN) e uno stato. Lo si alimenta scrivendo todo : .... E poiché fa parte del nucleo caricato a ogni sessione, nessuna azione si perde tra una sessione e l'altra.
È la stessa logica di tutto il resto: portare un'informazione fuori dalla memoria volatile della conversazione per posarla in un posto stabile e nominato.
La coda offline: parlare al contesto quando dorme
Ecco un blocco a cui non si pensa all'inizio, e che diventa presto indispensabile: il file offline (01_active/offline.md).
Il problema: le idee non vengono solo quando si è seduti davanti all'IA, con il contesto aperto. Un'idea su PM016 mi attraversa la mente una domenica sera, quando non ho nessuna voglia di aprire una sessione completa. Dove metterla?
Nel file offline. È una casella di posta. Vi deposito un messaggio — un'idea, una correzione, un promemoria — senza aprire una sessione. Il file dorme insieme al contesto.
Poi, all'avvio della sessione successiva, il workflow prevede un passaggio preciso: se offline.md non è vuoto, trattarne il contenuto come un messaggio in arrivo, poi svuotare il file. L'IA legge il mio messaggio della domenica sera come se l'avessi appena scritto, lo prende in considerazione, agisce, e rimette la casella a zero. Niente si perde, e non ho dovuto aprire una sessione solo per annotare un'idea.
È un modo asincrono di parlare a un contesto. Il contesto diventa qualcosa a cui posso lasciare un messaggio, anche quando non è «acceso».
Le fonti e le note: dalla materia grezza alla conoscenza riutilizzabile
Fino a qui, abbiamo parlato del pilotaggio. Ora, il contenuto.
Zoom sulla catena che va dal grezzo alla conoscenza:
03_sources/ ← la materia grezza
├── SRC-001.md la scheda (trascrizione utilizzabile)
└── raw/ l'originale tal quale (il PDF, illeggibile dall'IA)
04_notes/ ← la conoscenza estratta
├── atomic/ un'idea = una nota (NOTE-0001, 0002…)
└── thematic/ le sintesi che collegano più note
Quando porto della materia — per PM016, il PDF dei tre articoli — non va a riversarsi nella conversazione. Va in 03_sources/, la materia grezza. Ogni fonte riceve una scheda e un identificativo (SRC-001, SRC-002…). Il PDF originale, illeggibile direttamente dall'IA, è conservato tal quale in una sottocartella raw/, e una scheda .md ne dà una trascrizione utilizzabile. Si sa sempre da dove viene ogni informazione.
Poi arriva il lavoro di estrazione. A partire dalle fonti, l'IA produce delle note atomiche in 04_notes/atomic/. Una nota atomica cattura un'unica unità di pensiero: un fatto, una definizione, un'ipotesi, un pattern, una contraddizione. Per PM016, l'analisi dei tre articoli ha prodotto ventidue note. Eccone una, reale:
NOTE-0022 — Decidere senza diventare ciechi: il cursore quadro vs autonomia Pattern: dare a una responsabilità abbastanza autorità per arbitrare crea un nuovo rischio — la centralizzazione cieca. […] La coerenza non è l'omogeneità. Esempio Nike: universi molto diversi (running, calcio, basket…) coesistono senza uniformizzare tutto.
Questa nota è autonoma: si capisce senza riaprire l'articolo. È sourced (punta a SRC-001, pagina 67). Ed è collegata: in fondo, una sezione ## Backlinks la connette alla nota tematica the-brand-man. È Zettelkasten — unità di pensiero collegate tra loro, dove l'intelligenza emerge dai collegamenti, non dall'accumulo.
C'è una regola che mi impongo qui, e che è più sottile di quanto sembri: una nota atomica non è mai materia pre-formattata per il deliverable. Anche se lo scopo della missione è produrre dei post LinkedIn, una nota non deve essere un «aggancio» o una «punch line». La nota cattura una conoscenza neutra e vera. La messa in forma al servizio dell'obiettivo avviene solo nei deliverable. La catena è rigorosa: sources (grezzo) → notes (conoscenza neutra) → outputs (deliverable orientato). Finché siamo nelle note, lo scopo della missione non ha ancora voce in capitolo. Altrimenti si avvelena la propria materia prima.
Questa regola sembra rigida. In realtà, è lei che rende le note potenti — perché una conoscenza neutra è agnostica rispetto al deliverable, quindi riutilizzabile per qualsiasi esso sia.
Prendiamo una missione prodotto invece di PM016. A partire dallo stesso insieme di note atomiche — una sfida cliente, un vincolo di adozione, un pattern di mercato — posso generare supporti molto diversi: un pitch per un comitato di direzione, una documentazione di supporto, un articolo di blog, una sales narrative, un onboarding. Ogni deliverable pesca e combina i blocchi di cui ha bisogno in questo corpus comune. Se avessi formattato queste note per il pitch, servirebbero solo al pitch. Tenendole neutre, servono a tutti e cinque. La messa in forma, l'angolo, il tono: tutto questo arriva all'ultimo momento, in 07_outputs/, una volta che si sa quale deliverable si produce.
E la riutilizzabilità non si ferma alla missione. I contesti non sono silos stagni. Una nota prodotta per un contesto può illuminarne un altro — perché si possono collegare contesti connessi tra loro. Posso persino aprire un contesto per andare ad auditarne un altro: scorrere le sue note e individuare le buone idee da riprendere. Un blocco di conoscenza scritto una volta può così alimentare un deliverable oggi, un altro domani, e una decisione in un terzo contesto tra sei mesi. È esattamente la promessa di partenza: il deliverable è consumabile, la nota è un asset.
Quando più note convergono, si scrive una nota tematica in 04_notes/thematic/ — una sintesi di un angolo o di una tensione. Per PM016, una per articolo.
Le tre memorie: episodica, semantica, e le foto di tappa
Zoom sui tre luoghi di memoria — tre scale temporali:
05_memory/
├── journal/ ciò che è successo, giorno per giorno (la storia)
└── synthesis.md ciò che se ne ricava (la lezione)
02_checkpoints/ lo stato completo in un dato istante (la foto di ripresa)
È qui che si gioca la seconda grande sottigliezza del sistema. Un cervello umano non ha una memoria, ma ne ha più d'una, che funzionano a scale temporali diverse: quella che ricorda ciò che succede adesso, quella che conserva gli eventi vissuti, e quella che consolida i saperi duraturi. Il sistema riproduce questa architettura con tre oggetti distinti, che non bisogna assolutamente confondere.
Il diario (memoria episodica). In 05_memory/journal/, un file per giornata di lavoro. Racconta ciò che è successo: cosa si è fatto quel giorno, in quale ordine, quali decisioni sono state prese, cosa ha intralciato. È il racconto cronologico. Vi si va quando ci si chiede «ma cosa avevamo deciso martedì, e perché?». È datato, sequenziale, mai riscritto.
La sintesi (memoria semantica). In 05_memory/synthesis.md, un solo file. Non racconta ciò che è successo — condensa ciò che se ne ricava. Le conclusioni stabili, le convinzioni validate, i pattern estratti da decine di sessioni. È la memoria a lungo termine, liberata dalla cronologia. Un product manager senior non riscopre a ogni progetto che gli utenti mentono nelle interviste: è diventato un sapere semantico. La sintesi è questo. Fa parte del nucleo caricato a ogni sessione, perché è il condensato più utile per riprendere il filo.
I checkpoint (le foto di tappa). In 02_checkpoints/, un file per giorno al massimo. Un checkpoint è un'istantanea completa dello stato del contesto in un dato momento. L'angolo di redazione è molto preciso, ed è questo che ne fa il valore: «se un LLM arrivasse adesso senza aver letto niente, cosa deve sapere per riprendere senza errori e senza ricominciare da capo?» Il checkpoint è la rete di sicurezza della ripresa.
La distinzione diario/sintesi è quella che sfugge più spesso. Il diario è la storia; la sintesi è la lezione. Si hanno bisogno di entrambi, esattamente per la ragione che mi aveva spinto, nei miei primissimi tentativi, a separare l'aggregazione da un log cronologico: volevo sia sapere dove siamo (la sintesi) sia poter risalire il filo (il diario). Sovrascrivere l'uno con l'altro significa perdere o la memoria o la tracciabilità.
Ed è precisamente questo che rende il sistema auditabile. Un cervello dimentica — è la sua forza. Un sistema di file, lui, non dimentica niente. Dalla sintesi, si risale al checkpoint. Dal checkpoint, ai diari. Dai diari, alle note. Dalle note, alle fonti grezze. Quando qualcuno chiede «perché questa decisione?», la risposta non è mai «perché l'IA lo ha detto». È una catena di prove: fonte → nota → decisione.
Il ciclo di una sessione, dall'inizio alla fine
Ora che abbiamo i blocchi, ecco il film completo di una sessione su PM016.
All'avvio. L'IA legge il manifesto, carica il nucleo, legge l'ultimo checkpoint. Verifica il file offline: se contiene un messaggio che ho lasciato tra due sessioni, lo elabora poi lo svuota. In pochi secondi, sa dove siamo. La scheda di ripresa (resume_work.md) le dà persino la prima azione da fare.
Durante la sessione. Si discute — spesso ad alta voce, davanti allo schermo. E nel corso della conversazione, l'IA archivia in continuo. Arriva una nuova fonte → 03_sources/. Emerge un'idea duratura → una nota atomica in 04_notes/. Una decisione è presa → decisions.md. Una contraddizione emerge → contradictions.md (non la si liscia artificialmente, la si tiene visibile). Un'azione futura → il todo. Ogni volta che un file viene creato, il README.md della sua cartella e l'indice macchina sono aggiornati. Il contesto si tiene costantemente aggiornato, senza sforzo da parte mia.
A fine sessione. Scrivo /context_close. L'IA avvia il rituale di chiusura: scrive il diario del giorno, aggiorna lo stato corrente e la scheda di ripresa, promuove verso la sintesi ciò che merita di diventare duraturo, e crea un checkpoint se si raggiunge una soglia. Poi fa il commit di tutto. La sessione successiva potrà riprendere esattamente dove questa si è fermata.
Esiste anche una compattazione a metà percorso (/context_push): quando lo stato corrente si gonfia, quando il todo diventa illeggibile, o quando si gira in tondo, si condensa, si deduplica, si priorizza, si archivia ciò che non serve più — senza mai perdere la tracciabilità.
Ma il /context_push ha un ruolo ancora più vitale, ed è una trappola in cui si cade inevitabilmente quando si scopre il sistema. Quando una sessione dura a lungo, la conversazione finisce per superare la finestra del LLM. A quel punto, il LLM fa la sua compattazione: riassume silenziosamente gli scambi più vecchi per fare spazio. E tutto ciò che non era ancora stato scritto su disco in quel momento — una decisione evocata oralmente, un'idea lanciata di passaggio, una sfumatura importante — viene raschiato, deformato, o puramente perso. Il LLM non ti avverte; crede di aver conservato l'essenziale, ma è lui ad aver scelto cosa fosse essenziale.
Il /context_push è la contromisura: forza la persistenza su disco prima che il LLM compatti la sua memoria di lavoro. Facendo push regolarmente, si garantisce che tutto ciò che conta sia già scritto nei file — nel posto giusto, sourced, tracciato — quindi che la compattazione del LLM non faccia più perdere niente di importante. È il principio fondatore dell'articolo, applicato nel corso della sessione: ciò che vive solo nella conversazione è in bilico; solo ciò che è su disco è davvero memorizzato.
L'oblio senza la perdita
Un ultimo punto, perché dice molto della filosofia del sistema. Non c'è nessuna cancellazione brutale.
Quando un'informazione non è più utile, non si cancella. La si toglie dal caricamento predefinito, la si compatta, o la si archivia. Quando un'idea ne sostituisce un'altra, non la si sovrascrive: la si contrassegna superseded, si tiene il vecchio identificativo, e si fa puntare il vecchio verso il nuovo. Si cancella davvero solo in caso di errore manifesto o di duplicato non ambiguo.
Perché tante precauzioni? Perché l'auditabilità è tutto il valore del sistema. Il giorno in cui una convinzione prodotto deve essere difesa, devo poter risalire fino alla sua fonte, anche se risale a due mesi fa ed è stata «superseded» nel frattempo. Un ragionamento di cui si è cancellata la storia non è più un ragionamento — è un'opinione senza prove.
Cosa è davvero il contesto
In fondo, questo motore di contesto non è un sistema di archiviazione. È un'architettura di memoria per un'intelligenza che non ne ha nativamente.
Ogni blocco risponde a un limite del LLM: il manifesto risponde alla finestra finita; le tre memorie rispondono all'oblio tra sessioni; le note atomiche rispondono al Lost in the Middle; la separazione fonti/note/deliverable risponde al bisogno di tracciabilità; il file offline risponde al fatto che il pensiero non si ferma quando la sessione si chiude.
E il risultato è ciò che descrivevo nei miei articoli precedenti: il deliverable non è più il punto di partenza del lavoro, è un sottoprodotto. Ciò che ha valore è il contesto stesso — questa memoria strutturata, tracciabile, riutilizzabile, che si arricchisce sessione dopo sessione e finisce per produrre molto più di ciò che gli si chiede.
Per PM016, lo scopo era ventisette post LinkedIn. Ma ciò che rimane, una volta i post pubblicati, è un contesto: ventidue idee atomiche collegate, tre sintesi tematiche, fonti tracciate. Una materia che potrò riaprire tra sei mesi per un tutt'altro deliverable. Il post era l'obiettivo. Il contesto è l'asset.
Per saperne di più
Dal file unico al sistema di contesti: perché la memoria di un LLM non sta in un solo documento Il PM come architetto del Contesto Un file, qualche direttiva, e Claude fa il resto — come ho strutturato 500 email senza fatica Cos'è una nota atomica? Cos'è una nota tematica?