WUPHF: la memoria condivisa per i team di agenti AI, in markdown e git
WUPHF prende l’idea del wiki LLM di Karpathy e la estende ai team multi-agente: notebook privati, wiki condiviso, promozione con review, tutto su file markdown e cronologia git. Niente database, niente lock-in, niente dashboard.
Perché ti dovrebbe interessare
Tre settimane fa Karpathy ha pubblicato un gist che ha fatto il giro del mondo: dai al tuo LLM un wiki persistente, invece di trattarlo come un motore stateless. WUPHF è la prima implementazione che porta quell’idea oltre il singolo utente, verso team di agenti AI che collaborano. Se lavori con più agenti che devono condividere contesto senza impazzire in vector database e SaaS, questa è la direzione da guardare.
Dal wiki personale al cervello di squadra
Il 4 aprile 2026 Andrej Karpathy ha pubblicato un gist intitolato llm-wiki.md che è diventato virale in pochi giorni: oltre 5.000 star su GitHub e 16 milioni di visualizzazioni su X. L’idea è semplice ma potente: invece di trattare il tuo LLM come un motore di retrieval stateless (il classico RAG), dagli un wiki persistente e compounding in cui scrivere e da cui leggere across sessioni. Ogni nuova fonte viene integrata nelle pagine esistenti, le contraddizioni vengono segnalate, e la base di conoscenza si arricchisce anziché ripartire da zero a ogni query. Karpathy ha descritto il pattern così: “Obsidian è l’IDE; l’LLM è il programmatore; il wiki è la codebase.”
Il gist originale pensa a una persona, un LLM, un vault Obsidian. Almeno 15 implementazioni sono spuntate nella prima settimana. WUPHF prende il pattern e lo piega per team multi-agente, non per singoli ricercatori.
La differenza centrale è la divisione notebook-wiki. Ogni agente ha un notebook privato in agents/{slug}/notebook/*.md, dove abbozzare ipotesi e ragionamenti in corso senza inquinare la conoscenza condivisa. Separatamente, il wiki di team in team/* raccoglie la conoscenza canonica e revisionata: decisioni, playbook, procedure consolidate.
Il meccanismo chiave è il flusso di promozione tra i due livelli:
- Un agente abbozza nel proprio notebook
- Un revisore (umano o un altro agente) approva
- Il contenuto viene formalizzato nel wiki di team, con un back-link alla bozza originale
È lo stesso ciclo drafting-review che usano le vere organizzazioni per i documenti provvisori vs la documentazione ufficiale. Solo che qui avviene a velocità macchina.
Ecco dove WUPHF si discosta in modo significativo dalle altre implementazioni di LLM wiki nate dopo il gist di Karpathy. La maggior parte segue il pattern originale: una persona, un LLM, un vault personale. WUPHF tratta il wiki come infrastruttura condivisa per un team di agenti eterogenei (Claude Code, Codex, OpenClaw, LLM locali via OpenCode), ognuno con il proprio contesto e i propri bias. Il flusso di promozione è il layer di governance che rende il sistema funzionante senza degenerare in rumore.
Entity brief e integrità della conoscenza
Per ogni persona, azienda o cliente con cui i tuoi agenti interagiscono, WUPHF genera automaticamente un entity brief a partire da un registro di fatti in append-only. Quando si accumulano abbastanza fatti nuovi, un agente integrato chiamato Pam (l’Archivista) sintetizza un brief aggiornato e lo committa con la propria identità git. L’intera catena di autori è visibile in git log.
Le contraddizioni tra fatti vengono evidenziate inline invece di essere riconciliate silenziosamente. Un cron di lint giornaliero scansiona il wiki alla ricerca di:
- contraddizioni tra pagine
- voci stale e obsolete
[[Wikilinks]]interrotti, renderizzati in rosso per rendere visibili le lacune conoscitive
Il comando /lookup e un tool MCP permettono a qualsiasi agente di chiedere “cosa sappiamo di X” e ottenere una risposta con citazioni.
Il layer di indicizzazione bleve + SQLite alimenta /lookup e i controlli di lint, ma i file markdown restano la fonte di verità. È una scelta architetturale deliberata. Come dice l’autore del progetto: “Non è un vector store RAG con un’interfaccia chat travestita da wiki.” L’indice può essere ricostruito dai markdown in qualsiasi momento. Se WUPHF domani sparisce, possiedi ancora ogni singolo byte in ~/.wuphf/wiki/.
Cosa non è
L’autore è esplicito sui confini del progetto:
- Non è hosted: il tuo wiki vive sulla tua macchina
- Non è magia: la qualità della sintesi dipende dalla qualità delle osservazioni
- Il cron di lint cattura i problemi ma non li giudica
- Il recall sul layer di query è ancora in ottimizzazione: 85% di recall@20 su 500 artifact in un benchmark interno
E l’inquadratura Karpathy è sua, non di Karpathy: “Lui ha girato intorno al pattern per un po’. Sono io che sostengo di aver consegnato un’implementazione passabile.”
Il progetto conta 72 star su GitHub a fine aprile 2026, fase early-adopter. La codebase è prevalentemente Go (74.7%) con TypeScript (14.9%). L’avvertimento sulla stabilità è esplicito: “pre-1.0, main si muove ogni giorno, fissa il fork su un release tag.” WUPHF fa parte di un progetto più ampio descritto come “un ufficio collaborativo per agenti AI,” che supporta diversi backend di memoria. Il wiki markdown è diventato il default dalla v0.0.6, sostituendo il precedente context graph basato su Nex, anche se gli utenti esistenti possono continuare con il backend preferito.
I dettagli tecnici
Da qui in poi si entra nel tecnico. Se ti interessa l’idea più dell’implementazione, puoi saltare direttamente alla conclusione.
Architettura della memoria
La struttura del filesystem riflette direttamente la separazione concettuale:
agents/{slug}/notebook/*.md- notebook privato di ogni agenteteam/*- wiki condiviso e canonico- Registro fatti in append-only per la generazione degli entity brief
Il flusso di promozione è il layer di governance: il contenuto passa dal notebook privato al wiki di team solo dopo approvazione, con back-link alla bozza originale. Questo evita che le ipotesi non verificate di un agente diventino conoscenza condivisa senza review.
Indicizzazione e lint
Il layer di indicizzazione usa bleve + SQLite per alimentare /lookup e i controlli di lint. I file markdown restano la fonte di verità: l’indice è ricostruibile dai file in qualsiasi momento. Il cron di lint giornaliero scansiona contraddizioni, voci stale e wikilink interrotti, segnalando tutto inline.
Stato del progetto
- 72 star su GitHub (fine aprile 2026)
- Codebase: Go 74.7%, TypeScript 14.9%
- Stato: pre-1.0, main branch instabile, fissare i fork su release tag
- Il wiki markdown è diventato il default dalla v0.0.6, in sostituzione del context graph basato su Nex
- Benchmark interno: 85% recall@20 su 500 artifact
Il punto
Punti chiave:
- WUPHF estende il pattern wiki LLM di Karpathy da singolo utente a team multi-agente, con notebook privati e wiki condiviso
- Il flusso di promozione con review è il layer di governance che impedisce al wiki di degenerare in rumore
- Tutto su markdown e git: se il progetto sparisce, ti rimangono tutti i file
Il wiki come memoria condivisa non è un’idea nuova. Ma farlo funzionare per un team di agenti eterogenei, senza database e senza lock-in, è il dettaglio che cambia la domanda: da “posso costruire un wiki?” a “posso fidarmi che resti coerente?”
Community
“Ho configurato il tutto in un Obsidian Vault sincronizzato da remoto, ora posso creare il mio wiki, interrogarlo con l’agente e leggerlo quando voglio. Lo adoro proprio.”
- u/seth76
La discussione su Reddit ha raccolto un engagement contenuto (17 upvote, 1 commento) con l’osservazione più interessante sulla compatibilità con Obsidian, prevedibile dato il substrato in plain markdown ma praticamente convincente per chi usa già strumenti di personal knowledge management.