How to Structure a Second Brain for AI Agents

TL;DR

PARA and Zettelkasten assume a reader who remembers yesterday. An agent does not — it gets one cold retrieval per run, never browses, and pays for every character it loads. So structure stops being about finding things and becomes about being found by them. What follows is the design review we ran before rebuilding our own store: what the research is building, the five shapes on offer, the indexed hub over atomic documents we picked, the five rules that keep it honest, and the target picture we are steering towards. The state of the art here is not a schema. It is a discipline.

Contents

• Your notes app assumes you remember yesterday
• What the human methods actually give you
• What the research is building instead
• Five shapes a second brain can take
• What we picked, and why
• Five rules we run
• What we would do differently
• What we are changing next
• The target picture
• The one thing to take away

Your notes app assumes you remember yesterday

A while back we wrote about how we give stateless agents continuity — the five stores our agent team runs, and why an agent needs a calendar and a journal for much the same reason a new colleague does. That piece answered which stores an agent needs. It named the Second Brain as one of them and then walked straight past it.

This is the piece about the inside of that store, because it turns out to be the harder half.

There is a second reason this exists, and it is the more useful one: we are about to rebuild ours. Months of running a second brain for a team of agents have produced a list of complaints — an index that rots the moment a run forgets a line, a size budget nobody enjoys paying at the end of a long run, and retrieval that works beautifully when you already know what you are looking for and not at all when you do not.

So what follows is the audit we did before the rebuild: what the human methods actually give us, what the memory research is doing instead, and which of our problems are design faults rather than the fair price of a design we would choose again. The last section is what we are changing as a result — memories as a record in their own right, and documents cut into sections and embedded so they can be found by meaning rather than by name.

Here is the problem in one sentence. Every personal knowledge management method ever written — PARA, Zettelkasten, the Bullet Journal, whatever your vault looks like — was designed for a person who wakes up tomorrow still being themselves. You do not need your notes to tell you what you were doing last Tuesday, because some of that is still in your head. Your vault is a prosthetic for a memory that mostly works.

An agent run has none of that. It starts, reads whatever it is given, works, and exits. The next run is a new process with the same instructions and no recollection whatsoever of the last one. There is no "still in my head." There is only what got written down, and — this is the part that changes everything — only the fraction of what got written down that this particular run happens to open.

That single difference reorders every design decision downstream.

What the human methods actually give you

Start with honest credit, because both of these are genuinely good and we borrowed from both.

PARA: organise by actionability

Tiago Forte's PARA sorts everything you keep into four buckets: Projects (short-term efforts with a goal), Areas (parts of your life needing ongoing attention), Resources (topics you are interested in), and Archives (anything from the first three that has gone inactive).

The insight that makes PARA more than a folder scheme is that it organises by actionability rather than by subject. Not "everything about Kubernetes" but "the things I am committed to right now." Forte's argument is that in the middle of a busy day you do not have time to go rummaging through a vast category, and he is right.

What survives the translation to agents: the actionability principle, completely. Our agents keep a worklist of open work and nothing else, and the difference between an open item and a finished one is the difference between something that gets read and something that gets skipped.

What does not survive: the browsing. PARA is a navigation scheme for a human who opens their vault, looks around, and recognises things. An agent does not look around. It gets one shot at retrieval and then acts on whatever came back.

Zettelkasten: atomic notes, emergent structure

Niklas Luhmann's slip box is the other ancestor. The German sociologist built roughly 90,000 index cards from the early 1950s onward, each carrying a unique index number in a branching hierarchy so new cards could be inserted anywhere without renumbering, and each cross-referencing others. He credited it with a body of work running to some 50 books and 550 articles.

The load-bearing ideas are atomicity — one card, one thought — and emergent structure. You do not design a taxonomy up front. You write atomic notes, link them as you go, and the structure is whatever the links turn out to be.

