An LLM markdown wiki turns sources into an interlinked set of markdown files the model maintains, so you spend time using knowledge instead of reorganizing it - inspired by Andrej Karpathy's llm-wiki pattern and tested here as a personal second brain.
What is an LLM markdown wiki?
Karpathy's idea is not a product. It is a pattern you paste into an agent so the model becomes a disciplined wiki maintainer. Three layers matter:
- Raw sources - immutable inputs (articles, notes, exports). The model reads them; it does not rewrite ground truth.
- The wiki - a directory of markdown the LLM owns: summaries, concept pages, entity pages, cross-links, and an index.
- The schema - a project instruction file (for example
AGENTS.mdor a Cursor skill) that defines structure, ingest rules, and how to answer questions from the wiki.
The important contrast with classic retrieval is compile once, then maintain. Instead of re-deriving answers from raw chunks on every query, the model integrates each new source into the existing wiki - updating summaries, strengthening links, and noting contradictions. Knowledge compounds as files, not as chat history that disappears when the thread ends.
That framing also sits beside LLM context windows: you still respect token limits, but durable structure lives on disk rather than in one giant prompt.
Why let the LLM own the files?
The experiment started with a simple question: can this pattern actually reduce the maintenance tax of a personal knowledge base?
In practice the model writes summaries, extracts concepts, creates links, and keeps pages coherent over time. The wiki files are almost never edited by hand. That is the point. Manual upkeep is what turns "second brain" systems into guilt piles - folders you organize instead of use.
Letting the LLM own the wiki layer does not mean trusting every sentence blindly. You still review answers and spot-check pages that matter. It means you stop spending evenings renaming notes and redrawing folder trees. Time moves to asking better questions of a structure that already exists.
This is the same ownership mindset that separates disciplined AI-assisted coding from autopilot dumps: the human steers intent and quality; the model does the repetitive synthesis work.
How does Obsidian help review structure?
Obsidian is not the author of the wiki in this setup. It is the review surface - especially the graph view.
The graph shows whether topics flow from general ideas to more specific ones. When something sits at the wrong level of detail, it stands out immediately: a leaf concept floating next to a broad theme, or a dense cluster with no clear parent. Clear organization matters because mixed levels of detail make the knowledge base harder to use even when individual notes are accurate.
A useful habit after each ingest batch:
- Open the graph for the area you just updated.
- Check that new nodes hang under the right parents.
- Ask the agent to re-level or split pages that feel both too broad and too deep.
You can browse the same markdown in any editor. Obsidian simply makes hierarchy and orphans visible faster than scrolling file trees.
Why use Cursor as the main interface?
Cursor is the main interface for adding notes and searching the wiki on desktop. Prompts stay close to the files: ingest this source, update these concept pages, answer from the wiki only. That matches how agent workflows already work for code - intent, scoped files, review - and pairs well with spec-driven habits when you want the schema itself to stay explicit.
On mobile, the Cursor app with cloud agents keeps the same knowledge base available away from the computer. Context stays continuous across devices because the vault is the source of truth, not a single laptop chat session.
For teams and products that later expose the same knowledge through tools rather than a personal vault, MCP is the natural next boundary - typed resources and tools instead of dumping entire folders into a prompt. This article stays on the personal markdown pattern; MCP is the production bridge when multiple clients need the same corpus.
How does frontmatter-first search cut tokens?
As the wiki grew, full-file searches started costing more tokens and time. Every "find everything about X" turned into opening many markdown bodies the model did not need.
The fix was simple:
- Add frontmatter to every document - topic level, type, status, and key concepts.
- Build a search skill that checks frontmatter first (Cursor Agent Skills).
- Open full files only when metadata is not enough.
Responses stay faster and cheaper. The skill behaves like an index: narrow candidates by metadata, then read. That is the same selective-context discipline as production assistants - load what you need, not the whole repository - applied to a personal vault.
Example frontmatter shape (adapt fields to your schema):
---
topic_level: concept
type: summary
status: active
key_concepts:
- llm wiki
- frontmatter search
---
What is next for this system?
Today the system is used for notes and search. Further productivity gains are expected as the ingest and query loop becomes habitual rather than experimental.
Next, more personal and operational documents will be added so they can be analyzed quickly and the needed information found without hunting through folders. Sensitive material stays out of any shared or published copy of the pattern - the wiki is useful only if you trust what you put in it and keep private sources private.
If you are building the same idea for an engineering org later, start with the personal loop first: schema, ingest, lint, frontmatter search. Scale to shared vaults and MCP only after the compile-and-maintain habit is proven.
FAQ
How is an LLM markdown wiki different from RAG?
RAG retrieves chunks from raw documents at query time and synthesizes an answer in the moment. An LLM markdown wiki compiles sources into lasting markdown pages ahead of time, then answers from that maintained layer. You can still use retrieval against the wiki, but the core idea is a compounding archive - not re-deriving structure on every question.
Do I still edit wiki files manually?
Almost never in this experiment. The model creates and updates wiki pages; you review structure and correct rare mistakes. Manual edits are reserved for schema changes and fixing pages the lint pass keeps getting wrong - not day-to-day filing.
Is Obsidian required for an LLM wiki?
No. Any markdown-friendly editor works because the vault is plain files. Obsidian helps because the graph view makes hierarchy and weak links obvious. Treat it as a reviewer, not a dependency of the pattern.
What should go in document frontmatter?
Enough metadata to filter without opening the body: topic level (for example theme vs concept vs detail), document type, status, and a short list of key concepts. Keep the schema small enough that the agent fills it consistently on every ingest.
How do you keep context continuous on mobile?
Use the same vault with Cursor cloud agents so desktop and mobile share one file tree. Continuity comes from the wiki on disk, not from carrying a long chat transcript between devices.
Key Takeaways
- Compile knowledge into markdown once; do not re-derive it from raw sources on every query.
- Let the LLM own the wiki layer so maintenance does not eat your attention.
- Use a graph view to catch mixed abstraction levels early.
- Cursor desktop plus cloud agents keep one vault available across devices.
- Prefer frontmatter and a search skill before opening full files.
- Start with notes and search; expand document types only after the loop is stable.
- Keep sensitive personal documents out of any shared or public copy of the pattern.
References
- Andrej Karpathy, llm-wiki - pattern for LLM-maintained personal knowledge bases (raw sources, wiki layer, schema; ingest / query / lint).
- Cursor, Cloud Agents - running agents against a shared environment from desktop, web, and mobile.
- Obsidian Help, Graph view - reviewing note connections and hierarchy.
- Cursor, Agent Skills - packaging workflows such as frontmatter-first search.