Your second brain: a personal knowledge OS and the LLM wiki

Your mind is for having ideas, not holding them. The problem is that almost everything you learn, the article that changed how you think, the conclusion you reached at 2am, the name of that one tool, leaks out within days. A second brain is the fix: an external, trusted system for what you know, so your actual brain is free to think and create. This guide is the practical version, from the first note to a knowledge base you can ask questions in plain language, an LLM wiki of your own.

It covers what a second brain really is and the workflow that makes it stick, the tools (Obsidian, Notion, Logseq, Tana and the rest) and how to choose, why owning your notes in plain files matters, how links turn notes into a graph, and then the new part: putting an AI over your knowledge so you can interrogate it instead of just searching it. We built exactly this at company scale, a relationship graph you can query, so the last chapters are grounded in having actually done it.

1. What a second brain actually is

A second brain is an external, trusted system for what you know and want to remember, sitting outside your head so the head itself is free to do what it is good at: thinking, connecting, deciding. Your biological brain is a brilliant processor and a terrible hard drive. It loses the name of the book you read last month, the exact figure from a pitch deck, the half-formed idea you had in the shower. The premise of a second brain is simple: stop asking your mind to store, and let it think instead.

Crucially, this is not "take more notes." It is a single place you actually trust, so that the moment something matters, you offload it without friction and retrieve it without digging. Trust is the whole game. A note you are not confident you can find again is worse than no note at all, because it costs you the capture and gives you nothing back.

Where the idea comes from

The term was popularised by Tiago Forte in his 2022 book Building a Second Brain (the method and his school sit at buildingasecondbrain.com). Forte gave the practice two backbones that are worth knowing even if you never read the book.

The first is PARA, a way to organise everything you keep by how actionable it is rather than by topic:

• Projects: active efforts with a finish line (ship the Q3 release, plan the offsite).
• Areas: ongoing responsibilities with no end date (health, hiring, your company's finances).
• Resources: topics you care about and may reuse later (pricing strategy, a city you keep visiting).
• Archives: anything from the first three that has gone cold.

Organising by actionability is the move that separates this from a normal folder tree. The same article about pricing lives in a Project if you are pricing something this week, and demotes to Resources when you are not.

The second backbone is CODE, the workflow that turns input into output:

1. Capture: save what resonates (a quote, a chart, a stray idea) with as little ceremony as possible.
2. Organise: file it for action, not for tidiness, ideally into PARA.
3. Distill: pull out the signal. Forte calls his version progressive summarisation: bold the key lines, then highlight the keys among those, so a future you can grasp a note in seconds.
4. Express: use it. Write the post, make the decision, build the thing.

The folder of forgotten notes

Most people already have a proto second brain, and it is broken. It is a Notes app with 400 untitled entries, a Downloads folder of PDFs opened once, screenshots nobody will ever scroll back to. That is not a second brain. It is a landfill with search. The difference is not the tool, it is whether anything ever comes out again.

A second brain is measured by what you create with it, not by how much you have crammed into it.

It is for use, not hoarding

This is the point that most people miss, so it is worth stating plainly: the value of a second brain is realised at the output end. Hoarding feels productive (saving an article scratches the same itch as reading it) but a vault you never query is just anxiety with a backup. The questions that matter are: when you sit down to write a proposal, does the system hand you the three best things you already knew? When a decision comes up, can you surface the data you collected in March?

A concrete example: a founder gets a competitor's pricing email forwarded by a customer. In a hoarder's setup it becomes screenshot number 412. In a working second brain it is captured into the "Pricing" Project, distilled to one line ("they undercut on seats, charge on usage"), and three months later it is sitting right there when she rewrites her own pricing page.

Takeaway: before you choose a tool (Obsidian, Notion, Logseq, Tana, all covered later) decide what you want your second brain to produce. Design backwards from the output. A system built to be used looks very different from one built to feel organised, and only one of them is worth the upkeep.

2. The personal knowledge OS

Most of us do not have a knowledge problem. We have a fragmentation problem. The idea lives in a note, the link in a browser tab, the to-do in a different app, the meeting summary in a fourth, and the thing you read last Tuesday is gone entirely. Five apps, five silos, zero connections. A personal knowledge OS flips that: notes, tasks, references, bookmarks and daily logs live in one connected system that you actually run your thinking on, the way an operating system runs your machine.

The word "OS" is doing real work here. An OS is not where you store files, it is the layer you operate through. Everything you capture lands in the same place, gets linked to everything else, and stays queryable later, by you and increasingly by an LLM. The payoff is not tidiness. It is that your past thinking compounds instead of evaporating.

One system with links beats many silos

Silos lose the relationships, and the relationships are the value. A bookmark about pricing, a note from a customer call, and a half-formed strategy memo are only useful together. When they sit in three apps, nobody ever assembles them. When they sit in one linked system, a single backlink ties them, and a query like "everything connected to [[pricing]]" surfaces the lot in one view.

Links also make AI dramatically more useful. An LLM answering over a connected vault can follow your [[backlinks]] and tags as structure, not just match keywords across loose documents. Garbage in, garbage out applies to your second brain too: a connected graph is the cleanest possible input.

You have real options for the substrate. Obsidian is local-first Markdown with a deep plugin ecosystem and a graph view. Logseq is a block-based outliner, also local-first, where every bullet is linkable and queryable. Tana leans AI-native: its "supertags" turn any bullet into a structured database row, so a node tagged #meeting gains fields you can query like a table, and as of early 2026 it routes to several models including Claude. Notion trades local control for collaboration and databases. Pick one and commit. The worst knowledge OS is the one split across two tools you keep migrating between.

A workflow you can actually keep

The system only works if capture is frictionless and processing is deferred. Three loops:

• Capture fast, all day. One inbox, one hotkey. A thought, a link, a quote goes in raw in under five seconds. No filing, no deciding. Friction at capture is where second brains die.
• Process later, in batches. Once a day, walk the inbox. For each item: delete it, link it into an existing note, or promote it to its own note. This is where raw capture becomes connected knowledge.
• Review weekly. A 30-minute pass over open tasks, recent notes and the week's daily logs. What did I learn, what is still open, what gets dropped. The review is what turns a note pile into a thinking system.

A founder's knowledge-OS loop

Concretely. Enrico runs a customer call for EquityFlow. During it he dumps rough bullets into today's daily note and tags the company [[Acme Capital]]. He drops a competitor's pricing page into the same inbox. That evening, processing, he moves the pricing link under a permanent [[pricing]] note, turns one bullet ("they want CSV export") into a task linked to [[roadmap]], and leaves the call note backlinked to [[Acme Capital]].

Three weeks on, prepping a board update, he opens [[pricing]] and every linked call, memo and bookmark is right there as backlinks. He asks his AI layer, "summarize what customers said about pricing this quarter," and because the notes are connected and tagged, it answers from his evidence, not a generic guess. The call he would have forgotten is now load-bearing.

Takeaway: Start with one tool, one capture inbox, and the capture-process-review loop. Do not architect the perfect graph on day one. The links accumulate on their own, and that accumulation is the entire point.

3. The tools, compared

There is no best tool, only the best fit for your brain and your data. The honest split is between tools that store your notes as plain files you own (Obsidian, Logseq) and tools that store them in a structured database you query (Notion, Tana, Capacities). The first group survives the company going away. The second group does things plain text simply cannot. Below is the field as it stands in mid-2026, one tool at a time. The takeaway at the end matters more than any single row.

The contenders

A concrete example

Say you keep notes on every founder you meet. In Obsidian that is a folder of Markdown files and a Bases view; you own it forever but you built it. In Tana you tag each note #founder and a structured roster appears for free, fields and all. In Mem you just type and trust the AI to connect the dots later. Same goal, three philosophies: own it, structure it, or delegate it.

Takeaway: decide the non-negotiable first. If it is data ownership, start with Obsidian, Logseq or Anytype. If it is structure and collaboration, Notion or Tana. If it is least friction, Mem or Capacities. Pick the constraint, and the tool picks itself. The next chapter is about making whichever you choose answer questions, not just store them.

4. Local-first and owning your knowledge

Every note you write lands in one of two places: a folder on a disk you control, or a database on a server someone else controls. The distinction sounds abstract until you try to leave. A second brain is meant to compound over decades, so the most important question about any tool is not "what can it do today" but "will I still be able to read this in twenty years, with no account, no subscription and no working internet connection".

Files you own versus a database you rent

Local-first tools store your knowledge as plain text on your machine. Obsidian keeps each note as a Markdown file inside a vault, which is just a folder on your filesystem. There is no account system, nothing is uploaded unless you opt into sync, and Obsidian itself collects no notes. You can open any file in TextEdit, vim, VS Code or cat on the command line, with or without Obsidian installed. The app is a lens over your files, not a cage around them.

Notion sits at the other end. Your pages live in Notion's database in the cloud. That powers genuinely useful things: real-time collaboration, relational tables, permissions, sharing a doc with a link in seconds. But you are renting that structure. The pages are not files on your disk; they are rows that only Notion fully understands.

The honest trade-off is this: cloud databases buy you collaboration and convenience, local files buy you ownership, portability, privacy and longevity. Most teams need some of both. The principle that keeps you safe is to keep the core of your knowledge in an open, portable format, and treat anything proprietary as a convenience layer you can afford to lose.

A concrete example: try to leave

Run the migration test before you commit, not after. Export a real Notion workspace and watch what survives. Rich pages come out as Markdown, but databases export as CSV, which keeps the rows and drops the views, filters, relations, rollups and formulas that made the database worth building. Images are stored on Notion's CDN, so they download into nested subfolders with relative links that break the moment you reorganise, and some temporary image URLs simply expire. The export is lossy by design, because the source format is richer than Markdown and no patch will change that.

Now do the same with an Obsidian vault. There is nothing to export, because the Markdown files already are the data. Copy the folder to a USB stick, a Git repo or another machine and you have everything: notes, links, folder structure, all readable as plain text. That asymmetry is the whole argument. Lock-in is not a clause in a contract, it is the gap between how easily data goes in and how cleanly it comes back out.

"Local-first" is a spectrum, so check the format

Logseq is a useful caution here. Its classic version stores plain Markdown or Org-mode files locally, fully in the open-format camp. But the DB version rolling out through 2025 and 2026 moves storage to a SQLite schema for speed and richer queries, and that schema is not interoperable with the plain-text graph. SQLite on your own disk is still local and far better than a remote silo, yet it is a proprietary structure, not files you can read in any editor. The lesson is not "Logseq is bad", it is that "local-first" and "plain text" are different promises. Read which one a tool actually makes.

Your second brain should outlive any single app. Apps come and go; a folder of Markdown does not.

Takeaway: keep the durable core of your knowledge as plain Markdown in a folder you control, version it with Git or a normal backup, and let proprietary tools (Notion for collaboration, a SQLite-backed app for fast queries) sit on top as removable layers. Before you adopt anything, export your data once and see what breaks. If leaving is clean, staying is safe.

5. Links and the knowledge graph

Folders are where notes go to die. You file something under "Marketing" or "Q3 ideas", feel organised for a moment, and never open it again. The problem is not laziness, it is that a folder forces one note to live in exactly one place, while a real idea belongs in five. The fix is the single most important mechanic in modern note tools: the link. Instead of sorting notes into a tree, you connect them into a web, and you navigate the way your memory actually works, by association.

Wiki-links, backlinks, and why both directions matter

A wiki-link is just a note name in double brackets: [[Customer interviews]]. Type it inside any note and you create a clickable connection to that page (in Obsidian, Logseq, Tana and most of this family, the target does not even need to exist yet, the link creates it on click). That is the easy half.

The half that changes everything is the backlink. Because the link is bidirectional, the moment you write [[Customer interviews]] in note A, note B ("Customer interviews") automatically grows a list saying "note A links here". You never have to maintain it. Open any note and you see, at the bottom, every other note that ever pointed at it, what Obsidian splits into linked mentions (explicit [[brackets]]) and unlinked mentions (any note that merely typed the phrase). The note you are reading tells you, unprompted, about every context it has ever appeared in.

The graph view, and why connection beats hierarchy

Zoom out and all those links render as a graph: notes are dots, links are lines, and clusters appear where your thinking is dense. The global graph is mostly a pretty picture, but the local graph, the neighbourhood around one note, is genuinely useful: it shows you what a given idea sits next to. A hierarchy can only answer "what is this filed under". A graph answers the far better question: "what is this related to, and what did I once connect it to that I have since forgotten".

That is the whole pitch. Hierarchy is retrieval by location, which means you have to remember where you put something. A graph is retrieval by association, which is how human memory works. You do not recall your dentist's name by traversing a folder called "People > Healthcare", you recall it because you were thinking about the appointment you are dreading.

A link surfacing a forgotten idea

Concrete example. In March you jot a throwaway line in a meeting note: "churn spikes after the third failed payment, look into dunning". You link [[Payment retries]] and move on. Three months later you open [[Payment retries]] for an unrelated reason, and its backlinks panel shows that March meeting note sitting right there. The forgotten idea resurfaces exactly when it is relevant, with zero search, zero memory, zero filing. The link did the remembering for you. Takeaway: link generously in the moment, even when it feels pointless. You are not organising for today, you are leaving trails for a future self who will arrive by a door you cannot predict.

EquityFlow is a knowledge graph too

This is not only a note-taking trick, it is how we built the data behind EquityFlow. Under the hood it is a relationship graph: every entity, a founder, a fund, a company, a round, links to the others it touches. So a founder page is not a dead-end profile, it carries backlinks to the companies they started, the investors they raised from, the other founders they co-invested alongside. You explore by following relationships, the same associative move as clicking a backlink in your own vault, just at the scale of a market. And it is the same structure an LLM loves: a graph of explicit relationships is far easier to query truthfully than a pile of folders, which is exactly why the next chapters point your second brain at one.

6. From notes to a queryable LLM wiki

For decades the deal with notes was simple: you wrote things down, and later you went looking for them. Search was keyword search. If you wrote "position sizing" but searched "how big should my bets be", you found nothing, even though the answer was sitting right there in your vault. An LLM wiki changes the deal. It is your knowledge made answerable in natural language by an AI, instead of only findable by exact words. You stop hunting through files and start asking questions.

The shift is from storing to interrogating. Your second brain stops being an archive you dig through and becomes something you talk to.

How it actually works (the short version)

The mechanics behind this are usually retrieval-augmented generation, or RAG. It sounds like jargon, but the idea is plain. Three steps:

1. Chunk and embed. Every note is split into small passages, and each passage is turned into an embedding: a list of numbers that captures its meaning. Notes about "bet sizing", "position sizing" and "how much to risk per trade" land close together in this number-space, even with no shared words. That closeness is what makes semantic search work.
2. Retrieve. When you ask a question, the system embeds your question too, then pulls the handful of passages nearest to it.
3. Generate. Those passages are handed to the language model as context, and it writes an answer grounded in your own notes, ideally with citations pointing back to the source files.

The grounding is the whole point. A raw model answers from its training. A RAG-backed wiki answers from your material, and shows its work.

What you can run today

You do not have to build this. As of mid-2026 several tools ship it. Reor is a local-first knowledge app that chunks and embeds every note into an internal vector store and does Q&A over the corpus, with models running on your own machine for privacy. For Obsidian, community plugins such as Smart Connections add local embeddings and semantic search over your vault, and others expose the index to AI clients. Google's NotebookLM takes the cloud route: you upload sources and it answers questions grounded strictly in those documents, with inline citations you can click to verify. Different trade-offs (local and private versus hosted and polished), same underlying pattern.

A concrete example

Say your vault holds two years of investing notes. You ask:

"What did I conclude about position sizing for early-stage bets?"

Keyword search would need you to remember your own phrasing. The LLM wiki retrieves the relevant passages and answers something like:

Across your notes you settled on capping any single early-stage position at 2 to 3 percent of the portfolio, after the March 2025 write-up where a concentrated bet went to zero. You also noted that conviction should change holding period, not initial size.

Sources: 2025-03-18 post-mortem.md, investing/sizing-rules.md.

That is the difference: not a list of files to read, but a synthesized answer drawn from across them, with receipts.

Be honest about the limits

This is not magic, and treating it as an oracle will burn you. The model can still be wrong. It can retrieve the right passages and then misread them, or confidently fill a gap your notes never covered. It only knows what you wrote, so a wrong conclusion in your vault becomes a wrong answer with a citation attached.

This is exactly why grounding and citations are non-negotiable. A wiki that answers without pointing to sources is a wiki you cannot trust. One that cites 2025-03-18 post-mortem.md lets you click through and check in seconds.

Takeaway: treat the LLM wiki as a fast, fallible research assistant, never a final authority. Demand citations, click at least one, and remember the answer is only as good as the notes underneath it. Garbage in, confidently-cited garbage out.

7. The tools that put an AI over your notes

You have a vault full of notes. The promise of a second brain is that you can now ask it things, in plain language, and get answers grounded in what you wrote rather than what the model invented. As of mid-2026, the tools that deliver this fall into four rough camps: plugins bolted onto an existing app, AI-native apps built around it, dedicated local apps, and coding agents pointed at your raw files. Each makes a different trade between convenience and privacy.

Plugins for an app you already use

If you live in Obsidian, two plugins dominate. Smart Connections runs a local embedding model to surface notes semantically related to whatever you are writing, even when they share no keywords. Writing about "remote team comms" can pull up a forgotten note on "async video updates". By default it stays on your machine and needs no API key, though it moved to a paid tier in 2025. Copilot for Obsidian is the chat-and-rewrite layer: vault-wide Q&A, custom prompts, inline edits. The catch is that its RAG chat typically sends the relevant chunks of your vault to a cloud model (OpenAI, Anthropic, or whatever you wire up), so your notes leave the building unless you point it at a local model.

AI-native apps

Mem and Tana bake the AI in from the start. Mem auto-links notes via embeddings, drops folders entirely, and leans on a "talk to your notes" chat for recall and drafting. Tana takes the opposite route: its supertags turn any bullet into a structured, queryable record (#person, #meeting, #project), and the AI commands operate on that structure natively. Tana is more powerful and has a famously steep learning curve, expect a couple of weeks before it clicks. Both are cloud-first, so the privacy trade is real: your knowledge lives on their servers, and as of early 2026 Tana's offline support is weak.

Dedicated local apps

Reor is the purist's pick. It is a free, open-source (AGPL) desktop app that chunks and embeds every note into a local vector store, auto-links related ideas, does semantic search, and runs RAG-powered Q&A against local models through Ollama. Nothing leaves your machine. The cost is doing the work yourself: weaker models than the frontier cloud, and a smaller ecosystem.

On the other end sits Google NotebookLM, which is cloud through and through but excellent at one job: chat grounded strictly in the sources you upload, with citations back to the exact passage. By mid-2026 it defaults to Gemini 3.5, can suggest new sources to build out a knowledge base, and shows its reasoning steps. It is not your live vault, it is a project workspace you feed, but for "interrogate these 40 documents" it is hard to beat. Everything you upload is, of course, on Google's servers.

Point a coding agent at your raw files

The builder's move: your vault is just a folder of markdown, so let a coding agent read and edit it. Cursor or Claude Code opened on your vault directory can grep, summarize, refactor, and write notes directly. Cleaner still, run an MCP server over the vault so the agent gets safe, structured access. Options like obsidian-mcp-server can surgically edit a note by heading without clobbering the rest, traverse your wikilink graph, and find orphan notes. Lightweight servers such as mcpvault read the raw .md files directly with BM25 search and need no plugins or running app. Privacy here tracks the model behind the agent: a cloud model still sees the chunks it reads.

Practical takeaway

Pick by your single hardest constraint. If notes must never leave your machine, start with Reor or Smart Connections plus a local model. If you want the strongest grounded chat and the data is not sensitive, NotebookLM wins. If you already build with an agent, an MCP server over your existing vault gives you the most power for the least lock-in, no new app, just AI over the files you already own. Resist running all of them at once. One tool you actually query beats five you configured and abandoned.

8. Build your own LLM wiki

By now you have a pile of notes. The last step is making them answer questions. An LLM wiki is just a knowledge base where you ask in plain language and get back a grounded answer with links to the exact notes it came from. The recipe has four moving parts, and you can assemble them in an afternoon or in a weekend, depending on how much you want to own.

The four parts

Almost every system, from a toy script to what EquityFlow runs in production, is the same loop:

1. Source of truth. A folder of plain markdown notes. Plain text outlives every app, diffs cleanly in git, and stays yours.
2. An embedding model. It turns each note (or chunk of a note) into a vector so that semantically similar text lands near each other, even when the words differ.
3. A vector store. Where those vectors live so you can ask "what is closest to this question" in milliseconds. Local options like Chroma or LanceDB are plenty for a personal vault.
4. An LLM that answers from retrieval. You take the question, fetch the top few matching notes, and hand them to the model with one instruction: answer only from these, and cite the source. This is retrieval-augmented generation (RAG), and the citation is the whole point. An answer you cannot trace back to a note is a guess.

The easy path

You almost certainly should not write code first. As of mid-2026 the off-the-shelf options are genuinely good. NotebookLM will ingest a set of documents and answer with inline citations, no setup. Inside Obsidian, community plugins like Smart Connections or "Analogy" run local embeddings over your vault and expose semantic search and chat without you touching a vector database. Try one of these for a week. If it answers your real questions and links back to the right notes, you are done, and you have lost nothing but an evening.

The build-it path

You build when you want control: custom chunking, your own model, private data that cannot leave the machine, or behaviour the plugins will not give you. Two honest shapes:

• A small RAG script. Walk the folder, chunk and embed each note, store the vectors, and write a query function that retrieves and prompts the model. The grounding prompt is the load-bearing line: Answer using only the notes below. Cite each note by filename. If they do not contain the answer, say so. That last clause is what keeps it from inventing things.
• An MCP server over your vault. Instead of a one-shot retriever, you expose your notes through the Model Context Protocol so an agent like Claude Code can read and write them directly. Now the assistant searches your vault, edits a note in place, and links new notes to old ones, as part of its normal work. Several open-source Obsidian MCP servers already do read, write, and search; pointing one at your vault is a config file, not a codebase.

Be honest about effort. The script is an afternoon to a working demo and a week to something you trust. The hard part is never the embeddings; it is chunking, keeping the index fresh as notes change, and making citations land on the right paragraph.

The team version

Scale the same loop to a company and the source of truth stops being one person's folder and becomes a shared, structured knowledge graph: an interrogable brain the whole team queries. Then "who knew that the X deal stalled, and why" gets answered from the graph, with provenance, instead of from whoever happens to be online.

This is exactly what we built at EquityFlow over the private-market graph: entities, relationships and notes that an LLM reads to answer questions a search box never could, with links back to the underlying records. We wrote up how, end to end, in our deep dives.

Worked example: see how EquityFlow turned its private-market graph into a queryable brain, at equityflow.finance/deep-dives.

Takeaway: start on the easy path, prove the loop answers your real questions, and only graduate to a script or an MCP server when a concrete limitation pushes you there. The markdown folder is the asset. Everything else is replaceable plumbing around it.

9. Pitfalls, and a starter setup

Most second brains die quietly. Not from a missing feature, but from a handful of predictable mistakes. Here are the four that kill the most systems, and then a starter ladder that sidesteps all of them.

The traps

The collector's fallacy. Saving an article is not the same as reading it, and reading it is not the same as understanding it. A vault of 4,000 untouched web clips feels like progress and is actually a debt. The dopamine of capture masquerades as learning. The fix is brutal and simple: if you save something, you owe it one sentence in your own words. A note you cannot summarize in your own language is a note you have not learned.

Tool-hopping. The perfect app does not exist. Obsidian, Notion, Logseq, Tana: each is excellent and each is missing the one thing you currently fixate on. Every migration resets your muscle memory, breaks your links, and buys you a week of setup euphoria instead of thinking. The compounding lives in the notes and the habit, not the software. Switching tools resets the compounding to zero.

Over-structuring. Elaborate tag taxonomies, nested folder trees, color-coded databases with twelve properties: these are systems you maintain instead of use. The more scaffolding a note needs before it can exist, the fewer notes you will write. Structure should emerge from your notes, not precede them. If you spend more time on the meta-system than on the content, the system has become the hobby.

Capture without review. A second brain that you only write to is a landfill. Without a recurring moment where you revisit, connect and prune, notes pile up unread and the whole thing becomes write-only. Review is where capture turns into knowledge.

A starter ladder

Do these in order. Do not skip ahead, and do not add the next rung until the current one is a habit.

1. Pick ONE tool and commit for a quarter. Obsidian if you value local Markdown files you own forever, Notion if you prefer databases and live in a browser. Either is correct. The choice matters far less than the commitment.
2. Capture for two weeks, no organizing. One note per idea, meeting, article or half-formed thought. No folders, no tags, no template. Just get the habit of externalizing what is in your head. Resist every urge to tidy.
3. Add links between related notes. Now go back and connect. When a note relates to another, link them ([[wikilinks]] in Obsidian, mentions in Notion). Links, not folders, are what make a vault navigable and what an AI later traverses for context.
4. Run a weekly review. Thirty minutes, same slot every week. Reread what you captured, summarize the loose ones in a sentence, link what connects, delete what was noise. This single habit separates a living second brain from a dead archive.
5. Only then add an AI layer. Once you have a few hundred linked, reviewed notes, point an LLM at them. In Obsidian, the community Copilot plugin chats with your vault using your own API key (nothing leaves for third-party servers). In Notion, built-in Q&A answers questions across your workspace. Or drop a project folder into NotebookLM for grounded, cited answers. AI on top of thin notes returns thin answers, so this rung comes last.

A concrete example. Say you read three pieces on pricing this month. Rung 2: three rough notes. Rung 3: you link them to an existing SaaS pricing note. Rung 4: in your review you write one line distilling the through-line. Rung 5, eight months later, you ask your assistant "what have I concluded about usage-based pricing?" and it answers from your own past thinking, with citations back to those notes.

The payoff

That last moment is the whole point. Without a system, the pricing insight you had in March is gone by November, reconstructed from scratch or lost. With a second brain plus an LLM wiki, it is still there, linked, reviewed, and instantly queryable in your own words. Your past thinking compounds instead of evaporates. That is the difference between learning things repeatedly and building on what you already know.