# Esperimento — Memoria condivisa multi-agente ### Documento base · v0.11 · 28/06/2026 > **Scopo di questo file.** È la base del cantiere. Raccoglie tutto ciò che è emerso nella sessione del 27/06/2026, così che una chat nuova (Elon, Bill o Adrian) possa riprendere a freddo senza ricostruire niente. Si affina nel tempo: ogni sessione che tocca il tema aggiorna qui. > **Stato della decisione — GO.** Il **27/06/2026 Mauro ha deciso: si parte.** L'architettura (vedi sotto) è completa; tutte le questioni sul *come* sono chiuse. Resta un esperimento — può sbagliare, rallentare, essere messo in pausa o buttato: "partire" non gli toglie questa libertà, gliela dà come scelta. Nessuna scadenza imposta; il ritmo lo detta Mauro. --- ## 0. Cos'è questo esperimento (e cosa NON è) - **È** un esperimento puro: costruire una cosa propria, "quasi arte", il cui valore è la costruzione stessa. Vincolo scelto da Mauro, nessun pubblico, può sbagliare e buttare via. Coerente con *"io vado per la mia strada, poi quello che succede succede"*. - **NON è** un sostituto di Elon. Elon (chat su Supabase) continua a funzionare. Questo vive accanto, come sandbox. - **NON tocca** il sistema di produzione: greenfield, da zero. Niente Supabase/kernel/cron esistenti modificati finché non si decide diversamente. - **Tutto Python.** Esecuzione via Claude Code. Mauro progetta e dirige; non scrive il codice. - **Modulare per sostituzione**: si attaccano e staccano pezzi, si sostituiscono con versioni migliori quando escono. Non si reinventa la ruota. - Include una **componente permanente di ricerca e studio** sulle novità del settore — non un di più, è il carburante che la modularità rende azionabile. --- ## 1. Principi guida 1. **Architetto-orchestratore.** Mauro decide cosa costruire e perché, definisce specifiche e trade-off, valuta i risultati. L'esecuzione (codice) è di Claude Code. È la divisione del lavoro scelta, non una mancanza. 2. **Le cuciture sono il valore.** In un sistema modulare ciò che conta non sono i pezzi, sono le **interfacce** fra i pezzi. Un contratto pulito per "memoria" permette di mettere Mem0 oggi, Zep domani, la-cosa-di-settembre dopodomani senza toccare il resto. 3. **Il collo di bottiglia non è l'architettura: è la curatela.** Lezione di Albert e confermata dal campo nel 2026. Il retrieval migliore non guarisce la disciplina di alimentazione. La parte difficile (giudizio editoriale su cosa tenere) resta umana. 4. **Stato, non log.** La memoria conserva stato corrente, principi vivi, storia forense. Non diari verbosi. 5. **Puntatori, non contenuto** (per le mappe/indici). Una mappa rimanda, non racconta. 6. **Fatti vs inferenze.** I fatti dichiarati si registrano come tali; le inferenze si etichettano. Mauro ha diritto di rifiutare una diagnosi senza giustificarla. 7. **Distinguere "non in contesto" da "non esiste".** Errore di ragionamento emerso il 27/06: prima di dire *"probabilmente non c'è"*, si interroga la fonte. Vale per qualunque architettura di memoria. --- ## 2. I tre strati del sistema > **Gli agenti sono un dato di fatto, non una variabile.** Elon (qui, in chat) · Bill e Adrian (Claude Code). *As-is.* Nessuno strato "modello" da scegliere, nessuna API esterna, nessun confronto di modelli/prezzi: fuori dall'esperimento. L'esperimento è una cosa sola — la **memoria condivisa**. L'architettura ha tre strati. **MCP** ha la cucitura già standardizzata dall'industria; **memoria** e **connessioni** sono il lavoro vero di design. ### 2.1 Tool / agentico (MCP) — *l'unico strato davvero nuovo: il cantiere* - **MCP** (Model Context Protocol) è lo standard dei tool intercambiabili: donato alla Linux Foundation (dic 2025), adottato da OpenAI/Google/Microsoft, ~10.000 server pubblici. Claude resta il client più maturo (connettori per URL con OAuth dal pannello). - È ciò che fa passare l'assistente da "parla" a "agisce" (es. il caso d'uso viaggio: cerca voli/hotel/costi → esiste già: Otto Travel, Expedia, Booking.com, lastminute, TomTom Maps…). - **"Fatto bene" porta tutto il peso**: OAuth, permessi stretti, trattare le descrizioni dei tool come input non fidato (rischi reali: *tool poisoning*, prompt injection). I connettori community/authless vanno trattati con cautela prima di toccare dati veri. ### 2.2 Memoria (SOTA) — *l'idraulica nuova; si monta per ultima* - È il salto più grosso ma tocca le fondamenta: si monta quando gli strati sopra sono stabili, non prima. - Vedi §3 per lo stato dell'arte e §4 per la scelta di substrato. ### 2.3 Connessioni / sinapsi — *come il sapere si organizza (non metafora: meccanismo)* - È la natura vera del second brain: un **vault stile Obsidian con linking bidirezionale gestito e potato dagli agenti**. Le "sinapsi" sono i **link bidirezionali** fra note (A linka B, e B sa di A senza nominarla); l'AI è ciò che li **crea, mantiene e pota** in continuo. - Distinzione importante da §2.2: la memoria/mappa è *recupero* (dove vivono le cose, come le trovo). Questo strato è *struttura* (come le cose si legano fra loro). Due funzioni diverse, entrambe gestite dagli agenti. - Eredita e alza a funzione continua il pattern Karpathy: ingerendo una nota nuova, l'agente la collega a quelle esistenti, aggiorna le pagine connesse, crea cross-link. - **Il rischio non è la densità, è il criterio.** In un sistema gestito da AI i link si formano comunque; il valore dipende da *con che regola* l'agente collega e scollega. È la stessa curatela di tutta la serata, spostata dal "cosa ricordo" al "cosa collego". Sinapsi che contano = connessioni **curate**, non solo dense. Un cervello iperconnesso e indiscriminato è un archivio insensato. - **Nodo di design aperto — la regola di linking** *(gemello della convenzione di frontmatter)*: quando l'agente collega due note? Per parola condivisa (facile, rumoroso) / per entità o concetto (più ricco) / solo oltre una soglia di pertinenza (curato, costoso). E speculare: quando **scollega** o segnala un link diventato falso? Il frontmatter dice *dove vive* una nota; la regola di linking dice *a cosa si lega*. #### Prior art — il grafo a due livelli (studiato il 28/06) Il modello "macro per navigare + drill per approfondire" è **il mainstream**, convergenza di due campi: memoria-agenti (GraphRAG, Zep/Graphiti, HippoRAG, A-MEM) e PKM (Zettelkasten/Obsidian). Non si inventa: si sceglie fra strade asfaltate. - **Gerarchia canonica:** episodi → fatti → entità → **comunità**. Le "comunità" (cluster tematici con riassunti precalcolati, da GraphRAG) sono il **livello macro**; entità e documenti sono il drill. Navigazione macro **senza chiamate LLM** (semantico + BM25 + traversata): in Graphiti P95 ~300ms, quasi a tempo costante a prescindere dalla dimensione → conferma che "spostarsi istantaneamente" regge e scala. - **Cos'è un nodo — due risposte convergenti:** *entità/concetto* (il nodo rappresenta la cosa, non contiene il documento → livello macro) **+** *nota atomica* (un'idea sola, ~300–500 parole → drill). I sistemi migliori tengono **entrambi i piani**: è esattamente il modello a due livelli. - **Granularità (regole rodate):** un'idea per nota; se ne contiene più d'una, spezza; note lunghe = difficili da collegare. Ma non troppo fine (nebbia di micro-nodi). Le *structure notes / MOC* sopra le atomiche governano le aree dense. La tensione "troppo fine vs troppo grosso" è il dibattito classico, non un nostro problema nuovo. - **Linking:** "collega quando è significativo; >50 link su una nota = troppi". L'ensemble usato dagli altri: co-occorrenza di entità + similarità semantica + overlap di tag + ragionamento LLM con **edge tipizzati** (supporta / contraddice / elabora), non un "collegato" generico. - **BIFORCAZIONE che resta a noi:** *motore a grafo* (Zep su Neo4j, più potenza di query) **vs** *grafo derivato dal markdown* (Obsidian: nodi+wikilink, il grafo è la somma dei link). Direzione preferita: **markdown + grafo derivato da script** — coerente con "vault = verità, indice derivato e usa-e-getta", file leggibili, niente DB grafo da mantenere; a scala personale basta. - **Due problemi da progettare (non da scoprire):** *risoluzione delle entità* (stessa persona in 10 note = 1 nodo; Graphiti de-duplica da sé) = il taxonomy-drift con nome preciso; *passata di consolidamento* periodica ("sleep": raggruppa e astrae). Conferma del filo: anche i framework SOTA mancano di glossario/lineage/entity-resolution → il layer di curatela (nostro) è il pezzo che manca ovunque. **Ordine di costruzione consigliato:** MCP per primo (un connettore solo, end-to-end) → memoria SOTA + strato connessioni per ultimi (le fondamenta). --- ## 3. Stato dell'arte della memoria persistente (2026) > Riferimento per non ri-cercare. Il ritornello del campo: **il collo di bottiglia degli agenti è la memoria, non il modello.** - **Svolta concettuale:** la finestra di contesto NON è un sistema di memoria. La memoria è un componente architetturale dedicato, separato dal prompt. - **Tassonomia a 3 livelli** (ricalca la scienza cognitiva): episodica, semantica, procedurale. - **Pattern standard:** durante la conversazione si **estraggono** i fatti e si indicizzano per utente/sessione/agente; a inizio sessione si **recuperano** i rilevanti per similarità semantica + keyword + entità, e si iniettano nel contesto. ### I poli framework - **Mem0** — favorito della community (~48k stelle). Pipeline a due fasi (estrazione LLM, poi rilevamento conflitti e aggiornamento grafo), backend ibrido vettori + knowledge graph. Forte su personalizzazione. - **Zep** — knowledge graph **temporale** (Graphiti). Specialità: il *tempo* — traccia come una cosa è cambiata, non solo lo stato finale. Top su accuratezza nei benchmark. - **Letta** (ex MemGPT) — architettura **OS-style**: l'agente gestisce la propria memoria come RAM/disco, pagina dentro/fuori dal contesto ciò che serve. Self-hostable. - (Locali/MIT: MemPalace e simili — fuori scope per la scelta locale di cui sopra.) ### La terza via — vault markdown (la più allineata a noi) - La memoria vive in un **vault di file markdown** su disco; l'agente legge e scrive i file. *"Il vault è la fonte di verità, l'agente è intercambiabile. I modelli cambiano, i markdown restano."* - Varianti: bottom-up (utente aggiunge AI alle note); **LLM Wiki di Karpathy** (gist apr 2026 — fonti grezze in `raw/`, l'LLM "compila" un wiki di pagine con riassunti/backlink/cross-link, recupero a livelli); top-down (Anthropic dentro Claude). - Vantaggi per noi: **è il substrato git** (cartella markdown → repo privato = versioning/backup/sync gratis); **nativo per Claude Code** (legge .md direttamente, senza plugin né MCP); **leggibile/auditabile** (apri il file, vedi cosa ha scritto l'agente); risparmio token (carica solo i file rilevanti). - Saggezza ereditata: tieni **separato il vault personale da quello dell'agente** (kepano) — lascia che l'AI faccia casino nel suo spazio, promuovi nel principale solo ciò che si è dimostrato utile; il vault è *spazio di pensiero, non database*. --- ## 3-bis. Il pattern Karpathy (LLM Wiki) — studiato a fondo > Fonte primaria: gist `karpathy/llm-wiki` (4 apr 2026, 5.000+ stelle), più il thread di commenti — dove stanno le lezioni d'ingegneria vere. È un *idea file*, volutamente astratto, da incollare al proprio agente che ne costruisce la versione specifica con te. ### L'idea centrale Non RAG (recupera-e-dimentica, ri-deriva la conoscenza a ogni domanda). Invece: l'LLM **costruisce e mantiene in modo incrementale un wiki persistente** — markdown interlinkato fra te e le fonti grezze. Una fonte nuova non viene solo indicizzata: viene letta, integrata, le pagine entità/concetto aggiornate, le contraddizioni annotate. La conoscenza si **compila una volta e si tiene aggiornata**, non si ri-deriva → è un *asset che si accumula*. Metafora di Karpathy: *Obsidian è l'IDE, l'LLM è il programmatore, il wiki è il codebase.* Tu curi le fonti, esplori, fai le domande giuste; l'LLM fa il lavoro sporco (riassumere, cross-referenziare, archiviare, mantenere coerenza). ### Le 3 + 3 + 2 **Tre strati:** `raw/` (fonti **immutabili**, fonte di verità, l'LLM legge ma non modifica) → `wiki/` (markdown generato e posseduto dall'LLM: riassunti, pagine entità, concetti, sintesi) → **schema** (`CLAUDE.md`/`AGENTS.md`: convenzioni + workflow; il file che trasforma un chatbot generico in un manutentore disciplinato; si co-evolve nel tempo). **Tre operazioni:** *ingest* (fonte → l'LLM legge, discute con te, scrive una pagina riassunto, aggiorna l'index, aggiorna 10–15 pagine collegate, appende al log) · *query* (cerca nel wiki → risposta con citazioni; **le risposte buone si archiviano come nuove pagine** — le esplorazioni si accumulano come le fonti) · *lint* (health-check periodico: contraddizioni, claim stantii, pagine orfane, concetti senza pagina, cross-ref mancanti, lacune da colmare). **Due file di navigazione:** `index.md` (catalogo orientato al contenuto: pagina + riassunto di una riga + categoria; letto **per primo**, poi si scende — regge a ~100 fonti / centinaia di pagine senza embedding) · `log.md` (cronologico, append-only, prefisso parsabile `## [data] ingest | Titolo`, grep-abile: `grep "^## \[" log.md | tail -5`). **Perché funziona:** la parte tediosa non è pensare, è il *bookkeeping*; gli LLM non si annoiano, toccano 15 file in un colpo → costo di manutenzione ≈ 0. Lignaggio: il Memex di Vannevar Bush (1945) — conoscenza privata, curata, dove i collegamenti valgono quanto i documenti; ciò che Bush non sapeva risolvere (la manutenzione) lo fa l'LLM. ### Le lezioni che contano per NOI (dal thread, non dal gist) 1. **Lo schema è l'80% del risultato.** Un `CLAUDE.md` vago → wiki vago. Vale un'ora a scrivere convenzioni precise: naming, formato dei riassunti, gestione conflitti, *quando creare una pagina nuova vs appendere*, checklist di lint. **Riformula i nostri "nodi a monte":** la convenzione di frontmatter e la regola di linking NON sono due cose separate — sono *parti dello schema*. **Lo schema è l'artefatto centrale dell'esperimento.** 2. **L'index/mappa lo ricostruisce uno script, non il modello.** Lezione di costo (un utente: il token-burn non era ragionamento, era ri-leggere `AGENTS.md`/index/raw a ogni sessione). Pattern vincente: **Python deterministico** per intake, indici, validazione, handoff compatti; l'LLM riservato a curatela/sintesi/giudizio. Affila il nostro "auto-deriva la mappa": deriva via script (os.walk/grep/FTS), non facendo ri-scansionare il modello. 3. **Il nemico vero è la memoria sicura-ma-stantìa.** Oltre ~giorno 60 il fallimento non è "dimentica" — è *ricorda con sicurezza cose superate e peggiora l'agente*. Difese da progettare dal giorno 1: **append, non sovrascrivere** (una ri-touche aggiunge a una sezione History, non riscrive); **`raw` immutabile** come ground truth (il wiki è sempre ri-derivabile); ogni claim ancorato con citazione alla fonte; drift detection (età-stantìa, link rotti, escalation di confidenza). È la curatela, in forma meccanica. 4. **Lint scoped, non monolitico.** Non una passata LLM su tutto il repo (O(n²), brucia contesto). Decomposizione: (a) contraddizioni per-fonte all'ingest, solo le ~8–15 pagine toccate; (b) **commit-gate deterministico** = Python che greppa `Status: Unresolved` su tutti i file → costo di contesto **zero**, scala a qualsiasi dimensione, blocca i conflitti senza scomodare il modello; (c) backstop periodico scoped ai nodi cambiati + vicini di grafo (1°/2° grado). Severità: soft / scope-mismatch / hard; hard blocca il commit finché l'umano non risolve. ← *soluzione pulita al nostro problema delle scritture a tre mani.* 5. **Correzione onesta al "il multi-agente è la parte mai fatta da nessuno".** Falso, ora. trip2g serve un vault via MCP dove **a fine sessione ogni agente scrive il proprio stato in un vault condiviso e gli altri interrogano un hub per vedere chi-fa-cosa** — è la nostra mappa/changelog, già in produzione. Smriti-MCP espone la memoria come servizio MCP che più agenti condividono. OpenClerk impone un confine duro fra markdown canonico / stato derivato / autorità di scrittura. **Quindi: copiare, non inventare.** Resta nostro solo il disegno dei tre agenti specifici, non il concetto. ### Critiche da tenere presenti - **Hallucination baked-in / "model collapse":** comprimendo e riscrivendo, un piccolo errore propaga sui link e si fossilizza in "fatto". Mitigazione = `raw` immutabile + citazioni + append-non-overwrite + spot-check contro le fonti. - **Taxonomy drift:** l'LLM non vincolato genera `company`/`Company`/`Business`/`Organization` in run diversi. Mitigazione = identità entità stabile (`entity_id` ≠ nome visualizzato) e/o ontologia seminata (strict/emergent/off). - **Scaling:** oltre `index.md` (~50–100k token / ~150–200 pagine) serve un layer di ricerca o un index derivato *throwaway* ("vault = verità, index = usa e getta": FTS5 trigram + embeddings, rebuildabile, con content-hash authority). ### Upgrade path noti (non ora) **qmd** (ricerca locale markdown di Tobi Lütke: BM25 + vettori + rerank, CLI + MCP) · **OKF / Open Knowledge Format** (standard markdown + YAML frontmatter, `type` richiesto, link = edge non tipati; per portabilità) · contraddizione-come-nodo · federazione multi-vault. --- ## 3-ter. Ciclo di vita della memoria — estrazione, raw, giorno/notte (studiato il 28/06) > Come la conversazione diventa nodi, e come la qualità si regge **senza** che Mauro sia il guardiano. Il meccanismo è il più consolidato del campo (Mem0, Zep, Letta): si copia. ### Cosa si estrae, e quando - **Fatti distillati, non il transcript.** "Un transcript grezzo non è memoria, è un log." L'LLM legge la conversazione e produce fatti atomici strutturati (entità, relazioni, timestamp). = il nostro "stato, non log". - **Quando: dopo, in background.** L'estrazione gira asincrona, fuori dal percorso caldo — non mentre l'utente aspetta. A fine conversazione, non durante. ### Il cuore: estrarre è metà; **riconciliare** è l'altra metà Non "estraggo e aggiungo". Per ogni fatto candidato, il sistema guarda **cosa esiste già** e decide un'operazione — **ADD / UPDATE / DELETE / NOOP** (deciso dall'LLM contro le memorie vicine). È questo che impedisce al grafo di diventare fanghiglia: "preferisco Python" (sess.1) + "usa Python non JS" (sess.5) → **un** nodo canonico aggiornato, non due in conflitto. *Estrarre i nodi senza riconciliarli con gli esistenti = accumulo cieco.* ### Chi garantisce la qualità (NON Mauro come guardiano in scrittura) Chiedere conferma a ogni estrazione era la soluzione **sbagliata**: rimette Mauro come collo di bottiglia → è il difetto di Forte/Zettelkasten che vogliamo eliminare (il sistema muore quando l'umano si stanca di approvare). La qualità la reggono **tre meccanismi automatici**: 1. **Riconciliazione** (ADD/UPDATE/DELETE/NOOP) — la maggior parte della qualità si gioca qui. 2. **`raw` immutabile** — se l'estrazione sbaglia, non è fatale: si ri-deriva dalla fonte. L'errore è **reversibile per costruzione**. 3. **Consolidamento periodico** — fonde, ripulisce, segnala contraddizioni. Lo fa il lint, non Mauro. Ruolo di Mauro, ridefinito: **editore per eccezione**, non guardiano. Come con git — i commit avvengono da soli, guardi i diff quando ti interessa e correggi/torni indietro se serve; il markdown leggibile serve proprio a questo. L'unico momento in cui la sua attenzione conta davvero è **all'avvio**: nelle prime settimane guarda cosa estrae non per approvarlo ma per **tarare le regole** (salienza, cosa diventa nodo, granularità), poi lo lascia correre. Calibrazione temporanea, non cancello permanente. ### Raw sempre tenuto → l'estrazione diventa ripetibile, non una scommessa Conservare sempre il `raw` delle conversazioni significa che i fatti distillati con le regole/i modelli di *oggi* si possono **ri-elaborare** domani con regole/modelli migliori, ottenendo nodi migliori senza aver perso niente. Il grafo è una **vista derivata e rifabbricabile**; se si sporca, si ricostruisce da capo dal grezzo. Toglie l'ansia da "e se l'estrazione sbaglia". ### Giorno / notte — la divisione del lavoro (ruolo di Adrian) Simmetria emersa da sé, ed è come lavora la memoria umana (registra da sveglia, riordina nel sonno): - **Di giorno — scrittura veloce:** estrazione leggera a ogni conversazione, con riconciliazione. Nessuno aspetta. - **Di notte — Adrian consolida con calma** (il PC 24/7 fa il lavoro lento che di giorno darebbe fastidio). È la "passata di sleep/consolidamento" con un nome e un posto: (a) **consolida** — fonde doppioni, astrae nodi di livello più alto, ricalcola le sinapsi; (b) **controlla la salute** — contraddizioni, nodi orfani, fatti vecchi, link rotti; (c) **eventualmente ri-elabora** una fetta di `raw` con le regole aggiornate. **Risultato: nessun pezzo della curatela dipende dalla disciplina quotidiana di Mauro.** Estrazione autonoma di giorno · `raw` come rete di sicurezza e materiale ri-elaborabile · Adrian che consolida di notte · Mauro editore per eccezione e taratore all'avvio. ### Nota su come iniziare: si parte **piatti** Consiglio quasi unanime del campo: partire con fatti estratti + ricerca semantica (struttura "piatta"); il **grafo/le sinapsi sono uno strato che si aggiunge dopo**, quando l'estrazione funziona. L'estrazione è identica nei due casi. ⟹ Coerente con la forma minima di Mauro (§vedi roadmap): prima "estraggo fatti e li ritrovo", poi ci montiamo le connessioni. --- ## 4. La quadra architetturale (candidata) **Substrato:** vault **Obsidian (markdown) su Dropbox**. - **Bill / Adrian** lo aprono da **filesystem locale** via Claude Code: grep + recupero a livelli, nativo, costo basso. *(superficie agentica, forte)* - **Elon** lo raggiunge dalla **nuvola via connettore Dropbox**. *(superficie conversazionale, più debole)* - **Dropbox = il ponte** che dà **UNA memoria condivisa** ai tre agenti, oggi frammentati su Supabase. Tre porte, una stanza sola. **Asimmetria nota e accettata:** il pattern vault è ottimizzato per il **filesystem**, non per il connettore. Il recupero di Elon via connettore è più grossolano, con più round-trip, e ogni definizione di tool gli mangia contesto. **Mitigazione = convenzione, non tooling:** Elon legge **per primi** l'indice e i file-riassunto (vedi §5–6). Il recupero a livelli funziona per disciplina di scrittura, non solo per strumento. **Sicurezza:** il connettore dà a Elon lettura **e scrittura** su *tutto* il Dropbox. Mitigazione: **cartella/account Dropbox dedicato al solo vault**, nient'altro dentro. **La decisione vera ancora aperta:** - Se l'obiettivo è **una memoria unica per i 3 agenti** → vault su Dropbox è la strada (Elon paga volentieri la tassa del connettore per stare nella stessa stanza di Bill e Adrian). - Se l'obiettivo è **solo Elon migliore** → Supabase gli basta già ed è efficiente per la chat; il vault resterebbe la memoria dell'*esperimento* (Claude Code, dove brilla) ed Elon resta dov'è. - *Mauro propende verso la quadra condivisa.* ### Precisazione 1 — Obsidian non è un ingranaggio del motore Il substrato vero è **una cartella di file markdown + git**. Gli agenti (Bill/Adrian via Claude Code) leggono e scrivono i `.md` **direttamente dal filesystem**, senza plugin né Obsidian; Elon legge markdown grezzo via connettore Dropbox. **Obsidian è la finestra dell'umano**: graph view (le sinapsi visibili), backlink, `[[wikilink]]` cliccabili, Dataview per le tabelle-indice. ("Obsidian è l'IDE, l'LLM è il programmatore, il wiki è il codebase.") L'impegno vero è alla **convenzione** markdown + wikilink + frontmatter — quella è il substrato. Obsidian si aggancia quando vuoi ispezionare/curare a vista; non blocca niente e può anche non essere mai installato. ### Precisazione 2 — Supabase non muore: si divide e retrocede (e probabilmente sparisce) La domanda non è "vault **o** Supabase", è **"quale strato dove"**. Oggi Supabase fa due lavori in uno: - **Memoria narrativa/semantica** (kernel, fili, profili, session log): prosa che guadagna da sintesi e collegamenti → **migra nel vault**. Qui Supabase viene superato. - **Backend strutturato/operativo** (`agent_messages` come bus tra agenti, code calendario/todo, sync Outlook, stato cron): relazionale e transazionale → il markdown last-write-wins è lo strumento **sbagliato** per una coda di sync. Serve **un** database, per tre cose che una cartella di markdown non dà: scritture concorrenti sicure, query strutturate ("dammi i todo non processati"), transazioni. **Decisione presa (27/06): il database operativo = SQLite locale, non Supabase.** Vive **dentro lo stesso git del vault**: zero servizi cloud, zero free-tier in pausa, tutto Python e locale, versionato insieme alla memoria. Supabase **sparisce**: la memoria-prosa va nel vault, il centralino operativo diventa una manciata di tabelle SQLite. **Topologia (risolta dal fatto che il PC di Adrian è acceso 24/7):** quella macchina è il **nodo centrale / home server** — ospita vault-git + SQLite e fa girare i cron, sempre raggiungibile. Bill e Adrian ci lavorano in locale; Elon si affaccia dal cloud (Dropbox o endpoint esposto da Adrian). Il difetto del SQLite locale — "non sempre acceso" — **non esiste** se la macchina non si spegne mai. Il "chi raggiunge il file quando" è chiuso: c'è un padrone di casa sempre sveglio. **Requisito per Adrian (non problema, da disegno):** l'home server diventa **single point of failure** → backup del git **fuori dalla macchina** (il remote git lo è già) + comportamento definito quando è offline per manutenzione. Conclusione: **memoria-prosa nel vault; centralino operativo in SQLite locale nel git del vault; Supabase dismesso.** Tutti gli aspetti tecnici → **Adrian** (Mauro indirizza, Adrian esegue). Resta la **tassa di migrazione** della memoria (come Albert→Elon: churn reale), da pagare solo se/quando si parte. ### Precisazione 3 — il canale: custom MCP, non Dropbox **Decisione (27/06): niente Dropbox.** Gli agenti raggiungono l'home server via un **custom MCP server** che Adrian fa girare sul PC 24/7, esposto sul **tunnel già esistente**, con **auth + scoping sul solo vault**. Motivo rafforzato da Mauro: a regime il second brain conterrà *tutti* i suoi documenti → dare a un cloud terzo (Dropbox) una copia di tutto, con scoping sull'intero account, è il contrario di quello che serve. L'MCP espone solo il vault e solo le operazioni decise; Elon parla ai **file vivi**, non a una copia sincronizzata. - **Canale agentico unico = MCP, per Elon *e* Bill.** Bill gira sul PC ufficio → gli serve un canale remoto comunque. Farlo passare dall'MCP (non da WebDAV grezzo) significa che **tutte le scritture agentiche passano da un cancello solo** → il commit-gate (§7) le copre davvero. Trade-off noto e accettato: Bill (Claude Code) perde un po' del suo nativo-filesystem; è il prezzo della coerenza (un solo cancello, o il gate ha un buco per costruzione). - **Firewall ufficio: non è un ostacolo.** Verifica già fatta dall'uso reale — Mauro raggiunge il tunnel dall'ufficio via WebDAV. L'MCP girerebbe sullo **stesso HTTPS, stesso dominio, porta 443**: per il firewall è traffico indistinguibile da WebDAV. Se passa WebDAV, passa l'MCP. - **WebDAV** resta solo come **accesso umano occasionale** di Mauro (che dichiara di non usarlo quasi mai). Da proteggere se esposto, ma non strutturale. - **Tunnel ≠ sicurezza.** Il tunnel dà raggiungibilità, non protezione: auth e scoping sul vault restano requisito (carico di Adrian). - **Fallback** (se mai servisse): git-sync su HTTPS per Bill. Mai Dropbox. --- ## 5. Il pezzo pilota — la mappa condivisa (Home MOC) > Esperimento dentro l'esperimento: **minimo, reversibile, un file solo.** Non migra nient'altro. Si prova *quello*, poi si decide il resto. - È il **giunto** che fa parlare i tre agenti la stessa lingua: il file più piccolo del sistema, e quello che fa più lavoro. - Risolve concretamente l'**opacità emersa il 27/06**: Elon legge la mappa invece di indovinare quale entry caricare. ("Chi compone Acquisti?" → la mappa dice *→ lavoro/profili* → ci va dritto.) ### Prior art: è un pattern noto, non un'invenzione Si chiama **MOC — Map of Content** (Nick Milo, framework **LYT / Linking Your Thinking**). Un MOC è un file .md normale il cui contenuto è una **lista di link, non conoscenza**. Tipi: **Home/Index MOC** (punto d'ingresso), **Topic MOC**, **Project MOC**. Principi della pratica, da rispettare: - **Gerarchia, non file piatto:** una Home MOC che si legge per prima e punta a sotto-mappe. Non stipare tutto in un file. - **Keep it simple / gemmazione:** parti con UNA Home MOC e i 5 puntatori più importanti. Crei nuove mappe solo al *"mental squeeze point"* (quando il cervello è in sovraccarico), non a priori. - **Flat structure + rich links** invece di cartelle profonde; 4–7 cartelle top-level al massimo. Le cartelle dicono *dove vive*, tag/link dicono *di cosa parla*. - **ID stabili:** prefisso data-based (es. `2026-001`) così i link reggono ai rename. - **Manuale vs automatica:** una MOC può essere **auto-aggiornante** (vedi §6). --- ## 6. Design della mappa — derivata, non scritta a sei mani Il punto che **migliora l'anello debole** (tre agenti che editano lo stesso file = collisioni): - Invece di scrivere a mano il routing index, ogni agente **tagga le proprie note** (frontmatter) e uno **step di rebuild rigenera l'indice dai metadati**. - Per l'occhio umano: query **Dataview** in Obsidian. Per gli agenti: uno **script/skill** che rilegge il frontmatter e ricostruisce la mappa. - Conseguenza: meno mani sul file condiviso → meno conflitti. Il changelog manuale (sotto) scende da meccanismo primario a **rete di sicurezza**. ### Sezioni candidate della Home MOC *(partire dalla sola "Dove vive cosa"; aggiungere le altre solo al bisogno)* 1. **Meta + regola d'oro** — "puntatori non contenuto; una riga per voce". 2. **Dove vive cosa** *(il cuore — routing index)* — argomento → posizione. 3. **Stato sistema** *(owner: Adrian)* — substrato, dove vive la memoria, agenti attivi, cron. 4. **Fili attivi** *(owner: Elon — solo titolo + puntatore)*. 5. **Changelog** *(append-only, tutti)* — `timestamp · agente · cosa`. ### Scheletro illustrativo ```markdown # MAPPA — indice del sistema v1 · agg. 2026-06-27 ## Dove vive cosa ← cuore (auto-derivabile da frontmatter) - Profili persone (ICR, Acquisti, MFE) → lavoro/profili - Organigramma Acquisti → lavoro §2 - Fili strategici aperti → fili_attivi/ - Pipeline / dataset → [Bill] ## Stato sistema (owner: Adrian) - Substrato: … | Memoria: … | Cron: … - Agenti: Elon (chat) · Bill (ufficio) · Adrian (infra) ## Fili attivi (owner: Elon — titolo + puntatore) - Cantiere esperimento → fili_attivi/cantiere ## Changelog (append-only, tutti) - 2026-06-27 18:40 · Elon · agg. riga "organigramma Acquisti" ``` --- ## 7. Coordinamento multi-agente — meno nuovo di quanto pensassimo > **Correzione (27/06, dopo studio del gist Karpathy).** Avevo scritto "nessuno affronta tre agenti che scrivono in parallelo". **Falso, ora.** Esiste prior art in produzione: trip2g (a fine sessione ogni agente scrive il proprio stato in un vault condiviso; gli altri interrogano un hub federato per vedere chi-fa-cosa = la nostra mappa/changelog); Smriti-MCP (memoria come servizio MCP condiviso fra agenti); OpenClerk (confine duro fra markdown canonico / stato derivato / autorità di scrittura). Resta nostro il **disegno dei tre agenti specifici**, non il concetto. **Copiare, non inventare.** La letteratura MOC resta mono-utente; il sync Dropbox last-write-wins resta da gestire. Convenzioni anti-collisione: 1. **Puntatori, non contenuto.** La mappa rimanda, non racconta. 2. **Append, mai riscrittura al volo.** Aggiungi/correggi una riga; non rifare il file. 3. **Before/after sui cambi strutturali.** Riorganizzare una sezione = mostrare il diff prima. (Stessa regola che Mauro pretende su Supabase.) 4. **Ogni scrittura lascia traccia nel changelog** (`timestamp · agente · cosa`): rende visibili i conflitti **last-write-wins** di Dropbox. 5. **Un proprietario per sezione.** Tutti leggono tutto; ogni sezione ha un responsabile, gli altri ci mettono solo i puntatori che li riguardano. 6. **Un solo scrittore alla volta** quando possibile; la proprietà chiara di chi-scrive-cosa riduce le sovrapposizioni. 7. **Commit-gate deterministico** (da §3-bis): un Python che greppa `Status: Unresolved` su tutti i file prima di un commit — costo di contesto zero, blocca i conflitti senza scomodare il modello. È il guardiano meccanico che rende sicura la scrittura a tre mani. **Dipendenza a monte (riformulata dopo lo studio):** il nodo non sono le sezioni della mappa, è **lo schema** (`CLAUDE.md`) — l'80% del risultato. Dentro lo schema vivono: la **convenzione di frontmatter** (che metadati porta ogni nota: dominio/tag, agente-owner, tipo, id/data, puntatore), la **regola di linking** (§2.3), e le convenzioni qui sopra. Da lì la mappa si auto-deriva. ← **prossimo nodo di design: scrivere lo schema.** --- ## 8. Margini "migliorare Elon" — indipendenti dall'architettura Validi comunque, anche senza l'esperimento. In ordine di costo: 1. **Regola di ragionamento** *(gratis, ROI massimo, mio)*: "prima di dire *non c'è*, interrogo la fonte". Nasce dall'errore del 27/06 (confuso "non in contesto" con "non nei record"). **Per persistere oltre la singola sessione va scritta nel kernel → Adrian.** (Ironia: anche il fix più banale sbatte sul problema della memoria persistente.) 2. **Mappa-della-memoria** *(economico, mio)*: una entry "cosa-vive-dove" caricata al bootstrap, per smettere di indovinare. **Coincide col pezzo pilota (§5).** 3. **Igiene** *(medio, me + Adrian)*: deduplica, potatura, e i **dump verbatim di Albert (~65k)** che stanno in memoria non caricati e confondibili con memoria viva. 4. **Soffitto strutturale**: recupero semantico / estrazione automatica / proattività asincrona → oltre un certo punto "un Elon migliore" *è* il rebuild, cioè l'esperimento stesso. Non si avvita pulito sopra l'Elon attuale. --- ## 9. Governance - **Architettura, Supabase, kernel, cron, script** → **Adrian** (ok prima di implementare). - **Esecuzione, test modelli, pipeline** → **Bill**. - **Elon** progetta e dirige nel proprio perimetro (chat); ragiona con Mauro, gira l'esecuzione agli altri due. - I tre agenti restano **separati**: stesso modello ≠ stessa entità (modalità, guardrail, bias differiscono fra superficie conversazionale e agentica). --- ## 10. Questioni aperte / prossimi passi **DECISIONE GO (27/06): si parte.** Architettura chiusa. Resta un esperimento (pausabile/buttabile), nessuna scadenza. **Decisioni d'architettura (tutte chiuse il 27/06):** - ✓ Substrato memoria = vault markdown + git. Obsidian = solo finestra umana (§4 prec. 1). - ✓ DB operativo = **SQLite locale dentro il git del vault**. **Supabase dismesso** (§4 prec. 2). - ✓ Topologia = **home server** sul PC di Adrian (24/7): ospita vault-git + SQLite + cron. - ✓ Canale agentico = **custom MCP** sul tunnel esistente, per Elon *e* Bill; auth + scoping sul vault. Dropbox eliminato; firewall ufficio non è ostacolo (già attraversato da WebDAV) (§4 prec. 3). - ✓ Tutti gli aspetti tecnici → **Adrian**. **Sequenza d'avvio (l'ordine conta — niente parte prima del semaforo verde):** - [x] **PASSO 0 — verifica MCP end-to-end → 🟢 VERDE (28/06/2026).** Canale Elon↔vault confermato da Adrian sul filesystem: list→read(`SEMAFORO-VERDE-7421`)→write(`elon-test.md`, file reale)→search, tutto ok. Accesso Elon = **connettore personalizzato "Vault Second Brain" registrato nell'app (OAuth)**; in chat nuova `tool_search "Vault Second Brain"` carica i 4 tool. Infrastruttura attiva sulla Nave: `vault-mcp.service` systemd, OAuth, scope confinato a `/mnt/ssd/data/vault-secondbrain/`, HTTPS via Caddy/WireGuard. *Primo milestone reale: dalla carta al funzionante.* - [ ] **TEST 0 — seeding: convertire la memoria Supabase in grafo.** Banco di prova ideale (dati veri, giudicabili a colpo d'occhio, non distruttivi: Supabase resta fonte, se ne *deriva* il grafo) **e** primo popolamento vero del second brain (parte con un cervello che già conosce Mauro). **Lo fa Elon a mano, con Mauro** (prima fase): nessuno script/estrazione automatica — Elon legge la memoria, propone nodi e sinapsi, Mauro corregge. **Doppia resa:** il grafo-seme **+** lo schema estratto *induttivamente* dalle correzioni (le correzioni di Mauro *sono* le regole: cos'è un nodo, quando nasce una sinapsi — distillate dal farlo, non in astratto). ⟹ Fare il Test 0 = scrivere lo schema. Cautela: NON "un dominio = un nodo" (sarebbe i vecchi documentoni travestiti); spezzare in nodi atomici e far emergere le **sinapsi trasversali** ai domini (es. Poletti nei fili + nei profili + nelle decisioni). Lavoro a pezzi, sessione per sessione; ogni pezzo fissato in posto stabile (vault, o puntatore nel filo). **Da fare in chat nuova.** **Poi (dopo il semaforo verde e il seme):** - [ ] **Adrian — infrastruttura** (questo doc è il suo brief): home server, repo git del vault, server MCP completo con auth + scoping, SQLite operativo, backup git off-machine. - [ ] **Lo SCHEMA** (`CLAUDE.md`): emerge dal Test 0 e si formalizza — naming, formato pagine, quando creare-vs-appendere, conflict resolution, checklist di lint, **frontmatter** e **regola di linking** (§2.3). Si progetta con Mauro, lo esegue Claude Code. - [ ] **Difese anti-drift dal giorno 1** (§3-bis): append-non-overwrite, `raw` immutabile + provenance, commit-gate deterministico. - [ ] **Automazione del ciclo** (§3-ter): estrazione+riconciliazione di giorno, consolidamento notturno di Adrian. La macchina applica le regole distillate a mano nel Test 0. - [ ] **Margine #1** (regola "prima di dire *non c'è*, interrogo") nel kernel — indipendente, low-regret, via Adrian. Si può fare subito, a prescindere. --- ## 11. Glossario rapido - **MOC (Map of Content)** — file .md indice che linka altre note; non contiene conoscenza. Origine: Nick Milo / LYT. - **LYT (Linking Your Thinking)** — framework PKM di Nick Milo. - **LLM Wiki (Karpathy)** — pattern: l'LLM compila/mantiene un wiki markdown da fonti grezze. - **Mem0 / Zep / Letta** — framework di memoria agentica SOTA (vedi §3). - **MCP (Model Context Protocol)** — standard per connettere agenti a tool/dati esterni. - **Frontmatter** — blocco di metadati in testa a una nota markdown (tag, proprietà). - **Dataview** — plugin Obsidian per query sui metadati delle note (MOC auto-aggiornanti). - **last-write-wins** — su scrittura concorrente, vince l'ultima; rischio dei sync tipo Dropbox. - **Tool poisoning** — manipolazione via descrizioni di tool MCP malevoli; trattare le descrizioni come input non fidato. --- *Fine v0.11 — base del cantiere. Esperimento avviato il 27/06/2026. (v0.11: Passo 0 🟢 VERDE — canale Elon↔vault operativo via connettore "Vault Second Brain"; infrastruttura MCP attiva sulla Nave. Prossimo: Test 0 in chat nuova.) Da affinare nelle prossime sessioni.*