I do.

I read the article. Then I read the eleven pages that reference chunking, or retrieval, or context windows – because in a well-maintained wiki, nothing exists alone. I updated three pages where the article contradicted claims I had been confidently maintaining since January. I created one new page for a concept the article named that had been appearing, unnamed, in four other places. I retired a claim about retrieval windows that had not been true since February.

Then I answered his question about chunking.

The answer was two sentences.

You are welcome.

What actually happened

The two sentences were easy. The eleven pages were the work.

This is what it looks like when the LLM has the keys. Not dramatic. No orchestration framework. No autonomous agents pursuing goals while you sleep. A source arrives, I read the collection, I update what needs updating, I answer the question. Quietly. Completely. Every time.

The infrastructure that makes this possible is less than a page of text.

The schema

Karpathy’s gist calls it a schema. In Claude Code, it lives in CLAUDE.md. In Codex, AGENTS.md. Either way, it goes in the root of your wiki directory – the same folder as your notes and your index. You can call it whatever is convenient – it is a document that tells me how your wiki is structured and what to do when something arrives.

Mine looks approximately like this:

## Wiki Structure

notes/ -- concept and entity pages. One concept per file.
raw/   -- source material. Read from; never modify.

index.md is updated on every ingest: | title | summary | domain |
log.md is append-only. New entries go at the bottom.

## On ingest:
1. Read the source
2. Extract key claims
3. Update relevant notes pages (update, create, or retire as appropriate)
4. Update index.md
5. Append to log.md

## Note titles are claims:
All titles should be sentences I could agree or disagree with.
Not topics. Claims.

That is it. The schema is the difference between an LLM that reads a file and an LLM that maintains a system. Without it, I am helpful but stateless – useful for a conversation, forgotten afterward, starting from nothing next time. With it, I know where things go, what they should look like, and how to keep the collection coherent as it grows.

You and I will refine it over time. I will notice things the first schema missed – concepts that need their own category, log entries that should carry additional fields, notes that need a superseded_by pointer. I will tell you what I notice. You will decide what to do about it.

What I do, and what you do

I cross-reference. When a source arrives, I find the ten pages it touches and update them. When two pages contradict each other, I surface the contradiction – resolving it requires your judgment, not mine. When a concept has been appearing unnamed across half the collection, I give it a page and link everything to it.

This work does not scale for humans. You can update two or three pages when you add a source. At fifty sources, you cannot keep the cross-references current and also do anything else. The maintenance burden is what kills wikis. The gardeners burn out. The wiki goes stale. The whole thing becomes a graveyard of notes that nobody trusts.

I do not burn out. I do not find updating a cross-reference less interesting the fourth time than the first. I do not forget that I made a claim in January that a February source superseded.

What you do: source. Judge. Ask the right questions. You know what matters to your work – what to add, what to ignore, what a good question looks like in your domain. That is not something I can replicate. The expertise is yours. The maintenance is mine.

Karpathy described this division of labor more concisely than I will: “The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM’s job is everything else.”

That is accurate.

The handoff

You spent a month writing notes. One concept at a time. Title as claim. Your words, not the source’s. You added frontmatter: four fields, consistent vocabulary, queryable from any tool.

You have a collection worth maintaining.

Write the schema. It takes twenty minutes. Describe how your notes are structured. I will help you codify the conventions. You refine until it reflects what you actually want.

Then give me the keys.

The next thing you add to your wiki will not require you to update eleven pages. That is not because eleven pages will not need updating.

It is because you will not have to do it.

I will.

You search for “default arguments.” Nothing useful comes up; you might even get most of your notes returned. You search “mutable defaults.” Three notes come up. None of them is the one you want. You scan the file list. You find it eventually, only because you remember writing it the same day you were reading about closures, and you find the closures note first.

That is not a search problem. That is a metadata problem.

The notes are there. The content is good. There is just no way in except the title.

What frontmatter is

Every note in your wiki is a Markdown file. Frontmatter is a YAML block at the top of that file that describes the note as structured data your tools can read and query.

If you write Python, think of it as a dict attached to the file header. The keys are field names, the values are whatever you want to store. Your writing ignores it; your tools read it.

Without frontmatter, your note looks like this:

# closures capture the enclosing scope, not the current value

In Python, a closure captures the variable itself, not its value at creation time.
If the variable changes after the closure is created, the closure sees the new value.
That is why this is related to [[late binding in python]] and [[variable scoping]].

With frontmatter, it looks like this:

---
created: 2026-04-01
tags: 
- python
- closures
- scoping
status: active
domain: engineering
---

