Build an AI Second Brain From a Pile of Docs

I fed 95 podcast episodes, 1.5 million words, into a folder. On my machine, a cheap model now answers “six months searching, zero offers, what am I doing wrong” like a coach who heard every one, and cites which. The map it built is public: explore it here.

No database. No embeddings. No code. A folder of linked markdown the LLM wrote and keeps current.

Here is how to do it to your own pile.

#Problem

Every business runs on documents. Contracts, transcripts, diligence notes, saved research. Scattered across fifty folders and a Slack nobody scrolls.

The answers are in there. Getting one out means reading everything, every time. So nobody does, and the knowledge rots.

Your LLM can’t help. It can’t see your files, and it forgets every chat. A brain with no library.

#Solution

Make the LLM the librarian.

It reads your docs, files each idea into a note, links related notes, and flags contradictions. You curate the sources. It does the tedious part. This is the LLM wiki Andrej Karpathy sketched out.

A knowledge graph, not a graph database. No Neo4j. No vector store. Markdown files with [[links]] between them. If you can drag in a folder, you can build this.

#Value

Ask anything. Get an answer from your own documents, with the source attached.

• Searching: every CIM and seller call across active deals, one place to ask.
• Operating: the team asks how do we do X here instead of pinging you.
• Investing: patterns across the portfolio, not just inside one company.

#How it works

Three layers. Sources are your documents; read-only. The wiki is the LLM’s: linked notes it writes and rewrites. The schema is one file naming the note types and how they link. You own that one, and it is the whole game.

Then four steps:

1. 01
   Write down five questions you'll ask it. The questions pick the schema, not the documents. Seller calls become a different vault for what objections recur than for where does the Henderson deal stand.
2. 02
   Feed it ten docs, not the pile. Let it read them and propose a structure.
3. 03
   Iterate the schema. Have it build ten notes, show you two, and ask what's wrong. Three rounds. The only step that needs your judgment, and the expensive place to be wrong: a bad schema at doc 10 costs a minute, at doc 400 a rebuild.
4. 04
   Freeze it. Ingest everything. Ask. Every answer cites its note. Every note links back to the source document.

#See it: Obsidian first, then the web

Your vault is a folder of linked markdown, so Obsidian opens it as-is. Graph view, backlinks, full-text search. Free, local, nothing to deploy. That is where you work.

When you want to hand it to someone, one script publishes the same vault as a graph site: index on the left, graph on the right, click a node to read. That is the map, not the chatbot. A static site has no model behind it; the asking stays on your machine, next to your files. Workshop and showroom, same folder behind both.

#Why it works

You outsourced the filing. Reading, tagging, cross-linking, keeping it current: the work that rots when a human owns it, handed to the thing that never gets bored. Same move as externalizing project memory out of a long chat.

Two things fall out. The model stops making things up, because it’s handed the right notes and told to cite them. And it gets cheap, because a small model can follow a map. The intelligence moved out of the model and into the map.

Add embeddings the day plain files visibly miss. Most ventures never get there.

You need a pile of docs, a clear schema, and a weekend.