The Science · Shared Notebook

The shared
notebook.

Why a vault of notes is enough for one mind, and breaks for many. This paper is partly a concession, which is the only honest way to start.

Working paper. This is a reasoned position, not a benchmark result. It concedes the single-mind case to the notebook outright, and states the runtime’s unfinished parts plainly.

There is a genuinely good idea going around. Keep your AI’s memory in a folder of markdown files. An Obsidian vault, or a CLAUDE.md and a /notes directory, that the model reads at the start of a session and writes back to at the end. It is transparent. It is yours. It survives the tool. You can open it, read it, fix it, grep it, put it in git. After a few years of opaque “memory” features that you could neither see nor correct, a plain folder of notes feels like sanity.

It mostly is.

1. The concession

For a single person, a well-kept vault of notes plus a small amount of glue is enough. Not “enough for now,” not “enough until you grow.” Enough.

If one human wants an assistant that remembers their preferences, their projects, the decisions they have made and the ones they have reversed, then a git-synced vault, a session-end step that distills what was learned, and a retrieval step that pulls the relevant notes back in covers the need. Sync is solved by git, the most battle-tested merge system ever built, and a single person rarely has two hands writing at once anyway. Recall is solved by reading files. Cost is near zero. Lock-in is zero. You can audit every byte.

We have built a cognitive runtime, and we will still tell you: at that scope, the runtime is over-built. If your honest situation is one person and a pile of notes, build the pile of notes.

So this is not an argument that notes are weak. It is an argument about the exact point where they stop being enough, and why that point is not where most people think it is.

2. What notes can actually do

First, clear away a bad argument, because we have made it ourselves and it is wrong.

It is tempting to say a folder of markdown “cannot represent” the things a real memory needs: how confident you are in a claim, how fast it should fade, who is allowed to know it, what it contradicts. That is false. Markdown front-matter holds structured fields perfectly well:

claim: "prefers async communication"
confidence: 0.7
decay_rate: slow
audience: [work-agents]
supersedes: note-2026-03-11

A note can carry confidence, a decay rate, an audience tag, a pointer to the claim it overrides. Representation is not the gap. Anyone who tells you files are too dumb to hold belief-state has not looked.

The gap, when there is one, is not what a note can say. It is what a pile of notes can do when more than one mind is involved.

3. How an agent actually reads a vault

It helps to be precise about the mechanism, because there is no magic in it.

A coding agent does not embed your whole vault and it does not pour the whole vault into the prompt. It loads one small always-on index at the start of a session, the file that says “here is who you are and where things live,” and then, when it needs a detail, it goes and reads the specific note, the way a developer greps a codebase. A small routing table in context; the bodies fetched on demand.

This is why the index has a hard size limit and the notes behind it do not. It is also why retrieval quality depends on two fragile things: whether the index points at the right note, and whether the agent guessed the right words to search. It is lexical, not semantic. It is good when names are stable and weaker when the thing you need is a half-remembered idea with no obvious keyword.

None of this breaks for one person. Keep reading.

4. Where the notebook breaks: many minds, one room

A previous paper in this series, Two minds, one room, framed a conversation as two minds in one room: both sides have state, both reason, both choose what to disclose. Hold that image, because it is exactly where a shared notebook fails.

A vault has one author’s-eye view. There is the note, and there is what the note says. But once there is more than one mind, the same claim has to be held differently by each of them:

  • You believe a project is “self-serve.” Your finance agent, having watched the numbers, holds the same claim at low confidence. Your support agent, having watched customers, believes the opposite. One claim, three stances.
  • A thing you told your lawyer is true, and must not surface when your marketing agent is in the room. The belief is real; its audience is scoped.
  • Your research agent concluded X in one tool; you said not-X in another. Someone has to notice the two are in tension, across the minds that hold them.

A folder of notes has no clean way to do this. You are forced into one of two bad moves. Either you copy the claim into every mind’s notes, and now you have five slightly-diverging copies of one fact and no integrity between them. Or you start building, inside your files, a table of canonical claims and a separate table of who-believes-what-about-each, with edges for who-may-see-what and what-contradicts-what. The second move is the honest one. It is also the moment you stop having a notebook and start hand-building a database, badly, with a text editor.