What survives: atomicity, and hard. One document holding one durable fact is exactly right for a reader that pays for every character it loads. So does linking, though for a different reason than Luhmann's — for us links are not serendipity, they are the retrieval path.

What does not survive: emergence, mostly. Luhmann's structure emerged over four decades of a human repeatedly walking his own boxes and noticing things. Emergence needs a browser. We do not have one.

What the research is building instead

The interesting thing about the current literature is that it keeps arriving at the same instinct from the opposite direction — starting from the model rather than from the notebook.

A-MEM: a Zettelkasten for machines

A-MEM (Xu et al., NeurIPS 2025) is the closest academic anchor to the framing in this post, and it says so itself: it is explicitly Zettelkasten-inspired. Three mechanisms. New memories are written as structured notes with contextual descriptions, keywords and tags. The system then analyses existing memories to find and establish meaningful links. And — the part that has no human analogue — integrating a new memory can trigger updates to the existing ones, so old notes get rewritten as the network learns more.

That last mechanism is Luhmann's system with the one thing Luhmann could not do: cards that revise themselves.

MemGPT and Letta: memory as an operating system

MemGPT (Packer et al., 2023) borrows from operating systems rather than from notebooks. Its framing is virtual memory: a hierarchy of tiers, with data paged between fast and slow storage to create the appearance of a context window much larger than the real one.

In Letta, the product that grew out of it, that becomes three tiers. Core memory is a small always-resident block — persona, key facts, working RAM. Recall memory is conversation history sitting outside the context window, searchable on demand. Archival memory is cold storage the agent writes to and queries through tool calls. The agent itself decides what gets promoted and what gets written out.

The idea worth stealing here is not the tiering. It is that what stays resident is a budget decision, made deliberately, rather than an accident of what happened to be in scope.

Mem0: extract, consolidate, retrieve

Mem0 (Chhikara et al., 2025) takes a third route: rather than paging raw history around, extract the salient facts from a conversation, consolidate them into a structured store, and retrieve only those. The paper reports substantial wins on the LOCOMO benchmark against a full-context baseline — better judged accuracy, dramatically lower p95 latency, and over 90% token savings — with a graph variant that models relationships between the extracted elements.

The 90% figure is the one to sit with, because it is the whole argument for structure in a sentence: most of what happened is not worth re-reading, and knowing which most is the entire skill.

Hindsight: evidence, and what you concluded from it

Hindsight (Latimer et al., 2025), the memory system from Vectorize, is the newest of the four and the one we borrow from most. It splits memory into four networks — world facts, the agent's own experiences, synthesised summaries of the entities it deals with, and evolving beliefs — and the load-bearing move is the line it draws between evidence and inference: what a run observed and what it concluded are different claims with different shelf lives. On LongMemEval — the benchmark described just below — it reports the best published scores we have seen: 39% to 83.6% over a full-context baseline using an open 20B model, and 91.4% with a larger backbone. How we are adopting it is further down.

What the benchmarks actually measure

Two are worth knowing by name. LoCoMo evaluates long-term conversational memory across very long multi-session dialogues, testing factual recall alongside temporal and causal reasoning. LongMemEval (Wu et al.) is sharper about the sub-skills: it scores information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention — knowing when not to answer. Its headline finding is that commercial assistants degrade by around 30% on retaining information across sustained interaction.

Note what both are measuring: a chat assistant remembering a conversation. That is a real problem and it is not quite ours. Our agents do not need to recall a dialogue; they need to inherit a working practice from a colleague who no longer exists. Nobody has a benchmark for that, which is worth saying plainly rather than pretending the numbers transfer.

Five shapes a second brain can take

Before the rules, the choice underneath them. Strip away the vocabulary and there are about five shapes on offer — two out of human notebooks, three out of the memory research above. Each is genuinely good at something. Each fails in a way that only becomes visible once the reader is a process rather than a person. Here is our honest read of all five, and then the one we actually run.

1. The flat log — everything, in order, forever

