A GitHub gist was shared earlier this year by Andrej Karpathy (formerly of OpenAI).
It’s titled “LLM Wiki.” The post is roughly 1,500 words long and outlines a method for creating a personal knowledge base that an LLM manages on your behalf — a lasting, ever-growing resource that becomes more valuable with each new addition.
Information is gathered once and kept up to date, instead of being reconstructed from the ground up with every new question.
Chances are, most readers skimmed it, found it mildly intriguing, and moved on!
I went ahead and built it. This article walks you through the setup process and shares the lessons I picked up along the way.
Every chat session begins with a clean slate.
You launch a conversation, reintroduce yourself, describe your current work, recap last week’s decisions. You receive a helpful reply. Then you close the next day, you repeat the entire process.
The tool itself functions well, but the underlying context layer is absent!
Granted, built-in memory features offer some help.
Claude can recall your name and role. ChatGPT picks up on your preference for bullet points. But neither has access to the specifics of your ongoing projects, the deal you’re close to finalizing, the vendor you dismissed last month, or what shifted in your pipeline this week.
That level of operational detail has no durable home!
The next step most developers consider is RAG.
RAG is certainly valuable, but it addresses a different challenge.
It reconstructs knowledge from the ground up each time a query comes in. You embed documents, pull relevant chunks at query time, and hope the correct pieces surface. Nothing carries over.
A question that demands combining information from five separate documents forces the LLM to locate and stitch together those pieces all over again, every single time.
The vault approach described here captures knowledge once and keeps it fresh. When new information arrives, the LLM indexes it, reviews it, weaves it into the existing structure, updates connected pages, highlights inconsistencies, and preserves cross-references.
The heavy lifting of synthesis is already complete before you pose your next question.
Karpathy sums it up neatly: the wiki is a persistent, compounding artifact.
The cross-references are already in place. The insights don’t vanish into past chat history. They accumulate.
Hi! I’m Sara, and each week on Learn AI I write about hands-on AI development. Tools, design patterns, and what tends to go wrong in production. Subscriptions are free.
The architecture: two folders and a schema file
The entire structure lives within a single directory tree:
vault/
├── CLAUDE.md ← schema file, entry point for any AI
├── Raw/ ← immutable source documents
│ ├── Meeting Notes/
│ ├── Documents/
│ └── _pending.md ← compilation queue
└── Wiki/ ← LLM-generated, structured, indexed
├── Projects/
├── People/
├── Decisions/
├── _hot.md ← active cache
├── _log.md ← audit trail
└── _index.md ← master index(This is just a sample layout. Adjust it to suit your needs.)
Raw serves as your definitive source.
Meeting transcripts, exported Slack conversations, documents pulled from wherever your actual work takes place. The rule is non-negotiable: the AI can read Raw but must never modify it. Append-only, no exceptions.
Wiki is what the AI constructs and curates. One file per project, person, decision, or topic area. Organized and cross-linked. This is the first thing the AI consults when you ask a question.
If you’ve worked with data pipelines, this separation will feel familiar. Raw is your ingestion zone. Wiki is your refined layer. If the Wiki ever drifts or becomes corrupted, you simply rebuild it from Raw. The original source is never at risk.
The schema file lives at the root and instructs any AI on how the vault is structured, what to read first, and what the ground rules are. I named mine CLAUDE.md. If you’re working with Codex, AGENTS.md works just as well. Call it whatever you like, as long as you direct the AI to it at the beginning of every session.
This is the piece most people overlook, and it’s the reason most setups quietly fall apart.
A folder full of markdown files isn’t a system by itself. These three files are what make it one.
_hot.md acts as the cache. Each morning, the daily automation refreshes this file with the most active threads, any important figures or deadlines that came up, and a brief note on anything urgent. It stays under 500 tokens. When you start a conversation and want a quick overview, the AI reads _hot.md first — no need to load the entire Wiki.
_pending.md functions as the queue. Each time a new file is added to Raw, its filename and date are appended here. When the weekly compilation runs, it reads this file, processes each entry, folds it into the Wiki, and marks it [COMPILED — 2026-05-01]. Without this file, the daily intake and the weekly compilation can’t stay in sync. You end up with orphaned raw files and a Wiki that lags weeks behind.
_log.md serves as the audit trail. Every automated run adds a timestamped entry: what executed, which files were handled, and which Wiki pages were created or modified. If the system drifts off course, this is where you trace the issue. Karpathy’s gist offers a handy suggestion here: begin each log entry with
Use a consistent prefix like ## [2026-05-01] daily-ingest so the entire log can be easily searched and parsed using standard Unix tools.
A vault without these files just sits there collecting dust. With them, you have a functioning pipeline.
The schema file: showing any AI how to navigate your vault
CLAUDE.md is where every session begins.
Here’s what belongs inside it:
- The folder map (what lives in Raw, what lives in Wiki, and the purpose of each subdirectory)
- The read order (
_hot.mdalways comes first, followed by the relevant domain index) - Hard rules: “never modify files in Raw/”, “never fabricate facts that aren’t in the source files”, “always append to _log.md after every run”
- The domain structure (which indexes exist and how they’re named)
The schema file is also where you bake in your prompting defaults. I follow a well-known pattern, adapted straight into the schema:
I want to [TASK] so that [WHAT SUCCESS LOOKS LIKE].
First, read the uploaded files completely before responding.
DO NOT start executing yet. Ask me clarifying questions so we
can refine the approach together.
Only begin work once we've aligned.Once this is embedded in your schema, every AI that opens your vault already knows to ask before acting. No more half-baked responses from a model that jumped to conclusions.
The prompting principles worth spelling out explicitly:
- Context beats prompts. Give the AI files to read, not instructions to follow.
- Examples beat prescriptions. Show a sample of what you want instead of describing it.
- Constraints beat rules. Define what the output should NOT be, and let the AI figure out the how.
- Goals beat instructions. State what needs to be achieved, not the steps to get there.
- State the task and the success criteria. That’s it — two sentences.
The automation layer: three separate rhythms, not one
I’ve seen two common failure modes: you update the vault by hand and it works great for a week, then life gets busy and three weeks go by with nothing filed.
Or you build one big automated job that ingests, synthesizes, and audits everything in a single pass — and now your daily ingest is overwriting Wiki files it was never supposed to touch.
The fix is to split the jobs apart. Here’s how.
Daily (weekday mornings): ingestion only
Pull from your sources. Drop new files into Raw/. Queue them in _pending.md. Refresh _hot.md based on what came in.
No Wiki edits. The daily job is mechanical, quick, and safe enough to run on its own every morning.
Here’s what the prompt looks like in practice:
Every weekday morning, do the following:
1. Check [your project management tool] for items updated or
created in the last 24 hours.
2. Check [your meeting notes source] for new transcripts. For
each one found, save it as a markdown file in Raw/Meeting Notes/
using the format YYYY-MM-DD — [meeting title].md.
Add a line to Raw/_pending.md with the filename and date.
3. Check [your team communication tool] for messages in key
channels. Extract decisions, action items, and anything
that affects an active project.
4. Check [your email] for flagged or important messages.
Summarize what needs attention.
After completing the above, rewrite Wiki/_hot.md with:
- The most active threads or open decisions from today's scan
- Any key numbers or deadlines that surfaced
- One line on anything urgent
Keep _hot.md under 500 tokens.Swap the bracketed placeholders with your actual tools. The structure works whether you’re pulling from Linear and Slack, Notion and email, or anything else entirely.
Weekly (Monday mornings): compilation
Read _pending.md. For each unprocessed file, read it fully, create a structured Wiki page in the correct domain folder, update the relevant index, add backlinks to related pages, and mark the entry as compiled.
The weekly job handles interpretation. It turns raw material into organized knowledge. It’s slower, costs more, and is worth reviewing now and then to make sure the AI is filing things in the right places.
Monthly (1st of the month): linting
Health check only. Scan the entire Wiki for stale pages (dates or statuses that newer content has made outdated), missing backlinks, contradictions between pages, coverage gaps, and orphaned pages that no index references.
Write a report file. Post a plain-English summary. Don’t auto-fix anything.
The monthly job never touches Wiki content directly. That boundary is what makes it safe to run unsupervised.
Each cadence carries a different risk level: daily is mechanical, weekly handles interpretation, and monthly handles diagnosis. Combining them into one job is how vaults end up corrupted.
On tooling: any system with scheduling works. A cron job with an MCP-enabled CLI, n8n, or an AI desktop tool that supports scheduled tasks.
The prompts above contain the logic. The runner is swappable.
What actually changes
You stop re-explaining yourself, and the nature of your conversations shifts.
When context is already loaded, you move past using AI for one-off questions and start using it for real work.
The AI understands your active projects, your latest decisions, and your team’s dynamics. When you type ”what should I prioritize today?” it pulls from _hot.md alongside your project files, returning an answer rooted in your real context.
Portability is the other major advantage!
Your context resides in a local folder on your own machine — not locked inside any AI’s memory. Simply direct a different AI at the same folder and it accesses the same files. Swap tools at will. The vault comes with you.
A few pitfalls worth understanding before you start building:
_pending.md overflows if your daily ingest is too broad and the weekly compilation can’t clear it quickly enough. Narrow down what you pull in each day.
Documentation stales if nobody reads _log.md. The monthly linter catches this — but only if you actually review the report.
The entire system collapses if automation ever writes to Raw. A single job that touches Raw “just this once” destroys the source-of-truth guarantee. That line must never be crossed.
The grueling part of maintaining a knowledge base isn’t the reading or the thinking.
It’s the admin work. Refreshing cross-links, keeping notes up to date, flagging when new information clashes with existing claims. People abandon wikis because the upkeep burden outpaces the benefit.
LLMs don’t get tired, don’t overlook a cross-reference refresh, and can update 15 files in a single pass.
Karpathy links this idea back to Vannevar Bush’s 1945 Memex concept — a personal curated knowledge repository with associative trails linking documents. Bush’s vision was closer to this model than to what the web actually became. The piece he couldn’t solve was who handles the upkeep.
The vault I’ve been using pairs Claude as the AI layer with a markdown tool as the front end.
The approach works with any AI that can read files and any scheduler able to run a prompt on a timer. The folder is just a folder. The files are just plain text.
Set it up once. After that, your AI never starts from a blank slate.
Thank you for reading!