That table, one shared claim, many minds each evaluating it, with audience scope and cross-mind contradiction, is what we call a Mind. The reason it is a runtime and not a file format is not storage. It is that the interesting questions are queries across identities: what do I believe that you do not, who is allowed to know this, where do two of my agents disagree. Those are joins, not greps.

One honest qualification, because the argument has two halves and only one of them is on firm empirical ground today. The audience-scope half holds: scoped, divergent stances and “do not surface X when Y is in the room” are real workloads files handle badly, and that is what this section is really about. The co-holding half, the picture of many minds holding the same claim at different confidences ready to be joined, is empirically thin right now. When we measured it, cross-mind proposition co-holding ran at roughly 0.2%: the same canonical claim being independently held by more than one mind is, in practice, rare. So the “joins not greps” framing is the right shape of the problem, but most of the value today comes from scope and contradiction, not from a dense web of shared claims. We state that rather than imply a richness that is not there yet.

5. The line that actually matters

Notice what the breaking point was not. It was not the number of machines. It was not the number of tools. A single person syncing notes across a laptop, a desktop, and three different AI tools is still one mind; git and a shared retrieval endpoint handle that, and we will not pretend otherwise.

The line is identity-multiplicity and audience scope. The notebook is enough right up until the moment that multiple identities, you, and the agents that work for you, and eventually other people and their agents, need to hold divergent, scoped, sometimes-contradictory beliefs about the same things, and need to reason over those differences. That is the workload files cannot carry without becoming a database in disguise. Everything below that line, the notebook wins on cost, transparency, and freedom.

This is a narrower claim than “you need a cognitive runtime.” It is narrower on purpose. The wide version invites a fair rebuttal, that a synced vault and a hundred lines of retrieval code cover most of this, and the wide version loses that argument on the parts (sync, single-user recall) that are genuinely matchable. The narrow version is the one that holds.

6. What it trades

Honesty requires the other column of the ledger.

Extraction is everyone’s problem, not the Mind’s alone. The belief-state a Mind holds, the confidences, the saliences, the supersessions, has to be filled in somehow. Either a person maintains it by hand, which no one sustains, or a model distills it from conversation. That distillation is hard, and a confidently-wrong structured belief is worse than a missing note, because the structure makes the error look authoritative. But a notebook that carries the same belief-state fields pays the exact same tax, done per-tool, with no central place to fix it. So this is not a cost the Mind pays and the vault escapes. It is a cost they share; the Mind at least centralizes it.

The runtime has real costs the notebook does not. It puts a network dependency in the read path: when the service is unreachable, the session has no Mind, while a local file is always there. It has a worse cold start, because a Mind compounds and day one is thin. And the very thing that justifies it, audience-scoped disclosure across identities, is the part still being hardened, not the part already finished. A capability that is the whole point and is not yet complete is a liability you state plainly, not a feature you sell. In progress · Phase 2

We are not claiming a win on a benchmark. We have not yet run the eval that would settle it: the Mind against a serious, git-synced, extraction-backed vault, scored on real task outcomes. Until that exists, treat this paper as a reasoned position, not a result.

7. The end state is not either / or

The right architecture keeps both layers, and most arguments about “files versus a system” miss that.

Keep the small always-on index, the CLAUDE.md, the few hundred words of “who you are and how to behave.” It is genuinely valuable and a runtime should not throw it away. Put the deep store behind a single retrieval call. For one mind, that deep store can be a folder and a script, and that is the right call. The deep store earns its way to being a shared, queryable, identity-aware runtime precisely when it has to serve many minds with scope, not merely when it gets large, and not merely when it gets centralized.

Since writing this, we took our own advice. thinqOS has adopted the notebook pattern internally as a complementary layer: agents now have a shared-file memory they can read and write directly, sitting alongside the runtime Mind rather than replacing it. Live That is this paper’s “keep both layers” prediction confirmed in our own product. The plain file is the right home for the always-on index and for durable notes a single agent maintains; the runtime is the right home for scoped, cross-identity belief. We did not pick one. We wired both, which is the whole point of this paper.

A notebook is the right tool for one mind in the room. When the room fills with minds, yours, your agents’, and the people you work with, the notebook does not scale into a Mind. Something else has to.

8. Read together

This paper sits beside the cognitive-runtime series and can be read on its own.

Where plain notes are genuinely enough, use them. The one line past which they are not is identity-multiplicity and audience scope. Below it, the notebook wins. Above it, something else has to.

Read Paper 3: Two minds, one room →Request access