A second brain is one thing: a context layer for your AI. Folder structure, not a note pile. Structure decides where the model looks, so structure carries the thinking, not the model.
Core claim: most note systems become a graveyard with good metadata. Storage without structure = no better than the memory already built into Claude, Gemini, ChatGPT. The value is in how you shape the context, not how much you dump.
What a second brain actually is
- Definition: a layer that feeds context to your AI. Nothing more.
- Substrate: plain markdown files in folders. No database, no vector store, no API plumbing. Any model reads markdown natively.
- Obsidian’s graph view = a rendering of the link structure already in the files. Nodes = notes, edges = links. Optional viewer, not the system.
- Portable: same vault reads in Claude Code, Cowork, Codex, Cursor, Gemini CLI. Switching agents needs zero migration.
- Auditable: agent does something odd → open the file, see exactly what it wrote.
Structure carries the thinking, not the AI
The bottleneck: models are bad at deciding where knowledge lives and when to load it. Fix → don’t let the AI decide. Build the folder structure around where information matters, and the model drops each input where you told it to go.
Pull thinking away from the model. Sounds backwards. Isn’t. The computer automates what used to take thinking; you keep the judgment. A CLAUDE.md that says “transcripts go here, conclusions go there” beats “figure out what’s important” every time.
Store the signal, not the source
An 8,000-word transcript is not the artifact. The 500-word synthesis you pulled from it is. Models reason far better over a tight wiki page than over raw transcript.
Rule: process the raw thing once, keep the output. Future sessions read the conclusions, not the transcript again. Don’t feed 12 research docs → feed what you extracted from them for this specific job.
One brain per workflow, not one for everything
A brain-of-everything → back to the graveyard. Build small brains scoped to a workflow: one for weekly content sessions, one for client X, one for a recurring report.
Scoped beats comprehensive. Ask about finance → model ignores everything but the finance folder, follows the links, answers in near-zero tokens. A giant undifferentiated wiki forces a slow, token-heavy, hallucination-prone crawl.
Start from pain, not from “we need a second brain”
Wrong start: “let’s build a knowledge base and scale it to everyone.” Right start: which recurring process is annoying enough to be worth capturing?
The pain names the folders. Pull data from a tool → that’s a folder. Take notes on it → another folder. Run math on it → a skill with a script. Map the pain and the structure falls out.
A skill is a frozen workflow
Skill = a conversation you had once, written down: this is what I do, when I do it, how I do it. Not a prompt. It encodes actual folder paths, template shapes, linking conventions → grounded output instead of guesses.
At its smallest, one markdown file describing “how I break down this session” is a skill. A whole folder of them = one repeatable process the model runs the way you run it.
Three layers of AI use
- Copy-paste. You hand-feed chats, notes, transcripts into the model each time. Works, doesn’t compound.
- Skills. Higher-level descriptions of how you do a thing, reused across sessions. The model stops improvising the method.
- Structured folders + one agent. Frozen dialogue in files, you route the agent through them and decide when it reads what. You become the human in the compute layer.
The Karpathy LLM Wiki pattern
Published April 2026 by Andrej Karpathy (OpenAI co-founder, ex-Tesla AI). Same shape as the folders-and-files idea, formalized. The model acts as a research librarian: reads raw sources once, compiles a cross-linked markdown wiki, maintains it as new material arrives.
- Compile-time, not query-time. Knowledge is synthesized once into wiki pages, then read from the compiled layer. RAG re-retrieves and re-synthesizes on every query, stateless.
- Read path: index first (~1k tokens), then the 3–5 relevant pages. Skip the vector search entirely.
- Compounds. Each new source gets cross-referenced against everything already there. The 50th source is woven into a mesh, not dropped as an island.
- Behavior governed by one plain-text file (agents.md / CLAUDE.md). Want new behavior → add a line in English. No code, no redeploy.
Wiki vs RAG: when each wins
| Dimension | LLM wiki (markdown) | RAG (vector DB) |
|---|---|---|
| Best size | Bounded, roughly under 100k tokens | Large / unbounded corpora, millions of docs |
| Infrastructure | None. Files in a folder | Vector store, embedding pipeline, retrieval layer |
| Setup | An afternoon | Days: chunking, embeddings, eval loop |
| Knowledge assembly | Compile once, read compiled pages | Retrieve chunks fresh each query |
| Readability | Human- and machine-readable, auditable | Opaque embeddings |
| Multi-user / access control | Weak. Needs a separate layer | Handled at scale |
| Claim-level citation | Cited pages tend to support the exact claim | Stronger on broad groundedness |
Threshold, roughly: wiki reliable below ~50k–100k tokens, RAG past the context ceiling. Cost is not automatic: one preregistered study found a wiki spending ~21x more per query than RAG on a research-synthesis task. Mid-scale answer is usually hybrid: compiled wiki for stable core knowledge, RAG for dynamic or overflow content.
Node graphs: where they help, where they don’t
Useful
Mapping a company or a multi-part process. Nodes = teams / concepts, edges = real connections (team → task → output). Click a node, follow the link, land on the linked file. The model traverses the same links fast.
Overkill
A linear personal workflow with few real cross-links. The pretty graph adds nothing over a clean folder list. Don’t add the viewer just to have a viewer.
Common folder conventions
- PARA (Forte): projects / areas / resources / archive, plus an inbox as the dump zone so capture never requires a filing decision in the moment.
- Karpathy wiki: raw/ for sources, raw/processed/ for dedup, wiki/ for compiled pages, plus control files (index.md, agents.md, log.md).
- Router pattern: CLAUDE.md as a thin pointer that reads first and sends the agent into specific files. Capability lives in the referenced files, not the router.
- Frontmatter on every note (title, date, tags, related) so the agent can filter by tag, sort by date, follow links.
Local models and the near-term bet
- Plain markdown in folders is provider-agnostic → runs against cloud APIs or a local model via Ollama with no rework.
- Local wins: no token spend on cloud calls, data stays on the machine, speed and privacy for bespoke personal use.
- Mac mini popularity = price-to-performance without building your own GPU server, not because it’s the strongest option.
- Scaling take: bespoke local brains per person may beat one central system. Reuse existing admin / user-management tools rather than rebuilding governance.
Enterprise scaling: the unsolved part
Folders-and-files breaks down for large teams the moment access control matters. Some files must stay editable only by certain processes, readable only by certain people.
- The simple lever without custom software: user-protected files / restricted SharePoints as workspaces. Slower, and locks you inside Microsoft’s tooling.
- Governance is a separate layer. Neither wiki nor RAG solves access control, freshness, or concurrency on its own.
- Reality check: no clean off-the-shelf solution yet for multi-user ICM deployment with per-file permissions. Real code steps in here, not just markdown.
Build sequence
- Pick one painful recurring process. Skip the grand plan.
- Write down input → process → output for it. That map is the folder structure.
- Create folders where each type of information should land. Rough is fine; folders are fast to move.
- Add a thin router (CLAUDE.md / agents.md) that tells the agent where things go and when to read them.
- Process raw inputs once, store the synthesis, point future sessions at the synthesis.
- Use it, then rebuild. Expect to throw the first version away. Structure is cheap to redo.
FAQ
No. The system is markdown files in folders. Obsidian is a viewer that adds graph view and wikilinks. The brain works read by Claude, Cowork, or any file-aware agent with no viewer at all.
Built-in memory is opaque and locked to one tool. A file-based brain is readable, editable, portable across models, and structured so the agent finds the right context instead of recalling fuzzy fragments. Off understanding → open the file and fix it.
Practical ceiling around 100k tokens for a single bounded base. Past that, add semantic search on top or split into scoped brains. For large, multi-user, fast-changing corpora, RAG or a hybrid is the right call.
No. That’s the point of the structure. You encode where signal lives via the folder layout and the router file; the model routes each input to the right place instead of guessing. Letting it decide is where quality drops.
Snippets
Pain-to-Structure Audit
Run this before building any second brain or ICM, so the folder layout comes from your actual process instead of a generic template.
- Which recurring processes produce the most value for me?
- Which ones are the most annoying or repetitive?
- What tools do I use for each, and at which step?
- Where do I not want AI involved (sensitive, accountability, judgment)?
- For the top process: what is the input, what do I do to it, what is the output?
- Each distinct input source → a folder. Each transformation → a skill or subfolder. Each output → its own folder.
Tags: second-brain, workflow-audit, folder-structure, context-engineering, process-mapping
Thin Router File (CLAUDE.md / agents.md)
Drop this at the root of a vault or project so the agent routes inputs by structure instead of deciding for itself where information belongs. Fill the bracketed parts for your own workflow.
# Operating instructions
## Who you are
You operate inside this vault. You read, create, and update
markdown files here. You do not decide what is important —
the folder structure already encodes that.
## Folder routing
- raw/ Unprocessed sources (transcripts, clips, pastes). Never read in full unless asked.
- raw/processed/ Sources already synthesized. Skip on re-read.
- [output-a]/ [What lands here and when]
- [output-b]/ [What lands here and when]
## Core rules
1. Everything is markdown, with frontmatter: title, date, tags, related.
2. Process each raw source ONCE. Store the synthesis, then read the synthesis in future sessions, not the raw source.
3. When [TRIGGER], route the result to [FOLDER].
4. Ask which workflow this is before acting when it is ambiguous.
5. After each operation, update index.md and append to log.md.Variables: [output-a], [output-b], [TRIGGER], [FOLDER]
Tags: claude-md, agents-md, router, context-layer, agent-instructions
Transcript-to-Signal Synthesis Prompt
Use this once on a raw transcript or long document to produce the compact page future sessions will read instead of the raw source.
Read the source below. Produce a synthesis page a future
AI session can use instead of the raw source.
Keep: claims, techniques, decisions, numbers, named tools,
open questions. Drop: filler, repetition, anecdotes, anything
tied only to the moment.
Structure it so a model can navigate it in seconds. Lead with
conclusions. Link related concepts by name so they can be
cross-referenced later.
Aim for signal density, not length.
[SOURCE]Variables: [SOURCE]
Tags: synthesis, transcript, compression, wiki-page, knowledge-management
Scoped Query Pattern
Use when querying a structured brain, to keep token cost low and stop the model from crawling the whole vault.
- Read index.md first to locate the relevant area.
- Ignore everything outside that area for this query.
- Read only the 3–5 pages the index points to.
- Answer from those pages; follow links only if a page references one directly.
- If the answer isn’t in-scope, say so rather than expanding the search silently.
Tags: query, token-efficiency, index-first, retrieval, scoping
Minimal Wiki Folder Skeleton
Starting layout for a single-workflow brain built on the Karpathy LLM-wiki pattern. Rename to fit your process; keep the raw / processed / compiled split.
vault/
CLAUDE.md # thin router, read first
index.md # pointer to what's where
log.md # append-only activity log
raw/ # sources land here first
processed/ # sources already synthesized
wiki/ # compiled synthesis pages
skills/ # frozen workflows (how-I-do-X.md)Tags: folder-structure, llm-wiki, karpathy, scaffold, obsidian.