of OpenAI) posted a GitHub gist earlier this year.
It’s called “LLM Wiki.” About 1,500 words. It describes a pattern where you build a personal wiki that an LLM maintains for you: a persistent, compounding artifact that gets richer every time you add to it.
Knowledge compiled once and kept current, rather than re-derived from scratch on every query.
Most people probably read it, thought “that’s interesting,” and closed the tab!
I built it and this article shows how to set it up and I also tell you what I learned during implementation.
Every conversation starts blank.
You open a chat, explain who you are, what you’re working on, what you decided last week. You get a useful response. You close the tab. Tomorrow you do it again.
The tool works fine, but the context layer underneath it is missing!
It is true that built-in memory helps a little.
Claude remembers your name and job title. ChatGPT knows you prefer bullet points. But neither knows the details about your active projects, the deal you’re about to close, the vendor you ruled out last month, or what happened in your pipeline this week.
That kind of operational state doesn’t live anywhere persistent!
The option most engineers reach for next is RAG.
RAG is genuinely useful, but it’s solving a different problem.
It re-derives knowledge from scratch on every query. You embed documents, retrieve chunks at query time, and hope the right fragments surface. Nothing accumulates.
A question that requires synthesising five documents means the LLM has to find and reassemble those fragments every single time.
The vault approach of this article compiles knowledge once and keeps it current. When you add something new, the LLM indexes it, reads it, integrates it, updates related pages, flags contradictions and maintains cross-references.
The synthesis is already done before you ask your next question.
Karpathy puts it cleanly: the wiki is a persistent, compounding artifact.
The cross-references are already there. The analysis doesn’t disappear into chat history. It builds.
Hey there! My name is Sara and I cover practical AI building every week on Learn AI. Tools, patterns, and what actually breaks in production. Free to subscribe.
The architecture: two folders and a schema file
The core structure fits in 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 an example. Feel free to customize it)
Raw is your source of truth.
Meeting transcripts, exported Slack threads, documents pulled from wherever your work actually happens. The rule is absolute: the AI reads Raw, never edits it. Append-only.
Wiki is what the AI builds and maintains. One file per project, person, decision, or domain area. Structured, cross-referenced. This is what the AI reads first when you ask a question.
If you’ve worked with data pipelines, this split is familiar. Raw is your landing zone. Wiki is your curated layer. If Wiki drifts or gets corrupted, you rebuild from Raw. You never lose the source.
The schema file sits at the root and tells any AI how the vault is organised, what to read first, and what the operating rules are. I call it CLAUDE.md. If you’re using Codex, AGENTS.md works. Name it anything, as long as you point the AI to it at the start of every session.
This is the part most implementations skip, and it’s why most implementations quietly die.
A folder of markdown files is not a system. These three files make it one.
_hot.md is the cache. Every morning, the daily automation rewrites this file with the most active threads, any key numbers or deadlines that surfaced, and one line on anything urgent. It stays under 500 tokens. When you open a conversation and want a fast briefing, the AI reads _hot.md first, no need to load the full Wiki.
_pending.md is the queue. Every time a new file lands in Raw, its filename and date get appended here. When the weekly compilation runs, it reads this file, processes each entry, compiles it into Wiki, and marks it [COMPILED — 2026-05-01]. Without this file, the daily ingest and the weekly compilation can’t coordinate. You get orphaned raw files and a Wiki that’s weeks behind.
_log.md is the audit trail. Every automated run appends a timestamped entry: what ran, what files were processed, what Wiki pages were created or updated. If the system drifts, this is how you find where. Karpathy’s gist has a useful tip here: start each log entry with a consistent prefix like ## [2026-05-01] daily-ingest so the whole log is grep-parseable with basic unix tools.
A vault without these files accumulates dust. With them, you have a working pipeline.
The schema file: teaching any AI how to read your vault
CLAUDE.md is the entry point. Every session starts here.
What goes in it:
- The folder map (what’s in Raw, what’s in Wiki, what each subdirectory is for)
- Read order (
_hot.mdalways first, then the relevant domain index) - Hard rules: “never edit files in Raw/”, “never invent facts not present in source files”, “always append to _log.md after every run”
- Domain structure (which indexes exist, how they’re named)
The schema file is also where you encode your prompting defaults. I use a very known pattern, adapted directly 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.When this is integrated into your schema, every AI that reads your vault already knows to ask before executing. You stop getting half-baked output from a model that assumed it understood the task.
The prompting philosophy worth encoding explicitly:
- Context beats prompts. Feed the AI files, not instructions.
- Examples beat prescriptions. Show what you want, don’t describe it.
- Constraints beat rules. Say what the output is NOT, let the AI choose how.
- Goals beat instructions. Say what to achieve, not how.
- State the task and the success criteria. Two sentences.
The automation layer: three cadences, not one
Two failure modes I’ve seen: you update the vault manually and it’s fine for a week, then life happens and it’s been three weeks since anything got filed.
Or you build one big automated job that ingests, synthesises, and audits all in one pass, and now your daily ingest is editing Wiki files it should never touch.
The solution is to separate the jobs. Let’s explore it below.
Daily (weekday mornings): ingestion only
Pull from your sources. Drop new files into Raw/. Queue them in _pending.md. Rewrite _hot.md based on what surfaced.
No Wiki edits. The daily job is mechanical, fast, and safe enough to run unattended every day.
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.Replace the bracketed placeholders with your actual tools. The structure works whether you’re pulling from Linear and Slack, or Notion and email, or anything else.
Weekly (Monday mornings): compilation
Read _pending.md. For each unprocessed file, read it in full, create a structured Wiki page in the right domain folder, update the relevant index, add backlinks to related pages, mark the entry compiled.
The weekly job does interpretation. It synthesises raw content into structured knowledge. It’s slower, more expensive, and worth reviewing occasionally to check the AI is filing things correctly.
Monthly (1st of the month): linting
Health check only. Scan the entire Wiki for stale pages (dates or statuses that newer content has superseded), missing backlinks, contradictions between pages, coverage gaps, and orphaned pages not referenced in any index.
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 without supervision.
Each cadence has a different risk tolerance: daily is mechanical, weekly does interpretation and monthly does diagnosis. Mixing them in one job is how vaults get corrupted.
On tooling: any system with scheduling works here. A cron job with an MCP-enabled CLI, n8n, or an AI desktop tool that supports scheduled tasks.
The prompts above are the logic. The runner is interchangeable.
What actually changes
You stop re-explaining yourself, and the conversations shift character.
When context is already loaded, you stop using AI for isolated questions and start using it for actual work.
The AI knows your open projects, your recent decisions, your team. You ask “what should I prioritise today?” and it reads _hot.md plus your project files and gives you a grounded answer.
Portability is the other thing!
Your context lives in a folder on your machine, not inside any AI’s memory system. Point a different AI at the same folder and it reads the same files. Switch tools whenever you want. The vault travels.
A few failure modes worth knowing before you build:
_pending.md backs up if daily ingest is too broad and weekly compilation can’t drain it fast enough. Tighten what you pull in daily.
Wiki drifts if nobody reads _log.md. The monthly linter catches this, but only if you actually read the report.
The whole system breaks if automation ever touches Raw. One job that writes to Raw “just this once” and you’ve lost the source-of-truth guarantee. That boundary doesn’t bend.
The tedious part of maintaining a knowledge base isn’t the reading or the thinking.
It’s the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims. Humans abandon wikis because the maintenance burden grows faster than the value.
LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass.
Karpathy traces this back to Vannevar Bush’s Memex concept from 1945, a personal curated knowledge store with associative trails between documents. Bush’s vision was closer to this than to what the web became. The part he couldn’t solve was who does the maintenance.
The vault I’ve been running uses Claude as the AI layer and a markdown tool as the front end.
The pattern works with any AI that reads files and any scheduler that can run a prompt on a clock! The folder is just a folder. The files are just text.
You set this up once. After that, your AI stops starting from zero.
Thank you for reading!