Second brains are have moved from personal archives into agent-readable cognitive infrastructure. The central constraint is dual legibility. The system has to make sense to me, in Obsidian, and it has to make sense to Claude in the repo. Throughout history, scholars, scientists, philosophers, and writers have kept some version of an external thinking system. Commonplace books serve as working scrapbooks to store arguments, fragments, and half-formed ideas, to be returned to later. They were not kept as diaries in the introspective sense. John Locke even wrote A New Method of Making Common-Place-Books, offering a system for arranging quotations, ideas, and speeches by subject and category. Cognitive scientist Don Norman, in Things That Make Us Smart, explored how humans become smarter by building external aids that extend memory and reasoning.

The urge to build an external mind is not new.

Certain models catalysed a shift from archive to systems where the intelligence lived in the structure between notes. German sociologist Niklas Luhmann created the Zettelkasten (slip-box) system considered the precursor to modern second brains in the early 1950s. Each note became a node in a wider web of thought, allowing old ideas to collide with new ones and generate unexpected arguments. You can find all of his notes on niklas-luhmann-archiv.de (see here Luhmann’s note on political rationalism). (sidenote: Side note: search results can be pulled as JSON by replacing the frontend search URL with the API endpoint v0.api.niklas-luhmann-archiv.de/ZK/search I want to try exporting Luhmann’s system into Claude and reconstructing the graph layer in Obsidian.) Tiago Forte’s PARA Method later catalyzed the explosion of the “Second Brain” concept through his series of viral blog posts in 2017. PARA categorised information by use rather than just topic or source. It stands for Projects, Areas, Resources, and Archives.

This brings us to April 2026 when Andrej Karpathy’s Second Brain article (“LLM Wiki”) goes viral:

LLM Knowledge Bases

Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating…

— Andrej Karpathy (@karpathy) April 2, 2026

The key shift in Kaparthy’s implementation is plain text plus structure. It ingests raw sources and the wiki is maintained by claude. It went viral because he revealed how second brain architecture can become immensely more powerful when layered on top of claude code:

llm-wiki/
  ├── CLAUDE.md         # schema / operating manual for the LLM agent
  ├── raw/              # immutable source documents: articles, papers, images, data files
  ├── wiki/             # LLM-generated markdown wiki: summaries, entities, concepts, syntheses
  │   ├── index.md      # content-oriented catalog of wiki pages
  │   ├── log.md        # chronological record of ingests, updates, and decisions
  │   ├── entities/     # people, companies, projects, places, recurring objects
  │   ├── concepts/     # reusable ideas, themes, mechanisms
  │   ├── sources/      # source summaries / extracted notes
  │   └── syntheses/    # comparisons, briefs, analyses, evolving higher-order pages
  └── outputs/          # optional generated outputs: answers, reports, charts, slide decks

A folder of Markdown files, if structured well, can be searched and maintained by Claude. He can identify contradictions, generate summaries, and file outputs back into the system. This is where my own system started: if the goal is not just to store information, which parts of these traditions should I actually use? My system leans heavily on the concept of Molecular Notes, adapted to suit my workflow and optimised for CLAUDE. Every design decision has to pass two tests: is this useful for the human navigating the graph, and is this legible to Claude operating inside the repo? Folders should support human navigation. Frontmatter should provide standardised machine-readable metadata. The only formal lineage field is derived-from. Body wikilinks carry the softer conceptual relationships: ideas that support, contradict, echo, or complicate one another.

FILE STRUCTURE:

second-brain/
  ├── CLAUDE.md
  ├── sources/          # reference notes, one per source 
  ├── book-notes/       # chapter extractions from books (seperate skill published to my gh-repo)
  ├── atoms/            # single concepts, self-contained
  ├── molecules/        # personal insights in your own words
  ├── compounds/        # re-synthesis: essays, theses, blog posts, projects
  ├── authors/          # author nodes (created when author links to 2+ sources)
  ├── MOCs/             # semi-structured navigation indexes on a topic
  ├── _templates/       # note type templates (excluded from Obsidian graph)
  └── _system/          # skills and scripts (excluded from Obsidian graph)

PIPELINE:

sources/
    ↓ extraction
book-notes/ 
    ↓ distillation
atoms/
    ↓ synthesis 
compounds/
    = larger outputs ↔ projects
MOCs/
    = navigation layer across all of the above

ORGANISATION:

Native Obsidian can do this through Graph view → Groups. Groups accept normal Obsidian search syntax, including tag:#... and frontmatter/property queries like [type:atom]. Obsidian’s docs say Graph groups are made by adding a search term and assigning it a colour; property search uses [property:value]; tags are searched with tag:#work

Roadmap and Open Questions to explore

## Roadmap / Open Questions

This system is still evolving. A few design questions I am interested in exploring:

### 1. Linear event tracking inside an interlinked second brain

Can a second brain support both linear chronology and nonlinear conceptual synthesis?

Most knowledge systems are either timeline-based, like journals and logs, or graph-based, like Zettelkasten and Obsidian vaults. I am interested in whether ongoing events, decisions, experiments, and project histories can be tracked linearly while still feeding into atoms, molecules, and higher-order synthesis.

### 2. Emergent intelligence through Claude + skills

Can AI-assisted skills help the system become more intelligent over time?

So far, this system includes skills for surfacing supportive and contrasting claims. But there are many possible ways to build connective tissue between disparate ideas: contradiction detection, analogy finding, source clustering, claim lineage, open-question tracking, and synthesis prompts.

The goal is not for Claude to “own” the knowledge base, but to act as an advisor on the graph: surfacing possible connections, tensions, and missing structure.

### 3. Projects and knowledge fragments

Should projects live inside the knowledge base or adjacent to it?

Currently, projects live adjacent to the knowledge base. This keeps the second brain focused on durable knowledge rather than execution clutter. But a more advanced version could treat project work as a source of reusable knowledge fragments, where project decisions, experiments, failures, and insights can eventually be promoted into atoms, molecules, or compounds.

### 4. Status promotion ritual

How should notes mature from seedling to evergreen?

A future version may introduce a more explicit promotion ritual, where notes move through stages such as:

- `seedling`
- `active`
- `evergreen`
- `archived`

This would make the system less static and more developmental: notes would not just accumulate, they would evolve.