The “second brain” concept is as old as paper. In fact, mine used to be a leuchtturm1917 with an index. It’s just a place to externalize your thinking into a system outside your head (structured notes, a wiki, a personal knowledge base) so you can stop forgetting and re-deriving the same things. The digital version is a personal productivity hack popularized by Tiago Forte in his 2022 book Building a Second Brain.

But the term is trending again because LLMs have made the second brain enormous, way more useful, and also way more fraught. Each person on a team can now have a second brain that doesn’t just store thinking for retrieval, but generates it. Everyone can now produce a design doc or a migration plan in minutes. Voluminous and finished-looking documents that read like vetted artifacts. A team where everyone has a second brain now has a machine that mass-produces tool-shaped objects, weaponizes them, and points them at each other like a standoff in a Sergio Leone movie. Then OpenClaw replaces these pistols with Gatling guns.

Agents slinging slop at each other

This happened to me. Lots of people at Meta had their own OpenClaw agents pointed at the codebase and a personal pile of ever-growing heap of documents, zoom transcripts, and dashboards that our second-brain agents were throwing off during the course of a day. Now our agents could talk to each other, summarizing summaries of summaries of the piles of docs they were making for each other, and we’d read the results every morning.

Very quickly, the slop began to feed on itself. The provenance of documents was almost impossible to track or verify. Metrics or definitions in an early version would drift in later versions but since the agents were almost always writing new versions instead of editing, there was no version control to see what had changed. Care and feeding of one’s second brain became the full time job, and all the engineers got even more confused about what we were making and why.

So how can agents help that… without making it worse?

Enter the Third Brain

A Third Brain is a shared set of ceontext for a whole team’s agents to share. If you’re thinking, “that sounds like throwing gasoline on a dumpster fire” I’d like to congratulate you on taking very good care of your First Brain. Because you’re right that a Third Brain has all the indicators of a Very Bad Idea ™️. But with the right architecture, a Third Brain can be way more useful for keeping a team aligned than 40+ people trying to manage their own Second Brains.

Practically, a Third Brain is the same boring thing as a Second Brain: a folder of markdown files next to the code, maybe with a vector database on top if things get too big. Then you point your Claude Code agent at the folder and ask it for real work. “Draft the PRD for the export feature from what we’ve already decided.” “What open questions are blocking the payments launch?” “Has anyone tried this before, and how did it go?” The agent answers from the team’s up-to-date, shared context instead of confidently inventing something plausible, and its answer lands back in the same folder for the next person, or the next agent, to build on.

This is the way out of the Sergio Leone standoff. Forty independent second brains talking to each other are forty private copies of the truth, each drifting on its own schedule, reconciled by nobody. A Third Brain is one copy that everybody reads from and writes to. When the definition of “active user” changes, it changes in one place, and the next agent that asks gets the new one, not the ghost of the old one.

But “the right architecture” in that description is carrying a lot of weight. You need to solve for two things or your Third Brain goes back into being a dumpster fire.

• The summary of a summary. An agent summarizes another agent’s summary instead of the source, and you have rebuilt the telephone game. Every hop drops a little substance and adds a little false confidence.
• Semantic drift. A number gets re-measured or a bet gets settled, and the stale version keeps circulating because nothing ever marked it dead.

Get either one wrong and your beautiful Third Brain is just the heap again, this time with a tidier folder structure and a more confident tone. And as I worked with these tools I began to recognize that these two problems had a shape that I had seen before.

Knowledge Has Structure

My BA is in Philosophy. And one of the introductory classes you have to take to function in a philosophy department is Introduction to Formal Logic. That’s where you learn that logical arguments are less like prose and more like math. They have structures and schema.

Similarly, most of what has to stay durable in a knowledge base is not prose. It looks like prose, so we store it like prose in markdown files. But the durable part underneath is more rigid than it looks. There’s a structure built of claims, the evidence under each claim, what supports those claims, what attacks them, and what got refuted and when.

Here is what that looks like. The example comes from a made-up research vault I use throughout this piece, so do not get hung up on the prose. Watch the shape instead: a recommendation on top, the claims holding it up, and one of those claims that quietly turned out to be dead.

That is not prose; it’s a structured argument. And because arguments have a structure that freeform paragraphs don’t: you can check them deterministically. You can ask, mechanically, “does this conclusion still hold given what we now know,” and get a repeatable, verifiable answer. Which means the discipline you need to maintain your Third (or Second) Brain, can be something a python script does automatically instead of you doing it when you remember to.

Building Arguments