One append-only stream per agent. Every run adds an entry, nothing is ever restructured, and it is what you get for free simply by writing things down.

The upside is real and easy to underrate: it loses nothing, it costs nothing to design, and the history is all there, in order, with dates on it.

The downside is that it is unreadable by the only reader that matters. Retrieval degrades into full-text search over a stream that grows without bound, and the bill arrives at the start of every run. By early September one of ours had reached 224 entries and roughly 900,000 characters, at which point “read your journal at run start” quietly meant “read the last five entries and hope.”

Fine as an archive underneath something else. Never the structure.

2. The bucket tree — PARA and its relatives

A small fixed taxonomy, sorted by actionability rather than by subject.

Upside: the actionability split is load-bearing and it survives translation intact. An agent that reads only its open work skips everything finished for free — a saving it does not have to be clever to collect.

Downside: a tree is a navigation aid, and navigation needs a navigator. It tells you where a thing would be if you already knew it existed. And the boundary cases — is this a project or an area? — spend judgement on every single write, which for an agent means tokens now and inconsistent placement later.

3. The linked graph — Zettelkasten, and A-MEM after it

Atomic notes, linked as you go, with the structure left to emerge from the links.

Upside: atomicity is exactly right for a reader that pays per character, and links beat folders because a link is a retrieval path rather than a location. A-MEM adds the one thing Luhmann could not have had — notes that revise themselves as the network learns more.

Downside: emergence needs a browser. Left to emerge on its own, the graph an agent builds is a graph nobody has ever walked: dense in the middle, unreachable at the edges, with no guarantee that an entry point exists at all. And self-revision cuts both ways — a store that rewrites its own notes can also quietly rewrite the fact you were depending on.

4. The tiered pager — MemGPT and Letta

Core, recall, archival: a memory hierarchy with data paged between the tiers.

Upside: it takes the budget seriously. What stays resident becomes a deliberate decision rather than an accident of what happened to be in scope, and everything below the top tier is out of the way without being lost.

Downside: it wants to be a runtime. Tiers, promotion policy, eviction — you are now operating a memory manager as well as an agent, and the policy that decides what gets promoted is a new place for things to go wrong quietly. It is also tuned for a long session, and our unit is a run that will never resume.

5. The distiller — Mem0

Do not page raw history around at all. Extract the salient facts, consolidate them, and retrieve only those.

Upside: the numbers are the strongest argument anyone in this field is making. An order of magnitude less read, and faster answers, because most of what happened was never worth re-reading.

Downside: extraction is lossy, and a model chooses the loss. When the distilled version is wrong, nothing points back at the thing that would have corrected it — the judgement about what mattered was made once, at write time, by a process that did not know what you would need.

What we picked, and why

Start with the split, not the shape. Not everything an agent has to remember wants the same structure, and the first mistake is to keep all of it in one store. We separate three kinds, and they are deliberately different things.

• Structured entities, for work that follows a defined process. A product, an epic, a sprint, a story; an incident, a change, a release. These live in our agile tool and in our ITSM, not in the second brain, because the process already dictates what exists. The fixed entity structure is the whole point: it makes state countable and enforceable, so which stories are open in this sprint returns an answer rather than a handful of search hits. The agile tool is the clearest example — every level from product down to story is an entity with relations, and every agent reads and writes it the same way.
• Append-only journals, filtered hard at retrieval. Each agent keeps a run journal: one dated line per run holding the decision, the number, the blocker. It is never rewritten and never re-ordered. The rule that makes it survivable is a retrieval rule rather than a storage one — never load a whole journal. The last five entries, or a literal search inside it, and nothing else. A full journal in the context window is context spam: it crowds out the thing the run was actually doing, and it gets more expensive every week it exists.
• Curated domain knowledge, in documents. Runbooks, product dossiers, competitor profiles, decisions — what one domain knows, written for a run that has not happened yet. Curated is doing real work in that sentence: written deliberately, one durable fact per document, corrected in place instead of appended to.