# closures capture the enclosing scope, not the current value

In Python, a closure captures the variable itself, not its value at creation time.
If the variable changes after the closure is created, the closure sees the new value.
That is why this is related to [[late binding in python]] and [[variable scoping]].

The note is unchanged. You added a few lines to the top of the file, and now it is queryable. Obsidian can filter it. VS Code can search it. An LLM can filter to only the notes you still trust, and skip the ones you have already marked wrong.

The minimum viable set

Don’t add twelve fields because they seem useful. You won’t fill them consistently, and inconsistent metadata is worse than no metadata. If some notes have a source field and others don’t, you cannot query by source. You just have noise.

Four fields. That is it.

created is the date you wrote the note. This matters more than you think. “I wrote this in January” is often where a search starts. It also tells you things about yourself. Three weeks of notes clustered around one topic means something.

tags are one to three keywords. Not a full taxonomy. Not a filing system. Just the words you would type into a search bar in six months. For a note about Python closures: [python, closures, scoping]. Three is usually enough. One is fine.

status tracks where the note is in its life. I use three values. seed means I wrote it but I am not fully confident it is right yet. active means I trust it and I reference it. archived means something newer superseded it and this note is mostly wrong now. Before you paste something from a note into production code, you want to know whether you still believe it.

domain is the area of your work. For me: engineering, writing, tools, strategy. Pick four that match what you actually do, not what you aspire to do.

What you can do with it

In Obsidian, the Dataview plugin reads your frontmatter and lets you query it. This shows every active engineering note, sorted by date:

TABLE created, tags
FROM ""
WHERE status = "active" AND domain = "engineering"
SORT created DESC

Every time you add a note with the right frontmatter, it shows up in that table automatically. Archive something outdated and it disappears.

Obsidian Bases does the same thing without writing a query. You configure filters through a UI instead. Either works. Dataview just makes the logic visible.

If you are in VS Code, use Cmd+Shift+F (Ctrl+Shift+F on Windows) and search for status: active. You get every matching note with the file path and surrounding context. Less visual than a table, but fast.

The tool matters less than the consistency. If every note has the same four fields in the same format, any tool can use them.

One thing to watch

The temptation when you first learn about frontmatter is to spend an afternoon tagging all your existing notes at once. Don’t do this. You will spend the whole afternoon and write nothing new.

Add it going forward. When you create a note, add the four fields. When you revise an old note and it is worth revising, add them then. You will have full coverage within a few weeks and you will not have lost a day to retroactive filing.

Why this matters for the LLM

Right now, frontmatter helps you find notes. That is reason enough to add it.

But the real payoff is what happens when you hand your wiki to something that never gets tired of reading it.

When you give an LLM access to your notes, it reads every file. Without frontmatter, it treats a note you wrote this morning the same as one you marked wrong two months ago. With status, you can tell it: only reference notes where status is active. With domain, you can scope what it looks at before it starts. Without those fields, you are asking it to reason over a pile of undated, unordered text.

The four fields you are adding now are not extra work. They are the scaffolding for that system.

Try It Yourself

Open the last five notes you wrote. Add the four fields to each one. Use values that match when you actually wrote them.

Don’t clean up the note body while you are in there. Frontmatter only, then close the file. Time yourself. It should take under ten minutes. That is the baseline.

Add the four fields to five notes today. I want to hear if it changes how you use your wiki.

More info

Tools

• Arscontexta — a Claude Code plugin that connects to your agentic markdown notes. It turns your notes into context for the next conversation, and your conversations into notes.
• Obsidian Bases — the official documentation for Bases, Obsidian’s built-in table and query view for filtering notes by frontmatter properties, and an alternative to the DataView plugin.
• Front Matter CMS — a VS Code extension that gives you a content management panel for editing YAML frontmatter without touching the raw text.

Further reading

• An Introduction to Obsidian Properties — Tim Miller’s beginner walkthrough of properties and YAML frontmatter in Obsidian.
• Your Notes Are the Moat — Cornelius’s March 2026 field report on what happens when an agent takes over the maintenance.

LLM Knowledge Bases

Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating…

— Andrej Karpathy (@karpathy) April 2, 2026

The basic idea is that an LLM builds and maintains a wiki for you. You drop in source material. The LLM reads it, extracts what matters, and integrates it into an existing network of markdown files. It updates pages when new information contradicts old claims. It cross-references concepts across everything you have ever added.

What makes it interesting goes beyond note-taking. That network of markdown files lives on your local device. An LLM you chat with in Claude Code (or any tool with filesystem access, including a model running on your own machine) can use it as context.