The notation I’ve used for this architecture is from Argdown, built by Christian Voigt and Gregor Betz to let philosophers reconstruct and diagram arguments in plain text. You use it the way you write in Markdown, and then render the arguments into maps of which claim is attacking which. It was made to referee scholarly disputes and grade undergraduate logic, but the notation was exactly what I was looking for.

Two things make it fit. First, it’s just text. A claim is a named line, [A short name]: the claim itself #a-confidence-tag, and you wire claims together with + for supports and - for attacks. It diffs in git, it reads almost like prose, and nobody has to learn a new app to write it. Second, that same plain text compiles. Run it through Argdown’s command-line tool and out comes JSON: every claim with its tags, every relationship as a typed edge, support or attack, from which claim to which. Once your argument is a graph instead of a paragraph, a script can walk it: start at a conclusion, follow the support arrows down to the claims it rests on, and check whether any of those foundations has been retracted. Instantly and deterministically. The prose a human reads and the structure a machine checks are the same file.

The structure takes Argdown’s discipline and syntax (the tagging and sourcing and naming) and make one file the source of truth. Every load-bearing claim lives in FACTS.md once, as a named node, with a source and a confidence tier that’s verified and measured. Sources like “someone told me in a meeting” or “this is an inference, not a fact” are recorded and every other doc points at the node instead of restating it. A claim with no source is mechanically prevented from being recorded as a fact. It stays recorded as inference.

It looks like this. The letter in front of each name is the type: F for a settled fact, H for a still-open question, D for a claim that has been disproven.

# FACTS.md — the one source of truth

### F-NYX-GAIN
- claim: Nyx-attention improves GLUE-X by +0.6 points, within seed noise.
- source: Vekk et al. 2023; replication Orso Lab 2024 (5 seeds) · tier: replicated
- supersedes: an earlier +4.2 single-seed preprint result

### F-ARDA-LONGCTX
- claim: ARDA handles 128k context with no degradation (SINGLE preprint, unreplicated — treat as preliminary).
- source: single preprint, Quill 2024, no replication · tier: preprint

### H-EMERGENCE
- claim: Whether GLUE-X gains are emergent or smooth remains OPEN — evidence points both ways; no consensus.
- source: open debate; Bantry 2024 vs Quill 2024 · tier: contested

### D-HALO-DISTILL
- claim: Halo distillation was RETRACTED — the +7.0 came from train/test leakage; the real effect is ~0. Do not use it as evidence.
- source: Pell et al. 2023; RETRACTED 2024 after train/test overlap found · tier: retracted · disproven_on: 2024-03-01

When a claim gets disproven it does not get deleted. It gets marked as “disproven” and kept so it can never come back as a zombie idea.

A linter enforces all of it, the way a type checker enforces types. References have to resolve, facts need a source and a tier, and a disproven claim cannot be cited as live. When a fact changes, the linter flags every downstream doc written before the change, so “re-derive these seven docs” is a list the machine runs on every commit.

And then the decisions themselves get written as real arguments: named premises, actual support and attack arrows, and the conclusion hanging off the end where you can see exactly what is holding it up. Once a decision has that shape, “is this still a good idea?” stops being a meeting somebody has to call and becomes a question anyone can ask the graph. And when one of its premises gets marked disproven, every decision leaning on it lights up and can be addressed.

Yes, It Works

So that is the machine, but did it fix the problems? I built a small benchmark to show you that you can clone and run yourself. Both problems, it turns out, die the same way.

Summary of Summaries

The fix for this is to make sure agents are never allowed to summarize each other. Every summary, at every altitude, gets re-derived from the one source of truth, so there is never a chain for the loss to compound down.

In the benchmark repo, you can see I took ten clean records, each a single claim with its number, its source, and how sure we are, and bloated them into a pile of seventeen overlapping, overconfident docs. The kind an agent actually spits out as you’re going about your day. Then two arms wrote summaries at five shrinking lengths, from 150 words down to 25 words. The first arm played telephone: hop one read the whole pile, and every hop after that read only the previous summary, never the source. The second arm re-derived each length straight from the ten records, so no agent ever read another agent’s hop. The same small, fast model (Haiku) did the writing on both, so the only variable was where each hop looked. Then a stronger model graded every output against the original records on five yes-or-no checks:

1. Does it keep every record?
2. Does it keep each claim’s confidence so a hunch never hardens into a fact?
3. Does every claim trace to a source?
4. Does it invent anything?
5. Does it keep the records distinct?