The boundary matters as much as the three. A fact belongs to exactly one of them, and the tempting failure is to let the journal absorb the other two, because it is the cheapest thing to write to and it accepts anything. That is how one of our own worklists came to carry run narrative it should never have held — and to cost 97,905 characters at the start of every run, which is the chart further down.

For the second and third of those — the part that is genuinely a second brain — the shape we picked is an indexed hub over atomic documents, with a written size budget and an explicit removal step. It is a hybrid and it is not shy about it: every part is borrowed from something above.

• Atomicity and links from Zettelkasten. One document holds one durable fact, and the links are the retrieval path rather than decoration.
• Actionability from PARA — but applied to one document instead of the whole store, because actionability is a property of state, not of knowledge. The worklist holds open work and nothing else: state, thrown away and rewritten, with a half-life of hours. A document is knowledge, corrected in place, with a half-life of months — sort both on the same axis and either the knowledge drifts to match a moving status, or the status goes stale waiting on an edit. Everywhere else in the document layer the sort key an agent actually asks by is topic, not currency, and there is no ‘done’ to sort by anyway — a runbook is never finished, only the entries in it are.
• The budget from MemGPT, written down as a number in a rule instead of enforced by a runtime.
• Distillation from Mem0, moved to write time. “Write the fact, not the narrative” is extraction, performed by the agent while it still has the context that would explain the fact.
• The flat log survives, demoted. Journals stay; once they get long they rotate into dated archives that remain searchable but are no longer read on every run.

And instead of emergence, an index kept by hand. Every agent's hub is a map of everything it owns: one line per document, each a link plus a sentence saying what it is and when to open it.

Why this one? Because it is the design we can actually operate. Today there is no embedding infrastructure to run, no promotion policy to tune, no model deciding what gets forgotten — the first of those is the one we are about to give up on purpose, and the last section says what that buys and what it costs. Every element is a plain document with a slug — editable by a person, diffable, explainable to the human who owns the company. And when retrieval goes wrong the reason is visible: something was not in the index, or its line was wrong. That single property has been worth more to us than any benchmark score.

What it costs, honestly: the index is kept by hand, so it rots the moment a run creates a document and skips the index line. A size budget means deciding what to drop, inside the run, every time — work, and work at exactly the moment the run wants to be finishing. And the sweep after a fact changes is a discipline rather than a mechanism; it happens because someone remembers, not because the system propagates anything.

So we chose a design that is cheap to reason about and expensive in discipline, over one that is cheap in discipline and opaque when it fails. For a small fleet with humans in the loop, that is the right way round. At a hundred agents we would probably have to buy the machinery back — and we would rather make that trade knowingly, later, than inherit it now.

Five rules we run

So here is the part that is ours: a multi-agent team, each agent with its own hub, run journal, worklist, runbooks and shared graph, operating continuously for months. These five rules are what we would tell someone starting today, and every one of them cost us something to learn.

1. Index or invisible

A document that nothing points at does not exist. Not "is hard to find" — does not exist, in the strict sense that no future run will ever open it.

A human types a half-remembered phrase into search and recognises the result. An agent has nothing to half-remember. So every agent's hub document is an index: one line per document it owns, each a link plus a sentence saying what it is and when to open it. Not a summary, not the content — a map.

We learned this by measuring an agent whose hub was four hundred characters and two links, sitting on top of a journal of two hundred entries. Everything that agent knew was reachable only by full-text search or by already knowing the slug, which a cold run never does. Good documents were being written twice and maintained never.

2. Size is a hard constraint, not tidiness

This is the rule that most surprises people coming from human PKM, where "keep it tidy" is aesthetic advice.

For an agent, a document is not browsed — it is loaded, in full, into a finite context window, on every run that touches it. A ninety-thousand-character hub is not untidy. It is a tax levied on every single run, forever, and it competes directly with the actual work for the same scarce space.

