AI Second Brain

Here is a slightly embarrassing truth about an MBA. You spend two years collecting frameworks, cases, spreadsheets and late-night insights. Then you graduate, and all of it quietly slides into a Downloads folder you will never open again.

I could feel it happening. Strategy lived in one course folder, finance in another, marketing in a third. The ideas were connected in the real world, but in my files they were total strangers. If I needed a framework six months from now, I would be digging through slide decks named Final_v3_REAL.pptx.

So I set myself a goal before graduation: compound everything I learned into one connected wiki. Not a pile of summaries, but a structured, referenceable library I can keep using for years.

The goal was simple: turn messy, unstructured course material into a clean, local file library that works like a record I can always come back to.

The spark came from Andrej Karpathy's "LLM Wiki" idea. The usual way to use AI with your documents is to have it search the raw files every single time you ask a question. It works, but nothing builds up. Every question starts from scratch.

The LLM Wiki pattern flips that around. The AI reads the raw sources once and compiles them into a persistent wiki of interlinked markdown pages. A schema file tells it how the wiki should be organized. Each new source updates and enriches pages that already exist, so the knowledge compounds over time instead of being rediscovered on every question.

That clicked for me immediately. It is basically what a great student does with their notes, except the AI does the tedious filing and linking, and I get to design the system.

The workflow has three parts. I drop raw material into a folder. A Claude agent (running in Claude Code) reads it, summarizes it and cross-links it. The result lands as pages in an Obsidian knowledge base.

Two small files hold the whole thing together. The index is a catalog of every page in the wiki, so the agent knows what already exists. The log is a running diary of what was ingested and when, so the agent knows where it left off.

In other words, this is a local, file-based knowledge library. People sometimes call it a "local RAG", and that is close in spirit: the AI still retrieves information before it writes. But instead of a vector database, retrieval happens through an index, links and a log that the agent maintains itself. More on that comparison further down.

The wiki started at about 50 pages. By the time all the courses were in, it had grown to roughly 580.

The graph at the top of this page is a small, curated sample of that wiki. The full ~580-page version stays on my laptop, so do not be surprised that the web graph has far fewer nodes.

Three tools did all the heavy lifting. Each one had a very clear job.

Notice what is missing: no vector database, no embeddings service, no custom backend. Just files, an agent and a viewer.

The first job was to separate what the agent reads from what it writes. Raw course material goes into one folder and is never edited. The wiki lives in another folder, and the agent owns it completely.

second-brain/
├── CLAUDE.md          # the operating manual (schema)
├── raw/               # untouched course files, by course
├── wiki/
│   ├── concepts/      # one page per idea
│   ├── sources/       # one summary per source
│   └── syntheses/     # cross-course pages
├── index.md           # catalog of every wiki page
└── log.md             # what was ingested, and when

This is a simplified view, but the principle is the important part. Keeping raw sources read-only means I can always trace a wiki page back to where the idea came from.

This is where most of my time went, and it surprised me. Claude Code reads a file called CLAUDE.md at the start of every session. I turned that file into the agent's operating manual: what kinds of pages exist, how they link to each other, and the exact workflow for ingesting a new course.

Once the schema was solid, I did not need clever prompts. I could say something close to "ingest the next course" and the agent knew what to do.

Every page in the wiki is one of three types. Keeping the list short made the whole system easier for both me and the agent to reason about.

The key rule: each concept gets exactly one page. If finance and strategy both talk about the same idea, they add to the same page instead of creating two.

Each working session handles one course, start to finish. The agent opens the index and the log, works through that course's raw files, writes or updates pages, and records what it did before the session ends.

Every session starts cold. There is no chat history carried over. The agent simply reads the index and the log and picks up where the last session stopped. That sounds limiting, but it turned out to be one of the most reliable parts of the setup.

Why one course at a time? An AI model can only hold so much text in its working memory (its "context window"). Keeping each session tightly scoped meant the agent was never juggling too much at once, and quality stayed consistent as the wiki grew.

This is where the magic happens. When the agent ingests a new course, it does not just add new pages. It goes back to existing concept pages and adds the new course's angle to them, then links related ideas together.

The more courses went in, the more each new one had to connect to. When a theme showed up across several courses, it earned a synthesis page that ties those threads together.

After each session I opened the vault in Obsidian and looked at what changed. The graph view is great for this: odd clusters, orphan pages or suspicious links stand out quickly.

When something looked wrong, I usually fixed the schema rather than the page. A better rule in CLAUDE.md fixes the problem for every future session, while a manual edit only fixes one page. Then on to the next course.

Building this taught me a lot about working with AI agents. Here is what stuck.

1. The schema is the product

The agent reads one operating manual and then runs the ingestion itself. Most of my iteration went into that document, not into prompts. Writing a good spec for an agent turned out to be a product management exercise: define the users, the outputs and the rules up front.

Design the system before you hand it to the agent.

2. The file system is the memory

No vector database, no RAG pipeline, no chat history. Every session starts cold, reads the index and the log, and carries on. Plain markdown turned out to be a very reliable memory for an agent: I can inspect it, version it and read it myself.

If a human can read the agent's memory, a human can fix it.

3. Architecture followed context limits

"One course per session" was not a product decision. It was a context management decision. But that tight scope is exactly what kept quality consistent from page 50 to page 580.

Sometimes the constraint designs the system for you.

4. The payoff was cross-referencing, not summarization

Summaries are nice. Connections are the real prize. Because each concept has one page that collects every course's perspective, the agent surfaced links I never made as a student. Siloed courses became one body of knowledge.

The value is not in any single page. It is in the links between them.

RAG stands for retrieval-augmented generation. In plain words: before the AI answers, it looks things up in your documents. The classic way to do that is to chop documents into small chunks, turn each chunk into numbers (embeddings), and store them in a vector database that can find "similar" chunks when you ask a question.

That is a great fit for some problems. For mine, I wanted something I could read, browse and keep as a long-term record. Here is how the two approaches compare.

To be fair, this is not a replacement for RAG in every case. At a few hundred pages, an index the agent can read is enough. At a much bigger scale, some kind of search layer would probably earn its place again.

The full wiki stays private. It is built from course material that is not mine to share, and it is full of my own half-finished thinking. So the graph at the top of this page is a curated sample: a few dozen notes on strategy, product, marketing and finance that show the shape of the system without exposing the vault.

Obsidian's own graph cannot be embedded in a website, so I rebuilt the experience for the web with Cursor. The sample notes live in a small data file that ships with the site. The graph runs in your browser: you can drag, zoom, filter by tag and click any node to read its excerpt and jump to related notes.

Building the wiki was step one. Now I am experimenting with the best ways to actually query it. A few ideas I am playing with:

If you have built something similar or have a favorite way to query a personal knowledge base, I would genuinely love to hear it. Send me your suggestions.

I took two years of MBA material, around 3,000 messy files across 27 courses, and turned it into a ~580-page linked wiki that lives on my laptop as plain markdown. A Claude agent did the reading, summarizing and linking. My job was to design the system it worked inside.

The biggest lessons had less to do with AI and more to do with product thinking: write a clear spec, let simple files be the memory, respect the constraints, and remember that the real value lives in the connections.

Explore the sample graph above, then steal this process for your own notes. Your future self (and your Downloads folder) will thank you.