One question decides whether your notes are a second brain or just a folder you'll never open again: will your AI agent — and you — find this again later? If the answer is no, the problem isn't the model. It's how you stored and routed the information. I'll show you the five levels of a second brain, what each is for, and — just as importantly — how to know when you do not need to climb higher.
The term first, because people use it loosely. A second brain is a place where you save what matters — notes, meeting recordings, decisions, project context — organized so an AI agent can ingest it, put it in the right spots, and recall it later in a way that makes sense, instead of hallucinating or burning your time and tokens hunting through everything. The idea exploded because we're all trying to get knowledge out of our heads into a reusable system. That knowledge is your moat. It's your IP. The hard part isn't having it — it's organizing it so a machine can give it back accurately.
Two ideas to hold before the levels
The first: going up is not "better." Each level solves a different problem, and the skill is finding the lowest one that removes a pain you actually feel. No pain point, no reason to invent a new architecture. I'll repeat this at the end, because it's the rule people most often break — reaching for a knowledge graph when a plain folder would have done.
The second: work backwards from the question. How you'll retrieve the data decides how you should store it. Think of a basketball and a hoop: the hoop is round, so you'd never make the ball a cube — it wouldn't fit. Before you save anything, ask how you'll want to ask for it later, and let that shape the structure. It gets concrete fast.
One more thing that holds for all five: one project doesn't live on one level. Inside a single second brain, one folder can be at level two while another is at level four. You decide per folder, based on the data and how you use it.
Each level answers a different retrieval question:
- Can I find it by an exact word or file name?
- Can I pull everything on one topic together?
- Can I find it when I search by meaning, using different words than I wrote?
- Can I trace relationship chains — ask about topic X and follow it back to topic A?
- Can the whole thing run always-on and autonomous, so I barely think about it?
Level 1 — find it by exact word or file
This is where you always start, with one routing file. In Claude Code it's a CLAUDE.md; in other tools, an AGENTS.md. It loads automatically when the agent opens that folder — think of it as the system prompt for the project. It tells the AI who you are, how you work, and, crucially, where things live.
That last part is the whole point: the CLAUDE.md is a router. It carries your role, but also routing rules — "information about me lives in this folder; quarter-one priorities live in that one." If you've ever asked your agent to do something and it came back with "I don't know what you're talking about" even though you know the files exist, that's almost always missing routing. The agent will not search your whole project on its own; you wouldn't want it to, because that wastes time and tokens. If it doesn't know something lives somewhere, it won't find it.
The structure underneath is plain folders and markdown: a context folder (an about-me file with always-true background on you and how you work), a decision log (the agent appends a dated entry every time you make a big call), and a projects folder (a file or subfolder per ongoing project or client — break it down by month if you like). That's basically it.
A practical test that routing works: you need a slide deck you built for a video and can't ask the AI. You go to projects, then the YouTube subfolder, then the dated entry — there's the deck. You find it because the drill-down makes sense, and so can your agent, because the routing mirrors how you think. Done well, you stop re-explaining yourself; the agent knows where to look and why.
There's no single proven "right way" to lay this out — don't copy my structure, or anyone's, as the only correct one. What matters is that routing exists and makes sense to you and to your AI. The risk here is simple: grow it too big and it gets messy and starts to feel ignored. That pressure nudges you toward level two.
Level 2 — pull everything on one topic together
Level two is when you build a wiki: files with indexes the AI drills down through. Instead of one flat folder, you get topic hubs — say agentic workflows, AI coding, context window — each linking out to related tools, concepts, and pages. The agent starts at the index for the topic you asked about, reads that page in full, then follows the trail to the next relevant page and reads that too. It reads whole pages along a trail, not snippets.
Those links and "see also" pointers create relationships — but be careful, this is not yet a knowledge graph. The links are like backlinks: they say "these two pages are connected" without naming how. There's no "this is endorsed by that" or "this is a competitor of that." Similar effect in places, genuinely different mechanism. I'll come back to the real graph at level four.
Level two is also where auto-memory earns its place. In Claude Code you can turn it on (run /memory to check whether it's on, and switch it on if not), and the AI will write and update a memory.md file on its own. Keep your brain tool-agnostic here: Claude Code reads CLAUDE.md and maintains that memory.md; to run the same brain in another tool, copy CLAUDE.md to AGENTS.md (keep them essentially identical) and add a routing rule so the other tool reads memory.md too. It's all routing.
A note on tools: a visual app like Obsidian simply visualizes your markdown files as a graph. It's nice if you're a visual person and easy to set up — but it adds no capability your agent doesn't already have. The files are the substance; the graph is just a view. Use it if it helps; skip it if it doesn't. A lot of serious work can live happily at level two for a long time — the reason to move on is a specific pain, not ambition.
Level 3 — search by meaning
Level three adds semantic search: searching by meaning instead of an exact word. The engine behind it is a vector database. The mechanism, plainly: you take a document — say a transcript — and chunk it into pieces; each chunk runs through an embeddings model that places it as a point in a kind of "meaning space," where position corresponds to meaning. Chunks about the same idea land near each other.
The payoff: keyword search asks "where does the word X literally appear?" — X equals X. Semantic search asks "what is similar to X?" — X is like X, Y, and Z. Search "feedback" by keyword and you only see that literal word. Search it semantically and you also surface things that mean feedback — test results, evaluations — even when the word never appears. That's powerful for pulling one specific snippet out of a huge body of text: store a thousand rules, ask "what did rule 17 say?", and vector search fetches the right chunk — far cheaper than making the agent read all thousand.
But — the part people get wrong — vectors are not magic. Because chunking breaks a document apart, it loses full context. Put a March 5th meeting transcript in as twenty chunks, then ask "summarize the March 5th meeting." The agent pulls back maybe five chunks similar to "meeting summary" and summarizes those — it can't see the whole transcript, so it may miss key information. Same trap with a sales table: ask "which week had the highest sales?" and a chunk-based lookup might grab a slice showing week six as the peak, while weeks fourteen and nineteen were actually higher and sat outside the fetched chunks.
The rule of thumb: when you need a specific snippet from a large pile of text, semantic search shines; when you need full context, a plain markdown file the agent reads in full is more accurate. And you don't pick one for the whole brain. You can mix: make one unit — say your transcripts — a vector folder, and keep context, projects, and decisions as markdown. Data type and use decide the structure, folder by folder. A useful move is to describe the data to your agent — "here's what I have and how I'll use it; markdown or semantic search?" — and let it walk you through the setup.
Level 4 — relationship chains (a knowledge graph)
Level four is the knowledge graph: not just files that link to each other, but entities plus named relationships between them. The graph knows Jordan works at Acme; Acme is endorsed by Postpilot; Postpilot is a competitor of Cadently. It stores not only the things but how they relate — letting you trace topic X all the way back to topic A. This is usually the most complex level, and often the most expensive on a managed platform (there are open-source options — LightRAG, Graphiti and similar — if you'd rather host it yourself).
There's a subtle efficiency win. A wiki page is read in full even if you needed one fact from it — chasing one tool name on a long "AI video production" page still costs the whole page. A graph is lighter to read: it goes straight to the related node and reads just that, not the entire file.
The catch isn't usually the software — most graph tools embed your data and build the relationships automatically. The catch is giving it enough data to build from. This is where I lean on an interview method. I run a skill that interviews me relentlessly about one topic and won't stop until it has pulled the knowledge out of my head into a file: "interview me about client A, about business B." It asks questions, and you can also feed it source material — transcripts, contracts, documents. That's how you generate enough structured knowledge for a graph to be worth building.
A privacy point you can't skip: processing all of this through a cloud model means that data is not private — it goes to the provider. For your own business notes that may be a fine trade. For sensitive client data, think hard, and consider routing it through local or open-source models instead, so your most confidential material never leaves your environment.
And the most common misconception: people assume the problem is the system failing to retrieve — and sometimes it is. But more often the real problem is that the knowledge never made it out of your head into the system. Before you blame the AI, open your folders and ask: is this actually holistic? Does it hold the nuance I carry in my head? If not, no level of retrieval will save it.
Level 5 — an always-on, autonomous brain
Level five is the always-on brain-OS. It has everything from the lower levels — routing, wikis, relationships, tools — plus an always quality: it constantly syncs, refreshes its memory, and adds knowledge on its own, to the point where you barely have to think about it. You can assemble this in Claude Code, but you'll be the one managing the scheduled jobs (the crons) that keep it syncing — that operational overhead is a real reason to be deliberate before reaching for it.
There's a caveat I take seriously here: too much context can do more harm than good. When a system ingests everything automatically, you lose the judgment about what's worth keeping. I prefer to stay in control of what my brain ingests — pulling in the week's meeting notes deliberately, brainstorming a topic and then ingesting it together — precisely because more is not always better.
Find your level — and what to feed it
You don't choose a level by ambition; you diagnose it by your pain. Use this:
- Re-explaining your setup, searching by exact word or file? That's level one.
- 30+ notes and you keep forgetting what's in them? That's level two — ingest them into a wiki with indexes.
- **Routing keeps whiffing on notes you know exist?** You want something that doesn't rely on an exact word match — level three, semantic search.
- You need relationships and chains of thought — follow topic X back to A? That points to level four, a knowledge graph.
- Running agents offline, syncing many agents together? That's level five, the always-on brain.
The last piece is what you let in — context versus connections. Feed your brain context: evergreen, holistic data — what the business has done, locked-in decisions, this quarter's goals. Ask of each item, "in a year, will having this memory still help me?" If yes, it belongs. Keep connections out: volatile data that changes week to week — Slack threads, emails, customer records. Ingest that and it's just noise you'll have to go back and delete every month.
But "keep it out" doesn't mean "cut it off." Give your brain access to fetch the volatile source live when it's actually needed. That produces a clean retrieval cascade: a vague question first hits the evergreen goals file; if the answer isn't there, it checks the wiki and transcripts; only as a last resort does it reach into the live source — the ticketing tool, the inbox — for real-time data. A real second brain isn't the one that memorized everything. It's the one that knows where to look, and in what order, and hands you an accurate answer.
So before you climb a level, return to the one question this all rests on: will you — and your agent — find this again later? If routing already answers yes, you're done. Boring folders and plain markdown are beautiful when they work. Pick the lowest level that removes a real pain, get your own brain working before you worry about your team's, and add complexity only when something actually hurts.
