How to Build a Second Brain

Most entrepreneurs I know have the same problem.

You've read hundreds of books. Listened to thousands of hours of podcasts. Taken notes from a thousand meetings. Had late-night voice memos that felt like breakthroughs. Screenshots of tweets you wanted to remember. Client calls that contained gold.

And where is all of it right now?

Scattered. Dead. Sitting in apps you forgot you subscribed to, in iMessage threads with yourself, in voice memos labeled "New Recording 247." The compounding machine inside your head exists, but the infrastructure around it is held together with duct tape and hope.

At the end of the day, the real asymmetry in business isn't information access. Everyone has the same internet. The asymmetry is whether your knowledge compounds or decays.

Mine used to decay. Now it compounds. I'm going to show you exactly how.

Why Every "AI + Documents" Setup You've Tried Is Broken

Most people's experience with AI and their own knowledge looks like this:

You upload files. The AI retrieves chunks. You ask a question. You get an answer. Move on.

That's how NotebookLM works. That's how ChatGPT file uploads work. That's how pretty much every RAG system out there works. And the fundamental problem with all of them is this: the AI is rediscovering your knowledge from scratch every single time you ask a question.

Nothing accumulates. Nothing compounds. You read 200 articles this year and your AI is no smarter about your world in December than it was in January. You're basically renting intelligence one question at a time.

At the end of the day, that's not a second brain. That's a search engine with a personality.

What I'm going to show you is different. Instead of retrieving from raw documents every time, the AI incrementally builds and maintains a persistent wiki that sits between you and your sources.

It's kind of like the difference between hiring a researcher who starts from zero every morning versus hiring a chief of staff who actually knows your business and gets smarter every week.

When you add a new source:

• The AI reads it
• Extracts what matters
• Updates the existing topic pages
• Rewrites the summaries
• Flags where this new information contradicts stuff you already had
• Strengthens the evolving synthesis

You never write the wiki yourself. The AI writes and maintains all of it. Your job is the sourcing, the exploration, and asking the right questions. The AI handles the summarizing, cross-referencing, filing, and the bookkeeping. Which, let's be honest, is the part nobody ever actually does. That's why most people's "knowledge bases" die within 3 weeks.

This one doesn't die. It compounds.

