An agent I was working with last week figured out something non-obvious about one of my repos: which of two near-identical build steps was the real one, and why the other quietly no-ops. The next morning I opened a fresh session on the same repo and it walked straight into the dead end it had worked past the day before. The model was fine. It just had no memory. Everything it learned died at the session boundary, and I was paying, in time and tokens, to re-teach it the same lesson on a loop. That is the problem a [[second brain::a personal, queryable knowledge base my agents read from and write to, so what one session learns is there for the next]] solves. It gives the model somewhere to keep what it figures out, so the next agent starts where the last one left off instead of paying to re-learn it every morning. In the first essay I called the whole project closing the context gap: giving an agent the accumulated, unwritten context that makes my judgment mine. The second brain is where that context lives when no session is open. It is the memory layer, and building one well turned out to be less about tooling than about a few decisions that sound small and are not. A second brain fails by growing faster than you keep it connected. Most people’s version of this is a folder of notes that only grows. You save the article, the thread, the meeting summary, and a year later none of it is searchable and you would not trust it if it were. I have built that pile more than once. A second brain is only useful if an agent can start anywhere and reach the right note in a couple of hops, which means what you are maintaining is the connections between the notes, and the discipline to keep them true. Without that discipline, the store is a junkyard in a graph no agent can traverse, and every hour an agent spends lost in it is an hour I paid for twice. This is what mine looks like today: type-named folders down the left, and a few hundred notes wired into one graph on the right. Someone on my team pushed back on this early, and the question was fair: how is this different from the context files a coding agent already reads, the ones that tell it your conventions and your stack? It is different in one way that matters. Those files belong to one tool and one repo. They pollute the agent’s window whether or not the task needs them, and they vanish the moment you switch tools. The second brain sits outside all of that. It does not belong to a tool. Any agent, on any tool, reads from it and writes back to it. The coding agent’s context file is a place the tool looks. The second brain is a place I think, that the tool happens to be able to read. The load-bearing idea is that agents write to it. When a session ends, what it learned does not evaporate. It gets distilled into a note that lives outside any one agent’s context window, and the next agent picks it up cold. Memory that outlives the session is the entire point. The rest of this is the machinery that keeps that store from rotting into the junkyard. Everything else hangs on one boring decision. A folder encodes what a note is, never what it is about. The instinct is to file by subject. A folder for longevity, a folder for a given client, a folder for AI. It feels organized for about a month, and then every new note could plausibly live in three folders and you spend more time deciding where things go than writing them. So I do the opposite. The folder says the note’s type: a distilled source, an [[atomic note::a note that holds one idea, small enough to link and reuse without dragging unrelated context along]], a reusable method, a due-dated reminder. The subject lives in tags, which stack without forcing a choice. A note about applying a research method to a health question is one type, in one folder, wearing two tags. I do not police this by hand. Exactly one agent is allowed to write to the store, and its entire brief is to file a note by type, keep the topic in the tags, and stamp every note with where it came from. Two rules in there do the quiet work. Distill, never archive means it keeps the lesson a session taught me, not the session. And every note it writes carries its own provenance, the agent that wrote it and the evidence it came from, so a note I never touched is still one I can interrogate. Making one agent the only writer is how the store stays consistent instead of drifting the way anything edited by a dozen hands eventually does. The shape of the whole thing is a hybrid I did not invent. It borrows the actionability instinct from Tiago Forte’s PARA, the atomic-note discipline from the Zettelkasten tradition, and the idea of navigational hub notes, Maps of Content, from the Obsidian community. I am not dogmatic about any of them. I took the one useful idea out of each and left the rest. The store sorts into about ten types, and two of them hold the substance. Notes are atomic concepts, one idea to a note, and it is by far the largest room: the actual thinking, stripped to a claim and its links. Sources are what I have read, distilled to the few lines that earned their place, never the whole document. Everything else exists to keep those two findable and honest. A second cluster is machinery. Atlas holds the maps, both the ones that group related notes and the per-world routing tables I come back to below. Protocols are reproducible methods, so an agent runs a workflow the way it worked last time instead of improvising it again, each run logging what it found. Surfaces are one note per tool, how to reach it and what it is good for, so an agent gets a little better at using a thing every time it touches it. Templates are the scaffolds a new note is stamped from. The last cluster is the world the store serves: who is who in people, what is active in projects, what is due in reminders, the one room that reaches back out to me. Writing holds the drafts and the published record, the pipeline this essay itself came through. Holding it together are two things that are not note folders at all: a written constitution the sole writer checks every note against, and a small validator that runs on each change and refuses to commit anything that breaks the schema. The hardest habit is refusing to write most of what I could, because a store that accepts everything is worth nothing. Every candidate note has to clear one of two bars, and if it clears neither, it does not get written. The first is durability: will this still be true and useful in six months? Decisions, hard-won lessons, standing facts about how a system behaves. The second is a content bar: is this raw material for something I will publish? A vivid framing, an opinion, an anecdote worth keeping in its own words. Almost everything that happens in a working day clears neither. The status of a task, a number that will be stale next week, a detail I can re-derive in ten seconds. That goes nowhere, on purpose. When something does clear the bar, I store the lesson, not the transcript. The temptation is to save the whole PDF, the full thread, the entire session log, because storage is free and deleting feels like losing something. But an agent does not want to read a forty-page paper to answer a question. It wants the three sentences that paper taught me. Don’t store big assets, store very small snippets, the smaller the better. You are building a Wikipedia at your own level, where each entry is short, dense, and links out to the others. Knowing a fact is stored somewhere is useless if the agent cannot find it. So above the notes sits a thin routing layer. I keep a handful of these routing layers, one for each world I operate in: my work, my family’s restaurant, my personal projects. Each is a [[retrieval map::a routing table that sends a question of a given shape to the surface that answers it, and tells the agent how to reach it]]. A map does not hold knowledge. It holds directions. It says, for a question of this shape, the answer lives on this [[surface::a place data actually lives and an agent can reach: a warehouse, a tool’s API, a folder of notes]], and here is how to get to it. Before an agent goes mining for anything, it reads the map first. Step zero, every time. When I ask a question the way I actually phrase it, the map resolves it the way a search engine resolves a fuzzy query, into the specific place the answer lives and the specific way to get it. It teaches an agent to navigate my world the way a new hire learns where things are kept, except it only has to be taught once. One caution I take seriously: a map like this is an attack map if it leaks, a directory of everything valuable and where to find it, so it holds the names of things and never the keys to them. Credentials live in the environment, never in a note. A store that only a human maintains decays at the speed the human gets busy. Mine maintains itself. The mechanism is a loop I think of as [[dreaming::a scheduled pass where the machine reflects on finished sessions and consolidates what it learned into memory, without me in the loop]]. Every session, when it ends, gets reflected on: what was learned, what tripped the agent up, what should have been written down. Those reflections queue up. Once a week, on a schedule, a job reads back across the queue and consolidates: it proposes new notes, updates to existing ones, connections I missed. It never writes to the store on its own. It hands me a short list of proposed changes with the evidence for each, and I approve or cut. Most weeks it is a handful of lines. The work happens while I am asleep or doing something else, and the residue of a week of sessions becomes memory without my sitting down to file it. The sharpest lesson about the store came from turning this machinery on the store itself. I had a hunch the graph was getting tangled, so I sent a fleet of read-only agents in to audit it, each mapping a different corner. I expected them to tell me my central hub notes were overloaded. They came back and told me I was wrong. The hubs were healthy. The real problem was over a hundred orphan notes with no links in or out, scattered across a dozen little islands, invisible to any agent trying to traverse the graph. I had been maintaining the wrong thing. The audit rewrote my sense of what “healthy” meant here, and it did it by refusing to confirm the problem I brought to it. That is the same discipline from the first essay, verification in a fresh context, pointed at knowledge instead of code. I run it against the store on a cadence now, the same way I run it on anything I am about to trust. Running a personal life and a work life through the same tools is a data-mixing accident waiting to happen. Two separations keep it from happening. The first is account-level. I run two separate accounts, one personal and one for work, sharing the same skills and conventions through symlinks so I maintain a single copy of how I work while the data never crosses. Personal knowledge goes in my own store; anything that belongs to work stays in a work-controlled system. The second is where the store lives. It is a plain versioned repository whose only remote is my own cloud storage. That is partly trust and partly practical: my data is available from any machine I sign into, and it is not one company’s outage or policy change away from being locked or lost. Underneath it, a guard I cannot talk my way past refuses to write anything shaped like a secret or personal data into the store, no matter which account or agent is asking. The convenience of an agent that can write to my memory is exactly why the floor under it has to be mechanical. The question I have gotten most from people watching this is whether leaning on an external brain stops you from internalizing anything yourself. I understand the worry, and I think it has the causality backwards. The store does not do my thinking. I still run the interviews, ask the questions a model cannot invent, form the opinions. What changes is that I stop losing the output. The brain holds the little ledgers so I do not have to keep them in my head, which frees me to do the part only I can do, and then it hands them back when I need them. The best version of this is using it as a sparring partner: point a model at my recent thinking on some decision and tell it to argue with me. What am I missing, what did I sequence wrong, what would someone sharp and skeptical say. It is a better brainstorming partner than a blank page precisely because it remembers what I already believe. It is a second brain for me, not only for the agents. My own memory runs in tiers: a working memory that holds a few things at once, a short-term memory that holds the day, a long-term memory that keeps what survives. The store stands in for all three and holds far more than any of them, which quietly moves the bottleneck. The faculty left doing the real work, and running faster for it, is processing speed: how quickly I can reason over what the store puts in front of me. I stop being rate-limited by what I can hold in my head, and start being limited only by how fast I can think about it. None of this is a product I bought, and there is no configuration to copy. You build it the way that helps you, and the one rule that does not bend is to keep it honest, because a store you have quietly stopped trusting is worse than no store at all. That is the second of the three layers. A second brain that remembers across sessions. Next, the harness that puts that memory to work, running real work unattended while I do something else.
