Obsidian
-
Embeddings Are Cheap Enough for Personal Wikis Now
My Obsidian vault is my main second brain: around 1,800 Markdown notes. Lately I’ve been less interested in what to put in it and more interested in a different question: what useful tools could I build on top of it?
A few ideas came to mind. Could I do better than Obsidian’s built-in search for the times I remember the idea but not the exact words I used? Could I eventually wrap the whole thing in my own little plugin? Both sound like fun future projects. But the one I wanted to tackle first was better backlinking: getting the system to find related notes and suggest links, so the graph helps maintain its own structure.
So I did what any reasonable person would do. I turned it into a small experiment.
The task was deliberately concrete: given an ordinary note, suggest the topic notes it should link up to. In Obsidian terms, that means adding a frontmatter field like this:
--- up: - "[[TypeScript]]" - "[[Agentic Harness Landscape]]" ---Call them parent backlinks, MOC links, or knowledge graph edges. The label matters less than the shape: each note can have zero, one, or several parents, and the system should never force every note into exactly one folder.
The Setup
My vault had about 1,800 notes, 27 topic hubs (the pages other notes already linked to, like “TypeScript” or “Tailwind CSS”), and a hand-labeled gold set of 38 notes. No vector database. No pre-existing
up:links.Every approach had to emit the same report schema, so I could compare methods mechanically instead of eyeballing a few good examples. And nothing wrote to the vault by default. Applying links was a separate, explicit step. That “report first, apply later” rule is the difference between a useful automation and a spooky one.
The Baseline: Full-Text Search
I started with classic keyword retrieval: index the topic notes, turn each child note into a query, score with Postgres full-text search plus trigram similarity. It’s a good baseline because it’s deterministic, cheap, and explainable.
But it has an obvious weakness in a personal wiki. A note can be about “serverless container hosting” without ever saying “Azure Container Apps.” A note about pyenv and virtual environments might belong under “Python” without naming it. FTS is great when the words line up. Personal notes often don’t.
The Embeddings Version
The embeddings approach was simple: build a text representation for every topic note and every child note, embed both with Google’s Gemini Embedding 2 model, normalize, take the cosine similarity, and keep the top matches above a threshold.
The text prep mattered more than anything else. For child notes I used the title plus opening body. For topic notes, the title, aliases, summary, and first section, stripping wiki-link syntax. MOC pages are often long lists of
[[Some Note]]links, and that’s worse input than a short prose description of what the topic actually means.I did not need vector infrastructure. Vectors were stored as plain arrays in Postgres, cosine similarity computed in Python. With 27 topic vectors and 1,800 child notes, brute force ran in about 6 seconds, and embedding the whole vault plus every test run cost about 30 cents. At this scale, architecture matters less than good text prep.
The Numbers
On the 38-note gold set:
Approach Recall@1 Recall@3 MRR F1 Full-text search 0.519 0.615 0.609 0.424 Embeddings 0.923 0.962 1.000 0.622 Of the 30 intended links across the gold set, embeddings found 28 and missed 2. Full-text search found 18 and missed 12.
The precision wasn’t amazing, and that’s fine. The goal of the first pass is high-recall suggestion, not automatic writing. It produces candidates for review. A later LLM reranker or a human can tighten precision.
One detail surprised me. I tested two query framings: one worded as “search result,” one as “semantic similarity.” Ranking was identical, but the similarity framing had worse precision because it surfaced loosely related matches. For “which topic should this note be filed under?”, the task behaves more like search than duplicate detection. Semantic search and semantic similarity are not the same product requirement.
Thresholds and the Gold Set
My first threshold was too low. Everything looked related to everything. Raising cosine similarity to around 0.70 cut the output to a reviewable set: of 1,805 notes scanned, 682 got at least one suggestion, averaging about 2.4 parents each. The rest got nothing, which is correct. Plenty of notes are fragments, logs, and one-offs. A good backlink suggester should be comfortable saying nothing.
You don’t find that threshold on a model card. You find it on your own notes.
Which brings me to the most valuable artifact in the whole project: the gold set. It wasn’t the embedding index. It was 38 hand-labeled notes, including negative examples with no expected links. Without it, I’d have judged by vibes, and that’s dangerous with embeddings because the good examples look magical. You need the misses in the same report or you’ll overestimate the system. Thirty to fifty labeled examples is enough to expose bad assumptions.
What I’d Actually Do
If I were adding this to another wiki, the order would be:
- Pick 20 to 100 topic notes explicitly, by folder, tag, or inbound link count. Don’t make every note a possible parent.
- Label 30 to 50 examples, negatives included.
- Build an FTS baseline first. If embeddings can’t beat it on your labeled data, your text prep is wrong.
- Build the embedding baseline and compare.
- Tune text prep and threshold.
- Emit a report before any writes.
- Only then consider LLM reranking or a real vector database.
That order keeps you honest. You’ll know whether embeddings help your wiki before you spend time getting Qdrant setup.
Personal wikis are small enough that we can stop treating semantic search as an enterprise architecture problem. The interesting work isn’t the vector database. It’s deciding what “related” means in your own graph, measuring it against your own notes, and building the tool so it suggests, explains, and writes only when asked. Use semantic search to propose structure. Use reports and gold sets to keep it honest. Let the human knowledge base stay human.
I’ll probably keep poking at it.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
Karpathy's LLM Wiki: Your Second Brain, Maintained by the Machine
A few months ago Andrej Karpathy dropped a GitHub gist that coined a term I haven’t stopped thinking about: the LLM Wiki. The pitch is simple enough to fit on a napkin. Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.
Sit with that for a second. It reframes your second brain as something the model builds and maintains, not something you query. When I walked through the history of the second brain, this is the corner I promised to come back to.
Compile, Don’t Retrieve
The usual move with a big pile of notes is query-time RAG. You ask a question, some vector embeddings go find the closest chunks, and the model stitches together an answer on the spot. It works, but the knowledge never gets organized. You’re re-deriving structure every single time you ask.
Karpathy flips it. Instead of retrieving at query time, the LLM compiles the knowledge ahead of time and keeps it current. The result is a persistent, cross-linked markdown wiki. The model doesn’t get bored, doesn’t skip the boring summary, doesn’t forget to update the index. It just keeps the thing tidy.
Google landed in a similar spot with their Open Knowledge Format (OKF), which formalizes the same idea as a curated markdown bundle with an open spec. So this isn’t one person’s hot take. The pattern is in the water.
The Three Components
Karpathy’s wiki has three parts, and the separation is the whole point.
Raw sources. Your curated collection of source documents. These are read-only. The LLM reads them but never edits them. He recommends a
raw/directory, with subdirectories for non-text files. This is your ground truth, and keeping it untouchable is what keeps the rest honest.The wiki. A directory of LLM-generated markdown: summaries, entity pages, concept pages, comparisons, overviews. The model owns this entirely. It creates the pages, maintains the cross-references, and enforces consistency. You’re not in here hand-editing.
The schema. A document like
CLAUDE.mdorAGENTS.mdthat tells the LLM how the wiki is structured, what the conventions are, and how the workflows run. It evolves as you use the system. Think of it as the contract between you and the machine.The Three Operations
The classic Second Brain CODE method has four steps. Karpathy’s version lands on three operations, which I appreciate.
Ingest. You add a source. The LLM reads it, writes a summary page, and updates the index. While it’s in there, it can also touch up related entity and concept pages and log the event. One new document ripples outward into everything it connects to.
Query. You ask a question against the wiki. The model finds the relevant pages, reads, and synthesizes an answer as markdown, tables, whatever fits. Here’s the part I like: a useful exploration can be filed as a new page. So the act of asking a good question makes the next answer easier to produce. The knowledge base gets smarter by being used.
Lint. A periodic health check. The model hunts for contradictions, stale claims, orphan pages, broken references, and missing concepts. The gaps. Then it suggests new questions to ask and new sources to chase. It’s the maintenance pass you’d never do yourself.
The Supporting Cast
A few files make the whole thing run:
index.mdis the content catalog. Every page, a link, a one-line summary, and some metadata, grouped by category. The model reads this first on a query.log.mdis an append-only chronological log with greppable entries like## [DATE] operation | title.qmdis a local markdown search engine (BM25 plus vector plus an LLM re-rank), available as a CLI or MCP server, for when the wiki outgrows a plain index lookup.
And because this lives in Obsidian, you get some nice perks for free. The Web Clipper turns a browser tab into markdown straight into
raw/. Graph View is a visual lint, hubs and orphan pages pop right out. Dataview pulls frontmatter into dynamic tables. And Marp spits out slides directly from your wiki pages.Why This Clicks for Me
The thing I keep coming back to is the read-only
raw/boundary. So much of the anxiety around AI touching your notes is “what if it mangles something I care about.” Splitting sources from the generated wiki means the model can be as aggressive as it wants in the wiki layer, and your source of truth never moves. The worst case is you regenerate a summary page. No harm done.I haven’t fully committed my own vault to this yet, but the shape is right. A knowledge base that maintains itself, where asking good questions leaves the place better than you found it. I’ll probably keep poking at it.
Sources
- Andrej Karpathy, LLM Wiki: A Pattern for AI-Maintained Knowledge Bases — the three components (raw/wiki/schema), the three operations (ingest/query/lint),
index.md,log.md,qmd, and the Obsidian tooling (Web Clipper, Graph View, Dataview, Marp). - Sam McVeety & Amir Hormati, “Introducing the Open Knowledge Format” (Google Cloud Blog, June 12, 2026) — Google’s OKF as a curated markdown bundle with an open spec, explicitly formalizing the same LLM-wiki pattern.
- Tiago Forte, Building a Second Brain (2022) — the CODE method (Capture, Organize, Distill, Express), the “classic” four-step workflow this post lines up against Karpathy’s three operations.
- Roger Montti, “Google Cloud Announces The Open Knowledge Format” (Search Engine Journal, June 15, 2026) — independent news coverage of OKF, including the quote linking it back to Karpathy’s LLM Wiki gist.
- Cecilia Meis, “Google Launches Open Knowledge Format, an AI Standard” (Semrush Blog, June 23, 2026) — news coverage framing OKF as a vendor-neutral markdown spec for AI agent knowledge.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
A Brief History of the Second Brain
The phrase “second brain” is glued to Tiago Forte and the productivity wave of the 2010s. But the ambition behind it is nearly five centuries old, and the method is a lot older than the name. So let’s walk the timeline, because the story is more interesting than the buzzword.
It Starts With Slips of Paper
Go back to antiquity and you’ll find people keeping personal notebooks of quotes, recipes, and observations. The commonplace book. Nothing fancy, just a place to park the ideas worth keeping.
Things get more systematic in the mid-1500s. A naturalist named Conrad Gessner suggested cutting notes into individual slips and gluing them onto sheets so you could rearrange and reassemble ideas from pieces. That modular instinct, breaking knowledge into movable units, is the seed of what the Germans would later call the Zettelkasten, the “slip box.”
About a hundred years later, Thomas Harrison built the Arca Studiorum, the “ark of studies.” It was a literal cabinet where paper slips hung on labeled metal hooks, sorted by subject. The design was published posthumously by Vincent Placcius in 1689, which makes it one of the first documented personal knowledge devices. Leibniz reportedly relied on it for one of his projects. A hundred years after that, Carl Linnaeus was working with standard-sized paper slips, over a thousand of which survived. Basically the index card before the index card existed.
For roughly 300 years this stayed a scholarly habit. Researchers, clergy, naturalists, the PhD crowd. Not something the general public thought about.
The Idea Goes Electric (In Theory)
In 1945, Vannevar Bush wrote an essay in The Atlantic called “As We May Think,” and described the Memex: a desk-sized microfilm machine that would store all of your books, records, and correspondence, with mechanical “associative trails” linking related items together. It never got built. But read that description again and tell me it doesn’t sound like every linked-notes tool we use today.
Then comes the patron saint of the second brain: Niklas Luhmann. From the 1950s onward he built a Zettelkasten of around 90,000 index cards over four decades. Each card got a unique ID, each linked to others by ID, a physical knowledge graph made of paper. Out of it came dozens of books (some counts say 70) and hundreds of articles. He described the system as a thinking partner he could have a conversation with. His archive was digitized and put online in 2019, so you can go poke around in it.
Luhmann wasn’t a one-off. The 20th century is full of scholars running the same playbook:
- Walter Benjamin (Arcades Project, 1927-1940)
- Roland Barthes (12,250 cards)
- Hans Blumenberg (30,000+ cards)
- Arno Schmidt (100,000+ cards for Zettels Traum)
- Mario Bunge (70 books, 540 articles out of his card files)
The Computer Was Supposed to Be the Second Brain
Through the 1980s to the 2000s, we still didn’t have today’s vocabulary. We had the PIM, the personal information manager, and the PKM, personal knowledge management. The personal computer itself was pitched as the thing that would know everything about you.
Apple, Xerox, and Microsoft all took a swing:
- NoteCards (Xerox PARC, 1985) was modeled directly on 3×5 index cards with typed links, an early hypertext take on the slip box.
- HyperCard (Apple, 1987) handed people a hypertext stack system, and its card metaphor was a straight callback to the Zettelkasten. It’s also what inspired Ward Cunningham to build the first wiki in 1994.
- Outliners like MORE, Ecco Pro, and Lotus Agenda chased hierarchical thought.
- OneNote (Microsoft, 2003) was the first mass-market freeform digital notebook.
- Evernote (2008) nailed the capture half with “remember everything,” but stayed folder-and-tag based, never a graph.
Zettelkasten Goes Public
In 2017, a writing coach named Sönke Ahrens published How to Take Smart Notes. He translated Luhmann’s dense German academic method into plain English for students and knowledge workers, and put the slip-box workflow, capture, permanent notes, link, develop, in front of a non-academic audience for the first time.
Almost in parallel, Tiago Forte coined the modern “second brain” and aimed it squarely at the everyday knowledge worker. Through Forte Labs he taught PARA (Projects, Areas, Resources, Archives), an action-oriented filing system that rejects the Dewey Decimal instinct, and the CODE workflow (Capture, Organize, Distill, Express) for the life cycle of a note. The 2022 book Building a Second Brain turned it into a movement.
From Folders to Graphs
Then the tools caught up to Luhmann. Roam Research (2020) made bidirectional links the whole point. Its early adopters were overwhelmingly academics, PhD students, and writers, and they showed everyone what diligent linking actually buys you.
Obsidian launched around the same time and is what most people picture now. Local-first, plain markdown, bidirectional links, a huge plugin ecosystem, and a motto that matters: your data is yours. That’s the real pitch. With Roam, Evernote, or Notion you can get your data in, but getting it back out in a format you own is a different story. You’re renting access to your own thinking. Obsidian doesn’t do that. It’s just markdown files on your disk. For my money that makes it the default, and everything with lock-in is a harder sell.
Either way, the shift is the headline: we moved from folders and notebooks to graphs. Links and backlinks. The knowledge graph stopped being a Luhmann eccentricity and became the norm.
And Now You Hook It Up to an LLM
Which brings us to right now. Somewhere around 2023, people started asking the obvious question: what if you point a language model at your second brain? The best way I’ve found is through a CLI-based agentic harness like Claude Code, pointed at your notes. I’ve been running Claude Code against my own vault for over a year, and the same approach works with other agentic coders. OpenCode is good, and Google’s Antigravity (Gemini) has been pretty good too.
There are different strategies for structuring a vault so an agent can read and extend it, and I’ll dig into those in a future post. One you may have heard of is Karpathy’s recent “LLM wiki” idea, which isn’t just about plugging an LLM in, it’s an opinion about how to structure the vault so the model works well with it.
That’s the real evolution. For 500 years the second brain was storage you read from. Now it’s becoming something that reads and writes back.
Era Metaphor Key figure/tool What it solved 1540s-1890s Card file / commonplace book Gessner, Harrison, Linnaeus Modular scholarly notes 1945 Memex (associative trails) Vannevar Bush The idea of external memory 1950s-1990s Zettelkasten (linked slips) Niklas Luhmann Memory as a thinking partner 1980s-2000s PIM (folders, notebooks) HyperCard, OneNote, Evernote Digital storage 2010s Methodology + capture Tiago Forte (BASB, PARA/CODE) A repeatable workflow 2020-22 Knowledge graph Roam, Obsidian Connection over hierarchy 2023- Agent-readable wiki LLMs, Claude Code, Karpathy Active synthesis Gessner was gluing paper slips onto sheets so he could rearrange his ideas. We’re doing the same thing. We just gave the slip box a way to talk back.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Sources
- Vannevar Bush, “As We May Think,” The Atlantic, July 1945 — the Memex proposal.
- Memex — Wikipedia — background on the Memex device and its hypertext legacy.
- Zettelkasten — Wikipedia — Gessner’s glued slips, Harrison’s Arca Studiorum (published by Placcius, 1689), Linnaeus’s paper slips, and the 20th-century card-file users (Benjamin, Barthes, Blumenberg, Schmidt, Bunge).
- Niklas Luhmann — Wikipedia — the ~90,000-card Zettelkasten, digitized and put online by the University of Bielefeld in 2019.
- NoteCards — Wikipedia — the Xerox PARC hypertext system (1985) modeled on 3×5 index cards.
- HyperCard — Wikipedia — Apple’s 1987 hypertext stack system; Ward Cunningham traces the wiki concept back to a HyperCard stack.
AI Obsidian Second brain Note-taking Zettelkasten Knowledge management
-
How I Researched the Time Series With My Second Brain
Writing ~30 daily, deeply technical posts about the history, physics, and software guts of “time” was not something I could sit down and free-type into a CMS every morning. To keep the whole thing cohesive, connecting the 1967 cesium-second redefinition to the Y2038 bug without contradicting myself three weeks apart, I leaned hard on my research workflow.
I don’t have a spicy, controversial take on second brains or personal knowledge management. I have one firm opinion: every engineer should have one. That’s it.
The secret to how I organized the Time series, if there is one, is that I kept it boring. Simple files, a little Markdown discipline, and everything stored locally.
The Master Map
If you opened my Obsidian vault and looked in
Research/Time/, you wouldn’t find a chaotic pile of notes. You’d find a few folders (Physics,Computing,Calendars,Measurement) and one file that mattered more than the rest:30 Days of Time - Blog Plan.md.That document was the central nervous system for the whole month. It didn’t hold the actual post text. It held the roadmap, stitched together with Obsidian’s cross-links. When I was plotting Week 3, the plan read like this:
### Day 13 - Unix time - Source: [[Unix Time]]That
[[Unix Time]]link pointed to a dedicated research note where I’d dumped every raw finding, link, and code snippet I had on the topic, including the rabbit hole on leap seconds getting smeared. The plan stayed clean and skimmable. The mess lived one click away, exactly where I needed it when I sat down to write.Get Good at Markdown, Not Plugins
Don’t go too crazy with plugins. I run a fair number of them myself and that’s fine, find the ones that genuinely help you. But the thing that actually pays off is getting good at the fundamentals of Markdown first, instead of spending a weekend configuring when you could be writing.
Tags and cross-linking are the connective tissue. By tagging research notes with
#timeand#physicsand linking them to each other, you build a web of context that surfaces on its own when you go to write. I didn’t have to remember where I’d put the note on atomic clocks. The links pulled it up next to everything related to it.Tag your concepts, link your ideas, and let the structure do the remembering for you.
Your Agents Can Read It Too
I was experimenting with building Second Brains using LLMs and agents over a year ago, and those early lessons still hold up.
When your entire knowledge base is plain, cleanly tagged, locally-stored Markdown, it becomes easy for the LLM harnesses to help you learn, explain, and synthesize your knowledge. A well-organized vault doesn’t just help your biological brain find things. It lets your AI tools act as an actual research assistant instead of a passive text generator. They can follow your
[[links]], read your tags, and pull the same context you would have pulled by hand.I’ve leaned into this hard on this project. I wrote templates, a handful of custom skills, and a few project-specific sub-agents whose whole job is to figure out how to make my harness work harder for me. That’s the general move I’d push: don’t just store context, build the small pieces of automation that turn that context into real productivity.
The work you do to make a vault readable for you is the same work that makes it readable for the agents.
Just Start Writing It Down
You don’t need a perfect system on day one. I still don’t. The Time vault grew one messy note at a time until it was ready to help shape the series.
As the tooling gets faster and context keeps exploding, having a system to organize your thinking is a superpower. Build something that helps you organize your Markdown, tag your concepts, and cross-link your ideas. Then keep feeding it.
How are you managing your long-term research right now?
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].