building a shared memory brain for AI agents

Every AI agent is an amnesiac. Close the session and the context is gone. Open a second tool and it knows nothing the first one learned. So you re-explain the same things — your stack, your conventions, why that service broke last time — to every agent, every session. The fix isn't a bigger context window. It's a memory that lives outside any one agent, that all of them share.

what I built

A persistent memory "brain" — call it Neuralis — that every tool and agent in my self-hosted fleet reads from and writes to. One source of truth. A coding agent learns something at 2am; the dashboard chat knows it by morning; next week's session starts already knowing it. The live demo at dirtysouthalpha.com/brain is that memory, visualized: every node is a memory, every edge a connection the brain drew itself, and the pulses traveling the graph are recall firing.

how it works (kept deliberately simple)

The whole thing rests on three moving parts, and each one is boring on purpose. Boring is what keeps it in daily use.

• Writing a memory is one call — the content, a region, where it came from, and a topic. That's it. Low friction is the whole point: if writing a fact is hard, nobody does it, and the memory dies.
• Recall is hybrid. Fast keyword/lexical search returns what you know about something in well under a second, and a graph layer pulls in related memories so you get a neighborhood, not a single row.
• It's a graph, not a list. Memories link to related memories, so recall returns context, not just a hit.

the design decisions that actually matter

The storage is the easy part. The reason this brain stays useful — instead of quietly rotting into a pile of contradictions the way most "memory" features do — comes down to five decisions. This is the interesting part.

1. Supersede, never delete. When a fact turns out wrong or stale, you don't delete it — you write the corrected fact and supersede the old one: the old memory stops surfacing, the new one wins by default, and the old stays linked for lineage. Two reasons. First, recall never hands an agent both the right and the wrong answer to pick from at random. Second, the history of a wrong belief is itself useful — "we thought X, it was actually Y, here's how we proved it" is worth keeping.
2. Write the mechanism, not the answer. "It's on port 8080" ages the moment something moves. "Find it with a quick lookup, then check the process" stays true forever. Memories that encode how to re-derive a fact outlive memories that just state it. This is the single biggest quality lever — the difference between a memory that helps for a day and one that helps for a year.
3. Dedupe before you write. Search first, write second. A brain full of near-duplicates is a brain that returns noise, and agents stop trusting it.
4. Write-back after the session, automatically. Durable facts — a root cause with evidence, a restart procedure, a "this looks like X but is actually Y" scar — get persisted at the end of a run so the next agent inherits them. If it cost you an hour to figure out, it should cost the next agent zero.
5. Accuracy is everyone's job. Every tool that touches the brain is responsible for keeping it correct: fix it on the spot, supersede when it's wrong. A shared memory that's allowed to rot is worse than no memory — because agents trust it.

A shared memory that's allowed to rot is worse than no memory — because agents trust it.

That second decision — write the mechanism — is worth making concrete. Instead of pinning a fact that a value lives in some fixed place, you store the move that finds it, so the memory survives the value changing underneath it:

a memory that re-derives itself

# bad: states a fact that goes stale the moment it moves
#   "the service is on port 8080"

# good: stores how to re-derive it — still true after it moves
ss -lntp | grep :PORT   # then check the owning process

Same idea, wildly different shelf life. The first memory is wrong the next time something reshuffles. The second one is a tiny procedure that keeps returning the right answer no matter what moved.

why a graph, and why regions

Grouping memories into regions (domains) and linking them means recall surfaces a neighborhood of related facts, not an isolated match — which is how you actually remember things. You don't recall a single fact in a vacuum; you recall it alongside everything it's connected to. The demo shows this literally: click a memory and its connected subgraph lights up; that's the same structure recall walks. A flat list can hand you a matching row. A graph hands you the row and the context that makes it useful — the neighboring facts you'd have had to know to ask for, plus the ones you didn't know existed.

the payoff

Nothing gets re-explained twice. Every run starts one step smarter than the last. The coding agent, the dashboard, the CLI — they share one brain, so knowledge compounds instead of scattering across a dozen tools. It's grown past 130,000 memories, self-correcting as it goes.

That compounding is the part you feel over weeks. A single agent with a great context window still forgets everything the moment the window closes. A shared brain doesn't: the lesson one tool learned the hard way is already waiting for the next one. The curve bends the right direction — the system gets more capable the longer it runs, not less.

the bigger point

A persistent, shared, self-correcting memory changes how you work with agents. You stop treating every session as a blank slate and start building on what the fleet already knows. That's the whole game.

Try the live brain — it's the visual proof of everything above, the real memory rendered as a graph you can poke at: