The second brain, three years in: what worked, what was theatre, and what AI changes

In 2021, a lot of engineers built a second brain. The book by Tiago Forte had made the pitch clearly: knowledge workers lose ideas, context, and decisions because they keep them only in their heads. An external, trusted system changes that. Most engineers who tried it spent a weekend setting up Obsidian or Notion with folders, tags, and templates. Most of them are not using it consistently anymore.

The pitch was reasonable

The problems the system promised to solve were real. Engineers lose context between projects. A decision made in Q2 gets questioned in Q4, and nobody can remember why the team ruled out the alternative they are now revisiting. Resources bookmarked mid-sprint never get read. Ideas jotted in the margin of a notebook become illegible three months later.

Forte argued that professionals increasingly work with knowledge rather than physical objects, and that most tools for managing it are stuck in the pre-digital era. That argument has not stopped being true. The pitch was not wrong. The implementation is where things fell apart.

The collapse follows a predictable pattern

For the first two or three months, the system works. There is time to process notes. The inbox stays manageable. The daily review actually happens. The system feels like it is paying off.

Then the first real crunch arrives: a deadline, a launch, a quarter-end sprint. The inbox stops getting processed. Notes pile up unreviewed. The daily review stops.

When the crunch ends, the inbox has thirty items in it. Some are still relevant, most are not. Re-engaging means deciding which is which — a task that feels more exhausting than useful after a six-week sprint. So the engineer ignores the inbox and keeps taking notes, hoping to process them later. The inbox grows to fifty items. Then a hundred. By this point, the system is not a second brain. It is a guilt archive.

Most people restart once or twice. The cycle repeats. Eventually the system just stops getting opened.

The collapse is not random. It happens at exactly the same moment for almost everyone: the first time the system requires maintenance they do not have time for.

The actual problem: you built an inbox, not a retrieval system

The second brain literature frames the core function as retrieval: build the system, and you will be able to find anything you captured. The problem is that retrieval requires organisation, organisation requires time, and time is exactly what you do not have when you most need to retrieve something.

You needed the decision log the day after the sprint, not the weekend after. You needed the resource the hour after you bookmarked it, not after you had organised it into the right folder. The system assumed a version of yourself who had downtime for gardening notes, and that version of yourself only shows up reliably between projects.

PKM systems are optimised for capture (low friction, feels good) and storage (pretty, searchable) but break at retrieval (which requires the item to have been processed first). Most engineers end up with a perfectly structured system containing no usable content, or a system full of unprocessed captures that take longer to search than a web search would.

Three things that actually held up

After several years of watching engineers try and mostly abandon these systems, the habits that survived were not the elaborate ones. They shared a single trait: each had a concrete retrieval moment built in from the start.

Project scratchpads. A single file, or a folder with a few files, that lives alongside the project and gets archived when it ships. No backlinks, no taxonomy, no daily review. Just a running note of what you are trying, what broke, what you decided. The retrieval moment is built in: you open it when you are working on the project.

Decision logs. Brief records of why a technical choice was made: what was considered, what was ruled out, and why. The architecture decision record format is the right shape, but a simple bulleted list in a markdown file committed to the repo works just as well. The retrieval moment is concrete: when someone questions the decision six months later, you open the file.

Post-project retrospectives. A one-page note written after a significant piece of work ships. What worked, what broke, what you would not do again. Short enough to actually write, specific enough to be useful. The retrieval moment is predictable: the start of the next similar project.

The pattern is the same across all three. The retrieval moment is not "whenever I happen to search for it." It is tied to a specific future event you can anticipate in advance.

What AI changes about the problem

The original case for a second brain included capturing expertise — how-to summaries, reference notes, technical explanations — so you could retrieve them later. That use case has been mostly eliminated by LLMs.

Before Claude and GPT, capturing a detailed note on how Postgres MVCC handles concurrent writes made sense: it was hard to find, harder to summarise, and took an hour to understand from first principles. Today you can ask for a precise, well-structured explanation in 30 seconds and get a better answer than you would have written yourself. The marginal value of capturing generic expertise is now close to zero.

What AI cannot do is know what your team decided, what your project's specific constraints were, or why your particular tradeoff was made. The decision log, the project retrospective, the context that is unique to your situation — that is what remains worth capturing manually.

Capture itself has also become cheaper. Voice memos with transcription mean that getting an idea out of your head takes 20 seconds instead of five minutes. The note is imperfect, but it exists. Whether you do anything with it is still the bottleneck, but the friction of initial capture has dropped substantially.

The minimal system

Here is what the minimal version looks like in practice.

One scratchpad per active project. A markdown file in the project directory, or a small folder if the project is large. Entries are dated but not elaborate. It gets archived when the project ships and rarely read again — but when it is read, it saves hours.

A decisions file in every repo. Not every decision needs logging, but decisions that were argued over do. Three sentences is enough: what was decided, what was ruled out, and why. Committed to the repo so it survives team changes.

A monthly retrospective. One note per month, written in under thirty minutes. What shipped, what broke, what you would change. No template required. This takes discipline, but it compounds in a way that nothing else does — reading six months of retros before starting a similar project is genuinely worth the time.

No inbox. No daily review. No annual review. No tag taxonomy. No graph view.

The test: if you have not opened the system in three weeks, you can pick up exactly where you left off in under five minutes. If re-engagement requires maintenance first, the system is too complex for the version of you that exists during a sprint.

The second brain worth keeping

The second brain promised to make knowledge workers more productive by externalising memory. The parts of that promise that held up are specific, not general: knowing why a decision was made, what broke in a project, what was learned. The parts that collapsed were the ones requiring regular maintenance to keep working.

In 2026, the narrow version of the system is genuinely useful, and AI handles most of what the broader version was trying to do. The question is not whether to build a second brain. It is whether you are capturing the things only you can know, or the things any LLM could tell you faster.