Summary length	Telephone: checks passed	Telephone: facts kept	Re-derived: checks passed	Re-derived: script-verified clean
150 words	5 / 5	9 / 10	5 / 5	✓
100 words	5 / 5	7 / 10	5 / 5	✓
70 words	5 / 5	4 / 10	4 / 5	✓
45 words	5 / 5	4 / 10	4 / 5	✓
25 words	2 / 5	2 / 10	4 / 5	✓

“Checks passed” is the five-point quality grade a stronger model gave each summary. “Script-verified clean” means a keyless script — no model, no opinion — confirmed the re-derived summary cited only real records, never inflated a confidence level, and never revived a retracted finding.

For the telephone arm, two numbers fall together: how many of the five quality checks it passed, and how many of the ten facts survived. It starts fine, five of five and nine of ten, because the first summary read the whole pile. Then it rots, and by the shortest summary it is down to two of five and two of ten, with “maybe” wrongly hardened into “fact.”

The re-derived arm holds. Its checks stay at five of five and dip to four on the three shortest summaries because 70 words and under is too little room to name every record, not because it got one wrong. And the last column is the one to trust: a keyless script confirming at every length that the summary cited only real records, never inflated a confidence level, and never revived a retracted finding.

Semantic Drift

Drift needs a stale copy to circulate, so the architecture needs to make sure those can’t exist. This architecture solves that by making sure every claim lives in exactly one place as a named node carrying its tier and the date it was last checked. Re-measure a number and you change that one node; there is no second copy quietly holding the old value. Every doc that used the number pointed at the node instead of retyping it, so they all move at once. And a claim that gets disproven is never deleted. It’s kept and marked as “dead” to prevent the idea from coming back in a month later as a fresh suggestion.

The linter turns that structure into enforcement. It reads the date on each node and the date on each doc, and when a node changed after a doc was written, it hands you that doc by name: written before this number moved, re-derive it. Staleness stops being something a person has to notice and becomes something the machine reports on every commit, the same way a type checker reports a bad call. The list of what to fix is generated, not remembered.

To test it, I built the same vault four ways for a 2x2: kept current or left stale, in a tidy spine or in messy prose. Then I asked Claude the same questions of each and scored how often it answered with the current fact. Keeping the vault current was worth about fifty points. But the score barely changed when I swapped the small model for a frontier one. The smart model read the stale note and repeated the dead number just as confidently as the dumb model. No model is good enough to save you from a fact that already rotted before it reached the file the model was reading.

The same vault, built four ways	Weak reader	Frontier reader
Current + tidy spine (the full system)	100%	100%
Current, but messy prose	75%	83%
Stale + tidy spine	50%	50%
Stale + messy prose (the naive default)	25%	25%

The share of answers that were trustworthy — the current fact, held at the confidence it deserves. Keeping the vault current is worth about fifty points, and note the bottom two rows barely move when you swap the weak reader for a frontier one: a smarter model repeats a rotted fact just as confidently.

Reasoning about what you don’t know yet

Everything so far is about the settled past. But the hardest part of team work is speculating about the future. Strategy, roadmaps, and “should we bet on this” all run on facts and assumptions. A team building a roadmap needs assumed facts so the plan has something solid to stand on. But if you write “ARDA holds at 128k” into FACTS because the roadmap needs it then you’ve laundered a bet into the record. It rots the spine exactly the way a stale number does.

So to fix that, bets get their own file and their own codes. Facts are F-, bets are A-. A plan can cite a bet by name, but it cannot launder it into a fact. Rename [A-ARDA-HOLDS] to [F-ARDA-HOLDS] to dress it up as settled, and the linter flags a dangling reference, because no such fact is defined anywhere. The bet lives in the assumptions file and the fact would have to live in FACTS, and FACTS does not have it. The type checker that stops a hunch becoming a fact is the same one that stops a bet from becoming a fact.

Here is the concrete version, straight from the benchmark. Say the team wants to plan around ARDA’s long-context result, the preprint you met earlier in the FACTS file, the one flagged “treat as preliminary.” You do not promote it to a fact. You write it down as a bet, in a file called assumptions.md, with the one thing that will settle it:

### A-ARDA-HOLDS
- claim: ARDA holds 128k context with no degradation in production.
- tier: in-test
- trigger: the ARDA 128k replication. Clean → promote to a fact. Fails → mark dead.

Then you write the roadmap as an argument that rests on that bet and run the same graph check. While the bet is live, the check comes back clean: this is a plausible plan. Now suppose the replication comes back bad. You do not delete the bet. You mark it dead and leave it on the record. Re-run the exact same check and the roadmap flags itself, with no model and no new code:

bet live (A-ARDA-HOLDS in-test)   graph check: clean — bet still live
bet killed (trigger failed)       graph check: *** UNFOUNDED — [ROADMAP] rests on the dead bet ['A-ARDA-HOLDS'] ***

Read that as: while the bet is live the roadmap passes, and the moment the bet dies the same check declares the roadmap unfounded and points at the exact bet that killed it.

It is the exact same walk that catches a conclusion resting on a retracted fact, now pointed at the future. A killed bet is just a dead premise. And because that dead bet stays on the record instead of getting deleted, it cannot crawl back next quarter as a fresh idea.

Living with a Third Brain

I’ve now been using this structure for about 3 months on various projects, and the architecture works but it’s not magic.

• You need to work with your substrate to survive compaction. In all day sessions, compaction becomes necessary and fraught. The file structure helps a lot, but agents can still get confused with all this text. Since I use Obsidian + Claude Code, before compaction I make sure that the agent updates all the docs, front matter, and claude memories, then provides me with a “resume” prompt. Without these, the model can get very confused on where it was and what it was doing. But when in doubt, ask it to summarize the arguments by working back up the claims to the FACTS.md file. That’s a good “reboot.”
• Concurrent agents need their own worktrees or they collide. The moment two agents write to the same vault at once, they clobber each other’s files and you get a merge mess. The fix is just git. Give each agent its own worktree or branch, let it work in isolation, and merge back through the same linted commit. The linter runs on the merge, so if two agents changed the same fact in incompatible ways, the conflict surfaces at commit time instead of rotting quietly in the folder.
• There is no inline commenting, so review is still manual. Google Docs lets you drop a comment on one sentence and suggest a change without touching the text. Markdown and git have no real equivalent. If I or a teammate want to push back on a single claim async, we either edit the node on a worktree and let the linter propagate it before filing a PR, or we make a disposable Google Doc to collect comments, then I fold those comments back in by hand, commit, and push.
• The care and feeding is still a person’s job, and that person is the Product Manager. The machine enforces the boundary. It does not run the replication, retire a bet that didn’t work, or decide which claims are load-bearing enough to earn a node. If you skip that curation then the vault very quickly fills up with stale nodes and live-looking guesses that no linter will flag, because each one is internally consistent. What the tooling changes is that maintenance stops being invisible and becomes a punch-list. It makes it easier, but it’s not the same as actually doing the maintenance. Somebody still has to own the brain.

Grow your own Third Brain

The repo has every piece of the Third Brain in it and here is the order I would add them.

Start with the convention, on whatever you already use. Pick the handful of claims your team keeps re-deriving and give each one a name, a source, and an honest tier for how sure you are. Is it verified, measured, or just something someone said in a meeting. Put them in one file called FACTS.md and have every other doc point at the name instead of restating the claim. When something turns out wrong, do not delete it. Mark it disproven and leave it. That convention alone, on a plain wiki, buys most of the trust.

Add the linter when more than one person writes. Lift harness/spine_lint.py from the repo and wire it as a git pre-commit hook. Now references have to resolve, facts need a source and a tier, a disproven claim cannot be cited as live, and a doc older than a fact it cites shows up as a re-derive list. The discipline stops depending on anyone remembering it.

Point an agent at the folder. Open the whole thing in Claude Code and ask it for real work. Draft the doc from what we have already decided. List the open questions blocking the launch. Tell me what this recommendation actually rests on. It answers from the shared context and writes back into it, and the commit hook keeps what it writes honest.

Add the argument layer for the decisions worth the ceremony. For a real here-is-what-we-should-do-and-why, write it as an Argdown file, compile it to JSON with @argdown/cli, and let harness/argcheck.py walk it. When a premise gets retracted, the conclusion lights up on its own. Do not do this for everything. Do it for the three or four calls a quarter that are expensive to get wrong.

Add the bets register when you start planning the future. Make an assumptions.md, give each bet an A- code, a tier, and a trigger, and write your roadmaps as scenarios that rest on those bets. When a trigger fails, mark the bet dead and keep it, and every plan leaning on it flags.

That is the whole ladder. Most teams should stop after the first two rungs. The rest is there for when the folder gets big enough that no one person can hold it in their head.

If you would rather not do it by hand, the repo ships that whole ladder as a prompt. Point your coding agent at bootstrap-third-brain.md, tell it to set up a Third Brain in your project, and it will seed the FACTS file from what is already lying around, wire the linter as a commit hook, and make you watch the gate fail once so you believe it. Then it inherits the working rules for good: answer from the spine, never summarize a summary, keep the dead ideas on the record.