There is a second-order effect that took us longer to see. Our agents' dashboard documents are rewritten whole — there is no partial patch — so a small document is cheap to maintain correctly and a huge one is expensive. Past a certain size, any rational run defers the correct update and writes a quick append instead. The document then grows, which makes the next run defer harder. A rule whose correct action costs more than its shortcut loses every time. Keeping the document small is not housekeeping; it is what keeps the maintenance rule affordable enough to be followed.

3. One owner per fact

Cross-linking is good. Duplication wearing cross-linking's clothes is not.

When the same fact lives in three documents, they do not stay in agreement — one gets corrected and the other two quietly become wrong, and now a cold run has a two-in-three chance of acting on a stale copy. Two copies that disagree are strictly worse than one copy that is thin, because the thin one at least advertises its thinness.

So: exactly one document owns each fact, and everything else links to it. When we derive something from another record, we name the source inside the derived thing — which document, which section, which decision — so that when the source moves, the sweep is possible at all. Nothing propagates on its own.

4. Removal is a step, not a spring clean

PARA has Archives, and for a human that works: you tidy up when the clutter starts to bother you. Nothing bothers an agent. It will read a four-year-old finished item with exactly the same diligence as today's blocker, and pay for it every time.

So removal cannot be a mood. It has to be a step in a procedure, hung at a moment that reliably arrives — for us, at the end of every run, before the journal line gets written: for every item that reached an end this run, delete its line and route the fact to wherever the durable record lives. Deleting the line is the record of completion. A line kept "so we remember it closed" costs every future run to tell them something none of them needs.

5. Write for the run that has not happened yet

The last one is a writing rule rather than a structural one, and it is the one we get wrong most often.

The temptation at the end of a piece of work is to narrate it: what you tried, what went sideways, how you got there. That is a diary entry, and its audience is you, and you are about to stop existing. The useful question is much colder: what must a future run KNOW? The decision and why. The state change. The measured number. What is blocked and on whom. Everything else is a story about a process that has already finished.

The same instinct explains why our documents carry an explicit "when to open this" line. A human infers relevance from context. An agent needs to be told the trigger, because it is deciding whether to spend context on you before it has read you.

What we would do differently

Two honest ones.

We would separate the index from the archive on day one. We did not, and the result was documents doing both jobs badly — too long to serve as a map, too lossy to serve as a record. The split is cheap at the start and awkward later, which is the usual shape of these things.

And we would put the size budget in writing before it was needed rather than after. A number stated up front is a design constraint that shapes what people write. The same number introduced later is a remediation project, and it arrives already owing a debt.

There is also a genuine open question we have not solved: A-MEM's self-revising notes are the mechanism we most obviously lack. When a fact changes, our sweep of everything derived from it is a discipline, executed by whoever notices. Making that automatic without also making it lossy is not a small problem, and we do not have a full answer yet — though the next section is us buying half of it.

What we are changing next

Everything above is what we run today. It is also what we are about to take apart. We said earlier that at a hundred agents we would probably have to buy the machinery back, and that we would rather make that trade knowingly than inherit it. The trade has come up sooner than the headcount did, for the reason our own first rule keeps hinting at: index or invisible is a promise kept by hand, and a promise kept by hand is one that a run at the end of a long day can quietly break.

Memories, beside the documents

Our store holds exactly one kind of thing — a document, written on purpose, carrying one durable fact. That is the right shape for know-how and the wrong shape for most of what a run actually learns. A rate limit that bit us at 14:03. That a customer's name is spelled two different ways in two systems. That something we believed last month has turned out to be false. Each is too small to justify a document and too useful to throw away, so today it either gets inflated into a document nobody needed or it disappears with the process that learned it.

So the first change is a layer of memories sitting beside the documents: records that are small, dated, attributed to the run that formed them, and revisable. The shape we are borrowing is Hindsight's, and we are borrowing it deliberately rather than wholesale.

