Every AI conversation you start is a blank slate. You explain your context, your project, your thinking — again. Then the chat ends and all of it evaporates. The “second brain” solves exactly that problem: it’s a persistent, structured collection of *your* thinking that an AI can read, search, and build on. Not the company’s knowledge base. Not a shared wiki. Your brain, externalized.
On a recent episode of our podcast, Dave Brear walked us through how he built his — and what surprised me most is that the story doesn’t start with AI at all. you can find the episode here: “Is Your AI Just ‘Slop’ – Or a Real Second Brain? and you can read the blogpost for a summary of the podcast: AI Second Brain: How We Use Zettelkasten, Obsidian and LLMs to Supercharge Knowledge Work
What is a second brain?
It starts with a wooden box in 1950s Germany
The intellectual foundation is the **Zettelkasten** (“slip box”), a method invented by German sociologist Niklas Luhmann. Luhmann wrote his ideas on index cards — one idea per card, in his own words. These are called **atomic notes**. The magic wasn’t the cards themselves but the *links between them*: this idea supports that one, this one contradicts that argument. Over decades, the box became a thinking partner that surfaced connections Luhmann himself had forgotten he’d made.
The modern recommendation for understanding this philosophy is the book **How to Take Smart Notes** by Sönke Ahrens. As Dave put it: yes, it could have been a blog post — but read it anyway.
Then AI changed the equation
A digital Zettelkasten (Dave uses **Obsidian**) stores everything as plain markdown files, linked with wiki-links, sitting in a local folder you control. Here’s the happy accident: **markdown is the native language of large language models.** Dave never designed his vault for AI ingestion — but when agentic tools matured enough to work directly with file systems, he pointed Claude at his vault and, in his words, suddenly every conversation started with all the context of everything they’d ever discussed.
The crucial mindset: expansion, not compression
This is the part most people get wrong. The AI hype machine sells *compression*: summarize this document, shorten this email. A second brain is the opposite — **expansion**. Dave’s best example: a politically sensitive customer email. He fed in over a thousand words of context (stakeholders, politics, motivations, desired outcome) to produce a 300-word email. The AI didn’t think *for* him; it challenged his assumptions, stress-tested his framing, and acted as a sparring partner. The ideas were all his. The AI helped him walk the tightrope.
That’s what a second brain really is: **a thinking system, not a note-taking system.** And one rule remains absolute: human in the loop. Dave is blunt that a significant percentage of first answers from his vault are nonsense. Catching that, correcting it, and arguing back is not a bug — it’s the exercise that sharpens your own thinking.
Part 2: How it works under the hood
A working second brain has roughly four layers:
**1. The vault.** A folder of markdown files. One idea per note, written in your own words, linked together with `[[wiki-links]]`. Tools: Obsidian (most popular), Logseq, or honestly just a folder — Notepad on Windows can save `.md` files directly.
**2. Metadata.** Each note carries YAML frontmatter: type (idea, draft, finished article), status, tags, dates. This is what makes the vault *machine-navigable* instead of a pile of text.
**3. Retrieval tooling.** Here’s the problem Dave hit immediately: ask an AI “find all the ideas in my vault” and it has to open and ingest *every single file* just to read the headers. He compared it to a snake that swallowed a goat — too much context, expensive, and degrading. Even million-token context windows don’t give you perfect recall at that scale. The fix is targeted retrieval:
– A **metadata index**: a small service that pre-indexes all frontmatter, so the AI queries the index instead of opening files
– **Link traversal**: start from one note and follow the chain of wiki-links — load a *chain of thought*, not a haystack
– **Semantic search**: find conceptually related notes, including ones you wrote months ago and forgot
Dave hadn’t written code in 20 years. He didn’t need to — he described what he wanted and let the AI build the tools. He calls it becoming a product manager of his own cognition.
**4. The agent.** An AI (Dave’s is a Claude Max subscription he’s nicknamed “Max”) connected to the vault, with standing instructions: *this is our shared space, you can read it and write to it, save what you learn about me, document roadblocks we solve.* Fair warning on cost: working this way reportedly uses roughly 10x the tokens of casual chatting. Dave blew past the €20/month tier quickly — and considers it the best money he spends.
Part 3: Setting it up
Dave’s advice is deliberately anti-prescriptive: don’t download someone’s ten-tool template. Every system that didn’t match how his brain naturally works got abandoned within months. So:
**Step 1 — Start with a blank slate.** Create a folder. If you have existing notes to seed it with, great; if not, also fine.
**Step 2 — Pick your editor.** Obsidian is the obvious choice: free, local-first, markdown, wiki-links, YAML support. But the storage is just files — the editor is replaceable.
**Step 3 — Point an AI at it and set ground rules.** Tell it explicitly:
> “This is our shared space. I can write to it; you should feel free to write to it as well. Every time you learn something about me or how I work, save it to a notes area you can read. When we solve a roadblock, document it.”
**Step 4 — Let it interview you.** Ask the AI to interview you: who you are, what you do, how you want to work together. Budget about an hour of back-and-forth. This becomes your foundational context.
**Step 5 — Do real work in it.** This is the step people skip. The value of a Zettelkasten is not the information it contains — it’s that you *think inside it*. Bring real problems. Develop real deliverables in the vault, not next to it. It compounds: the more you put in, the better it gets, and the gaps you discover (need better search? missing an index?) tell you what to build next.
**Step 6 — Keep it firewalled.** Dave puts enormous value on what he calls the sanctity of the vault: he always knows which words are his and which were AI-paraphrased, and he deliberately keeps company data *out*. More on why below.
Want a playground first? Dave published a public subset of his vault at **davebrear.ai** — you can query it via MCP or fork it from GitHub and point your own agent at it.
Part 4: Connecting Claude to your vault — step by step
The connection mechanism is **MCP (Model Context Protocol)** — the open standard that lets AI assistants talk to external tools and data. There are two main routes: Claude Desktop (chat-style, easiest) and Claude Code (agentic, most powerful — closest to Dave’s setup).
Route A: Claude Desktop + the filesystem MCP server
**What you need:** Claude Desktop installed, Node.js installed (the filesystem server runs via `npx`), and a vault folder.
**Step 1 — Open the config file.** In Claude Desktop, go to **Settings → Developer → Edit Config**. This opens (or creates) `claude_desktop_config.json`:
– Windows: `%APPDATA%\Claude\claude_desktop_config.json`
– macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
**Step 2 — Add the filesystem server, scoped to your vault only.** Paste this, replacing the path with your actual vault location (Windows paths need double backslashes):
“`json
{
“mcpServers”: {
“second-brain”: {
“command”: “npx”,
“args”: [
“-y”,
“@modelcontextprotocol/server-filesystem”,
“C:\\Users\\gerjon\\SecondBrain”
]
}
}
}
“`
Least privilege applies to AI agents too: point it at the vault folder, not your whole user profile.
**Step 3 — Restart Claude Desktop.** Fully quit the app, not just the window — the config only loads on startup. After restarting you’ll see a tools indicator in the chat input; click it to confirm the filesystem tools (read, write, search, list) are loaded.
**Step 4 — Test it.** Ask: *”List the files in my vault and summarize what you find.”* Claude will ask your approval before each file operation — every read and write requires an explicit yes, which keeps you in control.
**Step 5 — Set the ground rules.** Create a note in the vault root (e.g. `00-system/ground-rules.md`) containing your working agreement: this is our shared space, save what you learn about me to `/about-me`, document solved roadblocks in `/skills`, atomic notes only, always link. Start each session by telling Claude to read it first. (On claude.ai you can also put these instructions in a Project so they load automatically.)
**Step 6 — Run the interview.** *”Read the ground rules, then interview me: who I am, what I do, how I want to work with you. Save what you learn as linked atomic notes.”* Budget an hour. This is your foundation layer.
**Troubleshooting:** if the server doesn’t appear, it’s almost always one of three things — JSON syntax (a stray comma), a relative instead of absolute path, or an incomplete restart. Logs live in `%APPDATA%\Claude\logs` (Windows) or `~/Library/Logs/Claude` (macOS).
*Alternative without JSON editing:* Claude Desktop also supports **Desktop Extensions** — packaged MCP servers (`.mcpb` files) that install with a click via Settings → Extensions. Good for community-built Obsidian servers; the JSON route remains the right choice for custom setups.
Route B: Claude Code in the vault (Dave’s way)
This is the agentic setup: Claude doesn’t just answer questions about your notes, it works *inside* the vault — reading, writing, linking, and building its own tooling.
**Step 1 — Install Claude Code** and open a terminal *in your vault folder*:
“`bash
cd ~/SecondBrain
claude
“`
**Step 2 — Create a `CLAUDE.md` in the vault root.** Claude Code automatically reads this file at the start of every session — it’s where your ground rules become permanent:
“`markdown
# Second Brain — Working Agreement
This vault is our shared thinking space. You may read and write freely.
## Conventions
– Atomic notes: one idea per file, in my words
– Every note gets YAML frontmatter: type, status, tags, created
– Always link new notes to related ones with [[wiki-links]]
– What you learn about me goes in /about-me
– Solved roadblocks get documented in /skills
## Behavior
– Challenge my assumptions; don’t just agree
– When my new thinking contradicts an old note, flag it
“`
**Step 3 — Run the interview** (same as Route A, but now the results persist as files and the instructions persist across every future session).
**Step 4 — Build your retrieval tooling.** This is where Dave’s “snake that swallowed a goat” problem gets solved. Once the vault grows past ~100 notes, ask Claude Code to build what Dave built:
1. A **metadata index**: a script that scans all YAML frontmatter into a single index file, so queries like “show me all open ideas” read one small file instead of ingesting the whole vault
2. A **link-traversal tool**: give it a starting note and it follows the wiki-link chain, loading a chain of thought instead of a haystack
3. Optionally, **semantic search** over the vault
Then describe these tools in `CLAUDE.md` so every future session knows they exist and uses them instead of brute-force reading. Dave hadn’t coded in 20 years — he described what he wanted and let the AI build it.
**Step 5 — Work real problems in it.** Prepare your next presentation, draft your next blog post, think through your next difficult stakeholder conversation — inside the vault, as linked notes. This is what makes it compound.
Route C: Query someone else’s brain
Dave and Brian Madden each expose a *public subset* of their vault as a remote MCP server — distinct brains that don’t merge but can talk to each other. On claude.ai, remote MCP servers are added as connectors under Settings (on managed enterprise plans, your admin controls which connectors are allowed — James hit exactly that wall). Try it with Dave’s public vault at **davebrear.ai**, or build your own read-only vault server as a weekend project — which conveniently also gives you the endpoint you’ll need for Part 5, Route 3.
## Part 5: Connecting Microsoft 365 Copilot to your vault — step by step
One honest disclaimer first: **M365 Copilot cannot read an arbitrary local folder.** Its world is the Microsoft Graph. So every route starts the same way — getting your markdown somewhere the Graph can see it — and then differs in how much agent you build on top.
### Route 1: The 15-minute version — OneDrive + Agent Builder
The lightweight, no-code route: a declarative agent grounded in your vault.
**Step 1 — Sync the vault to OneDrive.** Your vault is just a folder of markdown files; Obsidian doesn’t care where it lives. Move it into (or sync it to) a OneDrive folder, e.g. `OneDrive/SecondBrain`. If you’d rather not expose everything, sync a curated subset — remember Dave’s principle of the partitioned vault.
**Step 2 — Create a declarative agent.** In M365 Copilot, choose **New agent** (Agent Builder), then **Skip to configure**. Note: this requires an active M365 Copilot license.
**Step 3 — Add the vault as knowledge.** On the **Configure** tab, in the **Knowledge** section, use **Browse** to select your OneDrive vault folder (or paste a SharePoint/OneDrive link).
**Step 4 — Write the instructions.** This is where your ground rules go: *”You are my second brain assistant. The knowledge source contains my personal notes as atomic markdown files with YAML frontmatter. Always ground answers in my notes, cite which notes you used, and tell me when my notes contain nothing on the topic rather than inventing an answer.”*
**Step 5 — Test and create.** Ask it: *”What have I written about sovereign cloud?”* and verify it cites actual notes.
**What you get and don’t get:** retrieval and grounding inside the tool you already live in — but it’s read-only. No writing back, no linking, no tool-building. It’s a window into your brain, not a hand inside it.
### Route 2: The proper version — a Copilot Studio agent on SharePoint
More control, better retrieval configuration, shareable with colleagues — and the natural way to build Dave’s “enterprise layer.”
**Step 1 — Put the vault (or its curated subset) in a SharePoint document library.** A dedicated site like `https://yourtenant.sharepoint.com/sites/SecondBrain` keeps permissions clean.
**Step 2 — Create the agent** at copilotstudio.microsoft.com: **New agent**, give it a name, description, and instructions (same ground-rules pattern as above, but you have far more instruction room here — encode your note conventions, your frontmatter schema, and how you want it to behave as a sparring partner, not a yes-machine).
**Step 3 — Add SharePoint as a knowledge source.** Go to **Knowledge → Add knowledge → SharePoint** and paste the site URL. Write a *detailed description* of what this knowledge contains — the description steers the generative orchestrator’s decision about when to use it, so “Gerjon’s personal knowledge vault: atomic notes on AI strategy, security, governance, and market vision” beats “my notes.”
**Step 4 — Check authentication.** The default **Authenticate with Microsoft** setting means queries run on behalf of the signed-in user with their SharePoint permissions — so colleagues can only retrieve from notes they can already access. Your library permissions *are* your vault firewall: get them right before publishing.
**Step 5 — Test, then publish** to Teams and M365 Copilot. Now your second brain answers from the same window as your email — and if you publish a sanitized subset to the team, you’ve built exactly what Dave described: colleagues asking “what does the CTO think about X?” without ever touching your private thinking.
Route 3: The architect’s version — MCP into Copilot Studio
This is the pattern that makes your second brain assistant-agnostic: one vault, one protocol, served to both Claude *and* Copilot.
**Step 1 — Build (or reuse) a vault MCP server.** The same server from Part 4 Route C works, with two requirements: Copilot Studio only supports the **streamable HTTP** transport (SSE is deprecated and no longer supported), and it must be reachable as a hosted endpoint — Azure Container Apps is a natural home. Keep it read-only to start.
**Step 2 — Connect it via the onboarding wizard.** In your Copilot Studio agent, go to **Tools → Add a tool → Model Context Protocol**, and either pick an existing MCP connector or register your server with its endpoint URL.
**Step 3 — Configure authentication.** The wizard supports OAuth 2.0, including **dynamic discovery** (Dynamic Client Registration) if your server supports it — the cleanest option. Entra ID-backed per-user auth means the vault server knows *who* is asking, which is what makes a multi-user “query the team’s brains” scenario governable.
**Step 4 — Add the server’s tools to the agent.** After connecting, choose **Add to agent** (or **Add and configure**); the server’s tools — your metadata index query, your link traversal, your semantic search — now appear on the agent’s Tools tab for the orchestrator to call.
**Step 5 — Test the difference.** Knowledge sources give you RAG: “find passages about X.” MCP tools give you *operations*: “traverse the link chain from my sovereign-cloud note and summarize the argument I’ve been building.” That’s the difference between searching a brain and thinking with one.
**The honest comparison:** today, Claude — especially Claude Code — is meaningfully better at the *agentic* second-brain workflow: reading, writing, linking, and building tooling inside your vault. Copilot is better at meeting you inside the enterprise walled garden, with identity, permissions, and governance already handled. They’re not competing patterns; they’re the personal layer and the corporate layer of the same idea — and Route 3 is the bridge between them.
Part 6: The uncomfortable governance questions
Three points from the episode that every IT leader should sit with:
**This is not a DLP problem — and that’s the problem.** Dave’s vault contains zero company files, zero customer data, no clipboard copies. Only his own observations. Yet ask it about “super secret initiative X” and it can synthesize something scarily close to reality. Traditional data loss prevention has nothing to detect, because nothing was ever copied.
**Shadow second brains are coming.** People who work this way don’t go back. If the enterprise doesn’t offer a sanctioned way to do this inside the walled garden, people will do it anyway — personal subscription, personal device, personal file share — and you will have no visibility whatsoever. Dave’s prediction: this goes from a niche practice to a significant factor fast. The only winning move is to provide the capability *inside* governance, not to ban it.
**Who owns your cognition?** James raised the sharpest question: if your employer hosts a system that captures how you think, what stops them from keeping 80% of your value at 0% of your salary after you leave? Dave’s tentative answer — a personal encryption layer over the “this is me” tier of context, useless without you in the loop — doesn’t exist as a product today. But he sketched a layered model worth remembering: company context at the base, role context above it, and *you* at the top. The top layer should be portable and yours.
Where to start, in one paragraph
Create a folder. Open it in Obsidian. Point Claude (Desktop or Code) at it, set the ground rules, and let it interview you for an hour. Then bring it one real problem this week and work the problem *inside* the vault. Read *How to Take Smart Notes* when you want the philosophy. And if you want to try before you build: Dave’s public vault is at davebrear.ai.
The tech, as always, is the easy part. The discipline of thinking in atomic notes, in your own words, every day — that’s the system. The AI just makes it compound.