Why an exobrain

Six ordinary moments, with and without

Same model, same prompt. The only difference is whether it has somewhere durable to read from.

You ask it to start a new piece of work

Bare agent

It branches off main. Your default is trunk.

You correct it. It apologises and gets it right for the rest of the session.

Tomorrow: main again.

With an exobrain

It branches off trunk, because your convention is a line in a file it read at startup.

You stopped noticing this months ago.

A procedure you run every week

Bare agent

You paste the same four steps into the chat, in the same order, for the fourth time this month.

The steps live in your head and nowhere else.

With an exobrain

You say “ship it.” The procedure is written down as a skill; it reads the steps and follows them.

When the procedure changes, you edit the file once.

A decision you made a month ago

Bare agent

It proposes the design you evaluated and rejected in August.

It was a reasonable suggestion — it has no way to know you’ve been here. Neither of you remembers the reason you said no.

You rebuild the argument from scratch.

With an exobrain

It reads the decision, and the reason behind it, and proposes something that accounts for both.

The afternoon you spent deciding stays spent.

You open your other laptop

Bare agent

Every path it learned is wrong. You spend the first twenty minutes re-teaching a setup you already taught.

Two machines means teaching everything twice.

With an exobrain

That machine’s scope loads, with that machine’s paths. Everything you know stays shared.

A third machine is one small file.

You want to try a different agent

Bare agent

Start over. Whatever it had learned lived in one vendor’s memory, in a format you can’t read or move.

Switching costs you everything you’d built up.

With an exobrain

Run the connector. The new agent reads the same files, and per-agent quirks sit in a sidecar.

Running two agents at once is a supported case, not a workaround.

It needs to reach an external system

Bare agent

It fumbles the authentication, then hits the obscure error that cost you an hour last year.

It costs the hour again.

With an exobrain

It reads that system’s document first — commands, credentials handling, and the failure modes you’ve already met.

The hour was spent once.

The problem is not capability

Coding agents are good. The frustration people report is almost never “it can’t write the code” — it’s that it doesn’t know anything, and it doesn’t know anything again tomorrow.

Four things go wrong, and they compound:

You re-explain the same context every session. Which package manager. Which branch is default. That the staging box is the odd one. Which of the three services owns auth. You have typed this before, probably this week.

Corrections don’t stick. You tell it the deploy script lives somewhere unusual. It thanks you, uses the right path, and has forgotten by the next session. Every correction is rented, never owned.

It guesses confidently in the gaps. An agent with no context doesn’t say “I don’t know your setup” — it assumes the common case. Usually main, usually npm, usually the conventional layout. When your world differs, you get a confident wrong answer, which is worse than a question.

Decisions evaporate. You spent an afternoon working out why the queue is configured that way. That reasoning existed in a chat window that is now gone. Six weeks later the agent proposes the thing you already rejected, and neither of you remembers why.

None of these are model problems. They’re context problems, and context is a thing you can actually own.

What changes

An exobrain gives the agent a durable place to read from and write to. In practice:

• It stops asking what it should already know, and stops guessing when it doesn’t.
• A correction becomes an edit to a file, so it holds for every future session and every agent you use.
• Decisions get written down where they’ll be re-read, not buried in a transcript.
• You can see what the agent believes, because it’s markdown, and change it by editing a line.

The last one matters more than it sounds. When an agent behaves oddly, “which line taught it that?” is answerable. That’s a debugging loop most agent setups don’t have.

Honestly, versus the alternatives

Versus a single AGENTS.md / CLAUDE.md

This is the fair objection, and for many people the honest answer is a single file is enough — use that. An exobrain is what that file grows into when it stops working, which happens for specific reasons:

	One flat file	Exobrain
Machine-specific paths	Pollute the shared file, or get left out	Live in a host scope, loaded only on that machine
Multiple people	Everyone’s preferences in one file, all loaded always	Each person’s scope loads for them
Growth	Every session pays for every rule, and the file drifts toward being ignored	Durable knowledge is indexed and read on demand
Time-bound work	Investigation notes pile up next to permanent rules	Workspaces are separate and expected to go stale
Multiple agents	Rewrite per agent, or accept the lowest common denominator	Shared AGENTS.md, per-agent sidecars

If you have one machine, one agent, and no colleagues, a flat file is genuinely fine. The scoping earns its keep the moment there’s a second anything.

Versus built-in agent memory

Most agents now offer some form of automatic memory. It’s convenient and it’s opaque: you don’t fully control what got remembered, you can’t diff it, it doesn’t move between agents, and when it’s wrong it’s awkward to correct.

An exobrain is the opposite trade — explicit over automatic. You decide what’s durable. The cost is that it doesn’t populate itself; the benefit is that you can read it, review it in a pull request, and take it with you.

The gates a fact crosses on the way in — a validator wired into git, a model reading the writing, a squash-merged diff — are How knowledge lands.

Versus a wiki, Notion, or a docs folder

Closer, and often better for humans. Two differences.

It’s written for an agent to read, which changes the prose — rules stated flatly, minimal narrative, structure that maps to how context loads. Human docs explain and persuade; agent docs assert.

It’s structured against drift. Nothing forces a wiki page to stay true, so the agent confidently reports last year’s architecture. An exobrain separates durable areas, which are meant to hold current truth, from time-bound work that is expected to go stale — so staleness lands somewhere harmless.

And it’s in the repo, next to the work. The agent already has a filesystem. No integration, no auth, no API.

When you don’t need one

Worth saying plainly:

• One-off work, or a repo you’ll touch twice. The setup won’t pay back.
• The agent already does fine. If you’re not repeating yourself, there’s nothing here to fix.
• You want it to populate itself. This is an explicit system. If you won’t write things down, it will be empty and useless.
• Purely human documentation. Write those for humans. Different job.

What it costs

A repo, and the habit of writing a fact down when you notice you’ve explained it twice. Setup is one prompt pasted into an agent — see Get started. The rest accumulates as you work, or it doesn’t and you’ve lost an afternoon.