What You Actually Need (Don't Overthink This)

Two tools. That's it.

Obsidian: download from obsidian.md. It's free. It's a markdown editor with graph views and link navigation. Think of it as the window you look at your wiki through.

Claude Code: download from claude.com/product/claude-code. This is the agent that reads your files, builds the wiki, and maintains the whole thing.

That's the entire stack. Anyone telling you that you need Notion AI + Mem + Reflect + Heptabase + a custom vector database is selling you something. You need two tools and a good schema. Everything else is cope.

Step 1: Create Your Vault

Open Obsidian. Create a new vault. Name it whatever makes sense to you: brain, vault, your name, doesn't matter.

Inside the vault, create exactly these two folders:

raw-sources/ this is your junk drawer. Articles, meeting transcripts, book highlights, podcast notes, screenshots, voice memo transcriptions, client call transcripts, random ideas at 2 AM. Dump everything here. Do NOT organize it. That's not your job.

These files are immutable. The AI reads from them but never edits them. This is your source of truth, the raw signal.

wiki/ this is where the AI writes the organized version. Summaries, concept pages, entity pages, comparisons, overviews, syntheses. The AI owns this folder completely. It creates pages, updates them when new sources arrive, maintains cross-references, keeps everything consistent.

You read it. The AI writes it. You never edit wiki pages by hand. This is the rule that makes the whole system work. The moment you start manually editing wiki pages, you've broken the contract and the AI can't trust its own work anymore.

Inside wiki/ there are two special files the AI maintains:

• index.md a catalog of every page in the wiki, each with a one-line description, organized by category. The AI updates this on every ingest. When you ask a question, the AI reads the index first to figure out which pages are relevant, then drills in. This is why you don't need embeddings or a vector database. The index IS the retrieval system. And it works surprisingly well even when you hit hundreds of pages.
• log.md a chronological record of what happened. Every ingest, every query, every health check, appended in order. This is how the AI stays aware of what's been done recently and avoids repeating work.

Step 2: Add the Schema File (this is the most important step)

Create a file in the root of your vault called CLAUDE.md (if you're using Claude Code) or AGENTS.md (if you're using something else).

This is the schema. This is what turns Claude from a generic chatbot into a disciplined wiki maintainer that actually follows your rules.

You and the AI co-evolve this file over time. It starts with Andrej Karpathy's base prompt and over weeks of use, you refine it for your domain, your style, your standards. Think of it as the SOUL.md for your second brain.

Here's the base prompt to paste in. Copy both parts and combine them:

1ST PROMPT

# LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

## The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM **incrementally builds and maintains a persistent wiki** — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then *kept current*, not re-derived on every query.

This is the key difference: **the wiki is a persistent, compounding artifact.** The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

- **Personal**: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
- **Research**: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
- **Reading a book**: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like [Tolkien Gateway](<https://tolkiengateway.net/wiki/Main_Page>) — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
- **Business/team**: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
- **Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives** — anything where you're accumulating knowledge over time and want it organized rather than scattered.

## Architecture

There are three layers:

**Raw sources** — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

**The wiki** — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

**The schema** — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

## Operations

**Ingest.** You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

**Query.** You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: **good answers can be filed back into the wiki as new pages.** A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

**Lint.** Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

2ND PROMPT

## Indexing and logging

Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

**index.md** is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

**log.md** is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. `## [2026-04-02] ingest | Article Title`), the log becomes parseable with simple unix tools — `grep "^## \\[" log.md | tail -5` gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.

## Optional: CLI tools

At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. [qmd](<https://github.com/tobi/qmd>) is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

## Tips and tricks

- **Obsidian Web Clipper** is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
- **Download images locally.** In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. `raw/assets/`). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
- **Obsidian's graph view** is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
- **Marp** is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
- **Dataview** is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
- The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.

## Why this works

The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.

## Note

This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.

Step 3: Fill Your Raw Sources (stop stalling)

This is where 80% of people quit. They build the folders, they paste in the schema, and then they stare at an empty raw-sources/ directory like it's supposed to fill itself.

Don't do that. Dump everything you already have. Right now.

• Articles you saved in Pocket/Instapaper/Matter and never re-read
• Kindle highlights (export them, paste them in)
• Podcast notes from Snipd or wherever
• Meeting transcripts from the last 6 months
• Client call recordings — run them through Whisper first
• Project docs from Notion, Google Docs, whatever
• Voice memos you made in the car
• Screenshots of tweets you wanted to remember
• Research you did before big decisions that you'd never find again

Copy-paste into .md or .txt files. Do NOT rename anything. Do NOT clean it up. Do NOT organize it into subfolders. Just get it in there. The AI will handle the mess — that's literally the whole point.

No existing material? No problem. Open Claude, talk to it for 20 minutes about your work, your goals, what you're building, what you're figuring out, what you're stuck on. Save that conversation as Memory.md and drop it in raw-sources/.

That's enough to make your first session feel like Claude actually knows you. The vault doesn't need to be complete to be useful. It just needs to be real.

Step 4: Tell Claude to Build the Wiki

Open Claude Code. Point it at your vault folder. Run this:

claude -p "Read everything in /raw-sources/. Compile a wiki in /wiki/ following the rules in CLAUDE.md. Create an index.md first, then one .md file per major topic. Link related topics using [[topic-name]] format. Summarize every source. Log everything to log.md." --allowedTools Bash,Write,Read

Then walk away. Go eat. Go to the gym. Let it work.

When it's done, you come back to a wiki/ folder full of organized articles, connections you never would've seen yourself, summaries of sources you'd completely forgotten about, and an index that makes everything searchable in seconds.

The setup I personally use: Obsidian on one monitor, Claude Code on the other. The AI makes edits in real time, and I watch the wiki evolve. Following links. Checking graph view. Reading updated pages as they get rewritten.

Obsidian is the IDE. Claude is the programmer. The wiki is the codebase. That's the mental model.

Step 5: Use It Every Day (This Is Where It Compounds)

Here's where most tutorials stop. "Now you have a wiki! Great!"

But a wiki that sits there is useless. The magic is in the daily loop. There are three operations you run constantly, and each one makes the next one better.

Operation 1: Ingest New Sources

Install the Obsidian Web Clipper browser extension. One click and any article lands in raw-sources/ as clean markdown.

Then tell Claude:

claude -p "I just added an article to /raw-sources/. Read it, extract the key ideas, write a summary page to /wiki/, update index.md with a link and one-line description, and update any existing concept pages that this article connects to. Log what you changed to log.md. Show me every file you touched." --allowedTools Bash,Write,Read

Here's what you'll notice after a few weeks: one article can touch 10, 15, sometimes 20 wiki pages. Claude finds unexpected connections. It flags contradictions with things you added months ago. It logs exactly what changed so you can audit the thinking.

This is the "compounding" part. Each new source isn't just added — it's integrated.

Operation 2: Ask Your Wiki Questions

Once you've got 10+ sources in, start using the wiki as a thinking partner:

• "Based on everything in wiki/, what are the three biggest gaps in my understanding of [topic]?"
• "Compare what source A says about [concept] versus source B. Where do they actually disagree?"
• "Write me a 500-word briefing on [topic] using only what's in this knowledge base. Cite everything."
• "What have I been wrong about? Find claims in older pages that newer sources contradict."
• "What's a thesis I could defend that would be unique to my knowledge base and not obvious from any single source?"

That last one is the killer. That's where you stop using AI as a search engine and start using it as a synthesis partner.

Critical move: save good answers back into the wiki as new pages. A comparison you asked for. An analysis. A framework you discovered. These should NOT disappear into chat history. Every good question becomes a wiki page. Every wiki page makes the next question's answer better.

That's the compounding loop. That's the whole game.

Operation 3: Weekly Health Check

Once a week, run this:

claude -p "Read every file in /wiki/. Find: contradictions between pages, orphan pages with no inbound links, concepts mentioned repeatedly but with no dedicated page, and claims that seem outdated based on newer files in /raw-sources/. Write a health report to /wiki/lint-report.md with specific fixes." --allowedTools Bash,Write,Read

This is your quality control. Without it, errors compound the same way good knowledge compounds. If Claude writes something slightly wrong in week 2, and you reference that wrong thing in week 4, now you have two wrong pages reinforcing each other. By week 10 you have an entire branch of your wiki built on sand.

Weekly health checks catch this before it metastasizes. Non-negotiable.

Step 6: Automations (Where It Gets Stupid Good)

This is the part I wish someone had shown me earlier. Once you have the base system working, you can layer automations on top and the thing basically runs itself.

Morning Briefing

Set this up once and it runs every morning while you're still asleep:

claude -p "Write a Python script called morning_digest.py that: 1) reads Memory.md and surfaces any open actions due today 2) reads any new files added to /raw-sources/ in the last 24 hours 3) pulls any contradictions flagged in the last health check 4) prints a clean briefing to the terminal. Then schedule it as a cron job at 7:00am." --allowedTools Bash,Write

Every morning you open your laptop to: what needs your attention today, what new knowledge entered your world overnight, and what's unresolved. You set it up once. It never stops.

Process a Call Transcript

After every meeting or client call, I run this:

claude -p "Read the transcript in /raw-sources/call-today.md. Extract every decision made, every action item with owner and deadline, and a 3-bullet summary. Add actions to /wiki/action-tracker.md, log decisions to /wiki/decision-log.md, and create a topic page linking back to this transcript." --allowedTools Bash,Write,Read

Every decision filed. Every action tracked. Nothing lost to "wait, what did we decide on that call again?" ever again.

Weekly Synthesis Post

This one's for anyone who publish content:

claude -p "Read everything added to /raw-sources/ and /wiki/ in the last 7 days. Identify the three most interesting threads, contradictions, or realizations. Draft a 400-word essay synthesizing them in my voice — conversational, specific, no guru bullshit. Save to /drafts/weekly-synthesis-[date].md" --allowedTools Bash,Write,Read

Your content engine starts writing itself, sourced entirely from your own thinking. The reality is — most content creators are just recycling the same three ideas. This makes you recycle YOUR ideas, which are more interesting, and the wiki gives you infinite depth to pull from.

Contradiction Tracker

This one changed how I think about my own biases:

claude -p "Read every wiki page. Find claims or beliefs I've held consistently across multiple sources. Then find any sources — even ones I dismissed — that challenge those beliefs. Write a steelman of the opposing view to /wiki/my-blindspots.md. Be ruthless. I want to know where I'm wrong." --allowedTools Bash,Write,Read

Most people use AI to reinforce what they already think. This does the opposite. The AI becomes your most honest advisor — because it's read everything you've read, and it has no ego.

What You Can Actually Build With This

Don't limit yourself to "personal knowledge base." This pattern works for anything where information accumulates over time and needs to stay organized:

Personal operating system — goals, health, decisions, lessons, journal entries. A structured, evolving picture of yourself that the AI maintains. By year two, you have something no one else in the world has: a fully synthesized view of your own life you can actually query.

Deep research on a single topic — going from zero to expert on something over weeks or months. Papers, articles, expert interviews, reports — all integrated. By the time you're ready to have an opinion, the wiki IS your opinion, backed by every source you've processed.

Book companion wiki — file each chapter as you read. Characters, themes, arguments, how they connect. By the end you have a rich companion that makes re-reading unnecessary. I've done this with Poor Charlie's Almanack and it completely changed how I engage with dense books.

Business/company wiki — fed by Slack threads, meeting transcripts, project docs, customer calls. The wiki stays current because the AI does the maintenance. Nobody on your team wants to update Confluence. Nobody has to anymore.

Competitive intelligence vault — track competitor pricing, features, hiring, positioning, product launches. Every new data point gets integrated into the existing picture. You go from "I should keep an eye on them" to having a living, breathing map of your market.

Client knowledge vault — everything you know about each client: their org chart, preferences, past conversations, stated priorities, unstated priorities, deals in progress. Updated automatically as new calls and emails get processed.

Investment thesis tracker — each position with its thesis, the evidence supporting it, the evidence against it. Updates as new information comes in. Forces you to actually revise your thesis instead of just holding your bags.

Course / skill acquisition wiki — as you learn something new, the wiki builds alongside you. Cross-references concepts across different teachers, different frameworks, different mediums. You stop "learning" and start building actual mastery infrastructure.

Dating / relationship journal (I'm not joking) — entries after meaningful conversations, patterns you notice, things you're working on. The AI flags patterns you can't see yourself. Uncomfortable but useful.

Pro Tips That Will Save You Months

Install Obsidian Web Clipper (browser extension). One-click article → markdown → raw-sources/. This is the single highest-leverage integration. Without this, you'll stop adding sources within two weeks.

Use the graph view in Obsidian. It's the best way to see the shape of your knowledge. Hubs, orphans, unexpected clusters, dead zones. The graph will tell you things about your own thinking that you can't see from inside the pages.

Install the Dataview plugin. If your CLAUDE.md tells the AI to add tags and dates to wiki pages (it should), Dataview generates dynamic tables and lists automatically. "Show me every page tagged #ai and #business updated in the last 30 days." Instant.

Put your vault in a git repo. The wiki is just markdown. You get version history, branching, and — if you want — team collaboration. I push my vault to a private GitHub repo as a backup. Never worry about losing it.

Evolve your CLAUDE.md weekly. The first version will suck. After two weeks you'll notice patterns — things the AI consistently gets wrong, formatting decisions you don't like, rules you wish it followed. Add those to the schema. By month three your CLAUDE.md is a 2000-word document that makes Claude behave exactly the way you want. This is where the real leverage lives.

Keep an "exceptions" file in the schema. When the AI does something wrong, don't just fix it — note it in CLAUDE.md so it doesn't happen again. Example: "When summarizing financial data, always preserve exact numbers. Do not round." One sentence in the schema prevents a hundred future errors.

Run the health check on Sundays. Weekly cadence is a sweet spot. Daily is overkill. Monthly lets errors compound too long. Sunday mornings, coffee, lint-report.md open, spend 20 minutes cleaning up the wiki. It's meditative.

The Thing Most People Get Wrong

You do NOT need Obsidian to make this work. A folder of markdown files and a good CLAUDE.md will outperform a fancy tool stack 90% of the time.

Obsidian is just a nice window to look through. The real system is:

1. The folders
2. The schema
3. The AI
4. Your discipline about not editing the wiki manually

That's it. Everything else is decoration.

I see people spending weeks picking between Obsidian, Logseq, Heptabase, Tana, Reflect, Mem, and never actually building anything. Don't be that person. Pick Obsidian, build the thing, then switch later if you want.

The tool is the least important part of this. The pattern is the point.

The sibling playbook

If you've already read Query Anyone's Brain (PB-001), you've seen the inverse version of this protocol. That one is for studying other people's bodies of work. This one is for compounding your own. Together they're the full personal intelligence stack. PB-001 is how you absorb the world. PB-002 is how you build a memory of what you've absorbed and what you've thought. Most people only run one or the other. The asymmetric move is running both and letting them feed each other.

One Last Thing

The reason this approach works and the reason it's going to make everything else look primitive in 12 months is because it respects how knowledge actually works.

Knowledge isn't a database you query. Knowledge is a living structure that gets refined every time you encounter new information. The old way: upload docs, get answers, treats knowledge like it's static. It's not. It's alive.

A wiki that updates itself every time you add a source is closer to how your own brain actually works, except your brain forgets and this one doesn't.

At the end of the day, the people who win the next decade aren't the ones with the most AI tools. They're the ones with the most compounded context. The ones whose AI gets smarter about their world every single day while everyone else is still asking ChatGPT the same questions from zero.

Build the wiki. Feed it every day. Let it compound.

That's the game.