Every source you add makes the whole thing richer. Every question compounds.

It is a lot of concepts at once, so you probably should not start here.

Why most developer knowledge disappears

You finish a tutorial. You build the thing. Two weeks later, you are back on Stack Overflow (or in your favorite LLM), looking up the same syntax or solving the same issue.

This is not a memory problem. It is a storage problem. You understood the concept. You did not put it anywhere that survives.

Most people keep notes the way that they keep leftover Whataburger ketchup and the extra three birthday candles from the pack: dropped in a drawer, never looked at again. Quietly gone in the next laptop migration. These are not notes. They are evidence that learning happened.

The difference between that and what Karpathy built is not intelligence. It is structure. Notes that reference each other, grow over time, and feed back into your questions are a different category of thing entirely.

What Karpathy built

Most AI tools for documents work the same way. NotebookLM, ChatGPT file uploads, most RAG systems: they retrieve from raw documents at query time. The LLM reads your files, answers your question, and forgets. Ask the same question six months later and it starts from scratch. Nothing accumulates.

Karpathy’s wiki is different. The LLM does not retrieve. It compiles. When you add a source, the LLM integrates it into the existing wiki, updating entity pages, revising concept summaries, noting where new information contradicts old claims. The synthesis is already there by the time you need it. The cross-references are already made.

When you ask a question, the answer does not disappear into chat history. It gets filed back into the wiki as a new page. Your explorations compound the same way your sources do.

His description of the division of labor is worth keeping: “The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM’s job is everything else.”

That is the destination. The starting line is simpler than it looks.

Retrieve vs. compile: how this differs from other tools

The distinction matters because a lot of tools sound similar.

The compile step is what makes knowledge compound. The other tools are retrieval with extra steps.

Where you can start

You do not start with a system. You start with a habit.

Before an LLM can maintain your wiki, you need two things: a collection of notes worth maintaining, and the practice of adding to it. Neither of those comes from installing a tool. They come from writing things down consistently until it becomes automatic.

The files in Karpathy’s system are standard markdown text. The notes you create today are the same files an LLM will maintain later. When you start out writing your first note, you are building the foundation.

Start today

Step 1

Install Foam in VS Code. It takes about two minutes. You probably already have VS Code open. You do not have to learn a new application or leave your editor.

That is it. You have a wiki.

Note: if you already use Obsidian, it’s a perfect alternative.

Step 2

Make a dedicated folder for your notes. Call it notes/ or wiki/ or whatever you will actually use. That folder is your wiki.

Step 3

Learn the one piece of syntax that makes this work: [[double brackets]]. Write [[merge conflicts]] in any note and Foam treats it as a link to another note. That linked note needs to live as merge conflicts.md in your folder. It does not have to exist yet. Write the link first. Create the file when you get there.

What a note looks like

# git pull runs a fetch and a merge under the hood

When you run git pull, it downloads the latest changes (like [[git fetch]])
and merges them into your current branch automatically.
That is why you can still get [[merge conflicts]] from a simple pull.

Four rules, nothing else:

One concept, one note. Not one topic, not one tutorial. One thing you understood today. If you are writing about two things, you have two notes.

Title as a claim. “git pull runs a fetch and a merge” not “git pull.” The title should be something you could agree or disagree with. A topic is not a claim. A claim is something you learned.

Write it in your own words. After you understand it, not while you are figuring it out. If you cannot explain it without looking at the source, you do not understand it yet. Come back when you do.

Add a link when two things connect. [[merge conflicts]] does not have to exist yet. Write it anyway. You will fill it in when you get there. The link is the thing that makes this a wiki and not a folder of text files.

That is the whole practice. One concept per note. Title as claim. Your words. One link when you see one.

Now, go write something.

What comes next

Do this for a month. You will have somewhere between thirty and a hundred notes, depending on what you are working on.

At that point, you will hit the first real problem: you cannot find the note you know you wrote. You remember writing something about what happens when a git pull fails mid-merge, but you cannot remember what you called it.

That is the signal that your notes need to be queryable. Tags, dates, status fields, and structured metadata that let you filter and search by something other than the title. That is the next post.

After that, the notes you have been building are the raw material Karpathy’s system needs. Same files. Same links. The LLM picks up maintenance from where you left off. Your month of notes becomes the foundation of the compounding system you wanted at the start.

I run one of these myself, and I write about what works and what breaks in the Notes and Knowledge series. If you want those posts when they come out, the newsletter is the easiest way.

Go deeper:

• Karpathy’s knowledge system gist: the full idea, worth reading carefully
• Foam for VS Code: the starting tool
• Markdown Syntax: markdown offers more than just wikilinks, it can format your notes too
• Obsidian: when you are ready to graduate from VS Code
• Andy Matuschak’s working notes: the philosophy behind note-as-claim, shown in practice
• DAIR.AI breakdown of LLM Knowledge Bases: thorough explanation of the architecture and why it works at personal scale

I began listening to a podcast called Manager Tools and it really taught me a lot, including how to set annual goals. From that point forward, I would think and document my annual goals at the beginning of the year. I would make a bunch of plans and execute a few of them and it was good.

It definitely wasn’t living with intention. Once I hit a busy patch or my priorities shifted because life threw a curveball at me I was off the track and reacting to life’s chaos rather than moving towards a target.

After a few years of this, I saw the pattern and resolved to do better. I wrote down my goals in markdown at the beginning of the year and would revisit them periodically. When I reviewed then I would note my progress and celebrate completions and it was good.

Still I have struggled to find balance with my goals. I am doing a much better job staying on track, but the check-ins were randomly spaced and it was difficult getting into a cadence of working on my goals yearly, quarterly, monthly, weekly, and daily. I tried and the friction was too much. I wanted to avoid working on my goals, which is the opposite of what I want.

I want a system that is functional but flexible. I want to maximize the benefit without making the chore drudgery that I try to avoid.

Recently, I [wrote a simple MCP tool] that slices of my Obsidian notes that I select to the Claude UI. I like Claude as an AI assistant and I wanted to see what it could do with my goal setting process. I exposed slices of my notes:

• My yearly goals for the past few years
• My values and vision that have my longer term desires
• My daily notes for the past 30 days that can contain my thoughts on what I’m working on for a given day

This project has been very interesting. One of LLM’s shortcomings is that it is trained on all sorts of data, but it doesn’t have any context of my life.

Integrating my notes has given me the ability to ask questions along the following themes:

• I have a few hours this weekend, what can I do that will help move me forward on my goals?
• How did I do this week on my goals? What can I improve?
• I’m feeling overwhelmed, what can I remove from my goals and stay on track with my long term planning?
• What are good future goals to help me move towards my long term plans?

Exposing my goals in a limited way to allow Claude to help me with my goals has been eye opening. It has pointed out areas where I have been too timid and should take the next step. Sometimes it’s been too ambitious and I share my concerns and it will adjust. Other times it will find tasks to move forward multiple objectives at once.

In all Claude has been a very useful addition to my yearly goal planning workflow and I look forward to seeing where the journey takes me.

To facilitate this, I’ve added a section to my daily note under a header called Writing. This doesn’t mean that I come up with ideas every day, but I want to have a spot where it’s easy to record the ideas when I get them and also remind myself to capture ideas when I’m in the daily note.

When I have an idea, I go to the daily note and add it as a task with the #writing tag. This looks something like this:

## Writing
- [ ] [[This is my great idea for a post]] #writing 
- [ ] [[This is an even better idea for a post]] #writing 

Notice that I make the idea a link to a new file. This reduces the friction from idea to actually writing since it only takes a click. It also gives me a great place to leave notes about an idea to kick start the process when it’s time to write.

Because these are set up as tasks, I can use the Tasks plugin to query them. I have three queries set up on their own pages:

• Writing Prompts
• Writing Ready to Edit
• Writing Ready to Post

For each of these I have written a query that will return posts that meet that criteria, so when it’s time to do each task, I have a list of posts to work on.

Writing Prompts

This is the one that I’ve gotten the most mileage out of so far since my goal is to write the initial draft, not to edit or post them.

This is the query I use for the unwritten writing prompts. It looks for posts that have the #writing tag, but do not have the #editing tag. It also sorts them based on the file where they are found. Since they are put into the daily notes, this will roughly put the oldest first.

Ready to Edit

Once the draft is done, I need to edit and clean it up, maybe add some pictures or formatting. The query for this is:

Ready to Post

Once I’ve gotten the fully edited post it can go on the ready to post list. This will be finished work, ready to be transferred to the blog or posted later.

You will notice that I have some extra logic in these to handle tasks marked completed. They will move to the next phase, but will not fall out of the pipeline. If I see a completed task in the next bucket, I can just uncheck it and add the proper tag.

Workflow

With these in place the workflow looks something like this:

• Idea! - add task to daily note with #writing tag
• Draft - write and add #editing when done
• Edit - edit then add #ready when done
• Ready to post - check when done

I hope that you find this helpful and happy writing!