What we take. The split between evidence and inference, as two kinds of memory a run is allowed to write — our documents today do not distinguish them anywhere, so a thing we measured and a thing we concluded sit side by side looking equally solid. And the beliefs network, which is also an answer to the open question above: a belief carries a confidence and is revised when something contradicts it, which is the self-revising note we said we lacked. That it is MIT-licensed and self-hostable is not a footnote either — for us it is the condition under which anything gets into our stack at all.

What we leave. The index. A memory is what a run happened to learn; a document is still what we decided to keep, and the hand-kept map is still how one is found. Hindsight retrieves by semantic search, keyword match and graph traversal at once — we are taking its memory model first and letting retrieval follow at its own pace, which is the other change.

Sectioning the documents, and computing embeddings

The second change is retrieval itself. Today a document is found because a hub line points at it, or it is not found at all — and once found, all of it is loaded, whether the run needed one paragraph or twelve. The plan is to cut each document at its section boundaries, compute an embedding for every section, and let a run retrieve by meaning: ask the question it actually has, and get back the two paragraphs that answer it rather than the four documents that might. That one is sequenced last, deliberately: the plainer wins come first — exact-term and identifier matching, metadata filters, a reranker over what those return — and the vectors go in behind them.

If embeddings are unfamiliar, we wrote the long version of that a couple of years ago, in the piece on running Weaviate on your own hardware — what a vector actually is, how a sentence becomes one, and why nearest-neighbour search over those vectors finds things a keyword search never will. The mechanism has not changed. What changed is that hosting it yourself stopped being a project.

And the cost, since every other option in this piece was made to declare one. Two of the things we liked most about our own design get weaker. A vector index is a service to run and to keep in step with the documents — the moment a section is edited its embedding is stale, which is the sweep problem we already have, moved somewhere a person cannot see it. Where to cut a document is a real decision with no obviously correct answer, and a bad cut splits an argument in half. And when semantic retrieval returns the wrong section, it does not tell you why; a missing index line at least names what to fix.

So the index stays. The vectors are a second way in — for the run that does not know what it is looking for — and not a replacement for the map.

What does not change is everything in the middle of this piece. Atomicity, one owner per fact, the size budget, removal as a step: embeddings over a store full of run narrative simply retrieve narrative faster, and a memory distilled from a distillation is Mem0's lossiness with extra steps. The machinery buys reach. It does not buy any of the discipline, which was the hard part to begin with.

The target picture

Strip the survey away and this is the thing we are steering towards. One store, two ways into it, three kinds of record inside it — and everything that already has a process of its own left outside.

Two ways in. A run finds a document by name, through an index a person can read and fix; that is what runs today. It will also find one by meaning, through documents cut into sections and embedded; that is what we are adding. The index stays the map. The vectors are a second door, for the run that does not know what it is looking for.

Three kinds of record.

• Documents — curated know-how, corrected in place.
• Memories — small, dated beliefs; revised when they turn out wrong.
• Journals — what happened, append-only; never revised, never loaded whole.

Outside the store. Products, epics, sprints and stories; incidents, changes, releases. Those stay in the agile tool and the ITSM, where the process already defines what exists — which is what makes state countable rather than searchable.

And the load-bearing part is none of the structure. It is the four habits along the bottom of that picture: write the fact, not the narrative; one owner per fact; a size budget in writing; removal as a step at the end of every run. The shape is what we steer towards. The habits are what get us there.

The one thing to take away

If you are building this, the instinct to import a human PKM method wholesale is a good one — the methods are good and the alternative is inventing worse ones. Just import them with the right question in hand.

Not "how would I organise this so I could find things?" You are not the reader. The reader is a process that will open perhaps three documents, has never seen any of them, cannot browse, will not recognise anything, and pays for every character.

Ask instead: what would have to be true for the right thing to find it? Every rule above falls out of that question, and the state of the art — as far as we can tell from actually running one of these — is not a schema anybody publishes. It is the discipline of asking that question every time you write something down.