Agent Wars, Episode 2: The Brain Wars

tl;dr: The frontier has moved from prompts to context to memory. Personal memory is mostly solved. Shared memory is where the value and the risk are, and governance, not retrieval, is what decides whether an organisation can actually use it.

An agent forgets everything the moment the session ends. The model spent an hour learning your codebase, and starts next time knowing none of it. Usually, we manually reintroduce that knowledge every time: the system prompt, the files we re-retrieve, a paragraph of what happened last session, all fed back in so the model can behave as if it remembers. It works well enough that it's easy to miss what it is: a workaround for a model that has no memory of its own.

If you use Claude Code, you know what I'm talking about. Whatever your agent worked out about the codebase today is yours, on your machine. Nothing you taught it survives beyond that boundary except what you wrote in a CLAUDE.md or AGENTS.md, and your teammate's agent starts from that same thin file knowing nothing of what yours figured out in order to get there. Yes, I know Claude Code has memory, but the memory is per-developer, when the thing worth remembering (how this service actually behaves, why that migration was painful) needs to belong to the repo and the team.

Episode 1 of this series was about the harness - what turns an LLM into something that plans, calls tools, and ships work. Here we'll focus on what the agent remembers in between the times it works.

We commonly call this a second brain - an external store you trust enough to stop holding everything in your own head, or in the model's context window. Build one for yourself and it's a personal brain. Build one for a team and it turns into something else: shared, contested, and in need of rules about who can write to it.

Sounds unimportant, but how well it is executed would determine how useful agents can be in an organisation.

Where context ends and memory begins

The two words get used interchangeably but they aren't the same thing.

Context is what's in the window on this call. It's what you choose to show the model right now so it reasons well this time by deciding what to include, in what order, and how tightly to compress it. When the call ends, the context is gone. Memory is what survives the call, plus the policy for writing it, storing it, and pulling the right piece back later.

Context engineering happens inside one call. Memory engineering happens across all of them, which is why it inherits every problem that anything stateful has: it goes stale, it contradicts itself, it fills up with junk, and eventually you have to govern it (see the context vs memory distinction, and mem0's context engineering guide).

To put it in sort of a hierarchical way:

• Prompt engineering is asking better.
• Context engineering is asking better with the right background.
• Memory engineering is asking better with the right background and the accumulated past.

Each level compounds on the one above. A prompt is just the words of a single request. Context is everything assembled into the model's window to serve that request: the prompt plus the retrieved files, the running history, the system instructions. Memory is the part that has to survive between calls, and hold across (usually) the whole life of the system.

Why not just store a memory as a skill?

You may have heard the discussion that "If a memory is just a fact the agent knows, why not store it as a skill?". A skill is a reusable instruction you hand the agent. If you store a skill like "the finance API uses XYZ schema and should be used for all finance queries" as a skill, the agent will know how and when to use it. Sounds logical, right?

The easy objection is that a library of thousands of skills would be unnavigable, but that's no longer true. Modern skill libraries retrieve by relevance: the common pattern, progressive disclosure, preloads only each skill's name and description and loads the full instructions when a task matches (how SKILL.md works), and community indexes already run semantic search over hundreds of thousands of public skills (the 2026 skills ecosystem). So skills can be retrieved like memories, and can accrue like memories.

And it doesn't even have to be a skill. Any plain file will do the same job: a memory.md an agent reads and appends to works exactly like a fact library, no different in kind from a skill holding a fact. The format was never the constraint.
The real problem shows up once you try to make that memory travel. A markdown file's usefulness as memory depends entirely on the agent reading and writing it: how well it parses the file, resolves conflicts, and updates it without corrupting what's already there.

That capability isn't uniform. An agent built well for this on one surface may not carry the same care to another, and a fact your agent wrote cleanly today might get garbled by a different agent's edit tomorrow. A skill or a markdown file has no protocol for this because none was ever designed to have one: they're read-and-follow instructions, not a system built to reconcile concurrent writers.

Layer on multiple surfaces (a chat assistant, a coding agent, a bespoke app) and the same file now needs consistent access control and update semantics across all of them: who can write, in what order, how conflicts resolve. That's real engineering, and it's exactly the governance a shared memory system exists to provide, not something a skill library or a markdown file was ever built to handle.

So the bottom line remains - skills and plain files can hold facts, but the moment that memory has to port across agents and surfaces reliably, you need a system built for exactly that, not a repurposed skill.

Personal memory is already everywhere

Sau Sheong's write-up of building his second brain is a good one to reference. His tool, Cortex, is a personal knowledge graph in a single SQLite file. It holds three layers at once: a graph of typed entities and relationships, a set of facts the model distilled and scored for confidence, and the raw chunks underneath for keyword and semantic search. Retrieval fuses all three with reciprocal rank fusion. It connects to his assistants as an MCP server, so the same `brain.db` is reachable from Claude Desktop, Claude Code, and whatever else, with nothing to lock him in. He quipped that "a note in isolation is worth its face value, and a note connected to fifty others is worth something else entirely." Once you trust an external memory, he says, your effort moves from remembering to thinking.

It works because it's one person's brain. One trust boundary (him), one owner, one retention policy (whatever he feels like), one blast radius if it holds something wrong. He's honest about the gaps (no decay, no salience weighting, so everything stays equally loud forever), and the gaps are maybe just somewhat annoying rather than outright dangerous.

Now let's say we change one variable and make it shared.

Why shared memory is harder

The naive view is that shared memory is personal memory with more users pointed at it. Change the connection string, and call it a day. However, I think it misses some important considerations.

The first is on shared retrieval. "Retrieval" sounds trivial (search, get results), but look at what Sau Sheong had to build for a good personal brain: the three-layer store, the extraction pipeline, the confidence scoring, the fusion across three retrieval strategies. That's real engineering, and it doesn't transfer. In a world of personal brains everyone rebuilds it, each to a slightly different standard, and most of them worse than they'd like. Build shared memory as a service and it's solved once, centrally, done well, and nobody downstream thinks about it again. For most teams that is valuable, at least at the start, because they get decent memory upfront, and someone else owns the hard part.

Furthermore, shared retrieval is fundamentally a harder problem. A personal brain has a single author, so its facts rarely contradict each other. A shared brain has many authors who disagree, so retrieval has to resolve conflicting facts and decide which to trust (by recency, by source, by who taught it), and it has to give two colleagues the same answer to the same question, which a personal brain never has to guarantee. That extra difficulty is exactly why you want it built once by people who can do it properly, rather than twenty times by people who can't.

The second is that a shared pool everyone reads from isn't actually what people want, at least not on its own. I want the organisation's knowledge and my own working notes and the thread of my own conversations, layered, with mine winning where they overlap, and without my half-formed notes leaking into the answers my colleagues get. So the shape is two tiers that compose at read time: a shared pool underneath, a personal layer on top. The instinct isn't rare (mem0 ships user, session, and agent scopes; supermemory separates contexts with per-entity container tags), so I wouldn't call the layering itself novel. What's less settled, from what I've seen, is making the personal layer a first-class conversational surface over the shared pool rather than a second database bolted on beside it.

The third is aggregation. Once memory is shared, the unit you want is rarely a single brain. It's a team brain made of several sub-brains (a policy brain, a systems brain, a this-project brain) that you query together or apart depending on the question, and that sometimes disagree. Deciding what happens when two sub-brains contradict each other is a problem a personal brain never has, because a personal brain is one thing by definition.

The fourth is that the source of truth keeps moving. A personal brain gets fed by hand. A shared brain fed only by hand is stale the day someone updates the actual policy in Confluence and doesn't think to tell the brain. So a serious shared memory has to sync: watch its sources, re-ingest what changed, tombstone what was deleted, and do it without a person in the loop each time. That's a whole subsystem the personal case skips most of the time.

Each of those is its own argument for building shared memory as a service rather than a pattern every team reimplements. Governance is the fifth and biggest reason since it's the one that decides whether an organisation gets to use any of this at all. It deserves a section of its own, and I'll come back to it in full further down.

Is memory a graph?

Here the field splits. "Memory", "RAG", and "knowledge base" get used as if they meant the same system and they don't.

Ask an engineer to give agents memory and the reflex is often a knowledge graph. Chunk retrieval finds passages near your query, which is fine until the answer needs three facts that exist in three different documents. A graph gives you structured, multi-hop recall: this person owns that policy which supersedes this other one. Zep does this by building a temporal knowledge graph from the conversation so it can reason about what was true when, and it leads the field on temporal-reasoning benchmarks (there are several 2026 framework comparisons if you want the numbers, though they come from the vendors, so pinch your salt to taste).

A graph is a data-modelling commitment (as the agentic GraphRAG writers put it), and a data model is a standing bill. It wants an ontology: entity types, relationship types, rules for what connects to what. Ontologies drift. Entities get renamed, relationships get added, and with no owner the graph goes stale faster than your durians (I mean the raw chunks) (Zep's own case against naive RAG-as-memory makes the maintenance point well, even while it sells a graph). Fragment-by-fragment extraction from a growing corpus tends to throw off graphs that are inconsistent and structurally broken, which then degrades the retrieval you built the graph for in the first place (the motivation behind newer work like MemGraphRAG).

Which is why a lot of the market doesn't build a graph at all. mem0 is a memory layer you bolt onto an existing agent, with those three scopes and a self-editing step that resolves contradictions on write. Supermemory offers the whole context stack behind one API (memory, retrieval, profiles, connectors, file processing), scopes with container tags, and keeps a pluggable vector backend so you bring your own. Both store distilled facts, notes, and chunks, namespaced by owner and retrieved by relevance, with no committed ontology to maintain. Letta (formerly MemGPT) takes a third road: treat memory the way an operating system treats RAM and disk, and let the agent page its own memory in and out, so the agent manages the memory rather than being handed it.

Give up the graph and you give up guaranteed multi-hop traversal, which is a real loss for the queries that need it. In exchange you drop the ontology tax, which for a memory that changes every day and answers to no single curator is usually the better trade. My view is that for shared, fast-moving, human-fed memory the non-graph shape is the better default to have, and you add graph structure only where a particular query class objectively benefits from it:

• Reach for the graph when the domain is stable and someone owns (and maintains) the ontology.
• Reach for plain namespaced records when neither is true, which is most of the time.

Shared vs. personal is handled the same way everywhere: a store plus a namespace you read within. We're not radically differing from the norms being established.

A concrete case: GovBrain

GovBrain is a system I've been working on. It's a self-service control plane for government teams to create, fill, share, and manage isolated long-term-memory brains. A user provisions a brain, ingests documents and images, searches it, shares it with colleagues, teaches it new facts (with optional review), and can make it forget when they need to. The control plane is the operator surface; the retrieval intelligence lives in a separate engine underneath, reachable by agents as MCP tools over the organisation's gateway. I'm referencing it to illustrate some of the challenges I mentioned earlier.

Start with engineering the retrieval pipeline: Retrieval quality (the chunking, the ranking, the fusion, the ingestion of PDFs and slides and images) is built once, in the engine, and every team that provisions a brain gets it without knowing it's there. A policy officer doesn't become a retrieval engineer to get a good brain. That's what they feel on the first day, ahead of anything to do with sharing. As an added bonus, this is the exact same mechanism I'm using: the memory engine is a memory-as-a-service that Fred built, and GovBrain is the sharing layer on top of it.

In GovBrain, there's a shared knowledge layer, and over it a per-user layer for an individual's notes and conversational context, so my working thread doesn't bleed into the answers a colleague gets from the same brain. Brains carry graded access (use, contribute, manage) and compose with each other. And a brain can be kept in sync with a source system, so when the underlying document changes the brain re-ingests it and tombstones what's gone, with nobody re-uploading by hand.

A brain also isn't tied to a surface. The same brain is reachable as MCP tools over the organisation's gateway, so anything that speaks MCP can read it: a chat assistant, a coding agent wired in through a session hook, a bespoke internal app through the REST path. The knowledge lives in one place and travels to wherever the work happens, instead of being copied into each tool and drifting out of sync. Portability matters more for shared memory than for personal, because the whole point is that one authored fact reaches everyone, on whatever surface they're working.

On governance, the parts that make this safe are already in place. Every brain is namespace-isolated. Sharing is by explicit grant at three levels (use, contribute, manage). Teaching can be gated behind review before a fact lands. And the consent page sits in front of any external agent before it touches a brain. What we're building further is the harder end of the same problem: richer provenance (tracing a fact from who taught it through to the answers it later shaped) and cleaner un-learning (removing a fact and its downstream influence in one move).

Those are the frontiers for everyone working on shared memory, and they're where most of the roadmap now points.

The frontier has shifted

Sau Sheong built a personal brain because he wanted one. We built GovBrain because we see an increasing need for shared institutional memory that is agent/AI-ready. The mem0, Zep, Letta, and supermemory teams are building memory-as-a-service because the market asked for it. The industry is somehow all building the same primitive: a persistent, retrievable, shareable memory that sits outside the model and outside the harness.

When a dozen groups independently build the same missing piece, the field is telling you where the frontier moved. It moved off the model. For a while the question was which model, then it was what context to feed it, and the state now is that the models are good enough and the context tooling mature enough that neither is the bottleneck for most enterprise work. The bottleneck is that every agent starts each session with no memory of what the organisation already knows.

The systems that win shared enterprise memory won't win on retrieval cleverness, because retrieval is converging and good-enough is, past a point, good enough. They'll win on two harder things to copy: solving retrieval once so nobody downstream has to think about it, and making the shared pool governable. The first is why this is a service and not a library. The second is the actual fight.

Governance is the fight

Look at what a shared memory is from a governance seat. A mistake doesn't wash out when the session ends; it persists and compounds. A fact one person contributed shapes the answers everyone else gets. And because the whole thing is reconstructable, the aggregate can reveal things no single entry was meant to. That's most of what makes data-governance people nervous, arranged in one system that agents write to on their own.

For a shared-memory system, the controls around the store are more important than the store itself. The two that carry the most weight are provenance and forget.

Provenance keeps each fact pointing back to who taught it and from where, so it can be trusted or challenged later. It should run forward too, not just back: if you can trace which stored facts fed into a given agent answer, then a wrong fact - or one planted on purpose by someone trying to poison the brain - doesn't just get corrected at the source, it tells you everything downstream it already touched. Forget decides whether a fact can be cleanly un-learned once it's in, including from everyone who's already read it downstream, and it's mostly unsolved as far as I can tell. Grants and isolation are the more tractable pair, deciding who can read or contribute and keeping "shared" from quietly meaning "shared with everyone". Consent is worth its own mention because it's the one users actually see. In GovBrain it's a checkbox and a paragraph, upfront and unambiguous.

Star Wars has the cautionary version of getting this wrong. When Obi-Wan can't find the planet Kamino in the Jedi Archives, the archivist tells him, with complete confidence, that "if an item does not appear in our records, it does not exist". It did exist. Someone had quietly deleted the record, and the shared archive had no idea it had been tampered with. That's the failure mode of a shared store without provenance and an audit trail: it doesn't just lose a fact, it loses any knowledge that it ever held one, and keeps answering as though it were complete. Provenance and a record of deletions are what stop your memory from lying to you with a straight face.

The industry is settling on a governance baseline for agent memory, and regulation is arriving to match. The recurring list is access control at the point of retrieval (no over-provisioned reads), immutable audit logs of which memories influenced which answers, provenance on every stored fact, retention schedules that purge by data classification, and selective deletion for right-to-be-forgotten requests (Atlan's governed-substrate and memory-governance risk writeups collect the list well). The regulatory clock is real too: the EU AI Act's obligations for high-risk systems, and GDPR's right-to-be-forgotten applied to accumulated memory, both push the same way. The uncomfortable part is that most of these have to be designed in before memories accumulate, not retrofitted after.

Who decides what gets in?

Provenance and forget are both about a fact after it's already in. Review is what decides whether it gets in in the first place, and a system that can trace a fact back to its author is most of the way to being able to challenge that author before the fact ever lands, not just after. Not every brain will run that workflow - a small team's working notes don't need an editor in the loop. But a brain that matters enough to a team or a department will eventually want one, and the mechanism has to exist in the platform now, not get stitched on once someone asks for it. It's the same boundary-you-can't-retrofit problem as provenance and forget themselves. Concretely, that means more than a yes/no gate on a contribution: the ability to reject a specific edit with a reason attached, route it back to whoever wrote it, and let them see who rejected it and why, rather than watching their contribution just vanish.

So far, this assumes a human decides what's worth teaching the brain - someone notices something in a conversation, a support ticket, or their own working notes that isn't written down anywhere yet, and decides it's worth turning into a fact the brain should hold. That's the safest point to gate at, because a person is making the judgment call before anything gets written. But as agents take on more of the actual work, it's reasonable to expect they'll increasingly be the ones proposing what should go into a shared knowledge base too - summarising a thread, noticing a pattern across tickets, drafting the fact for a human to approve, or in more autonomous setups, writing it directly. That shifts the risk surface: a human skimming their own notes before sharing them is a different guardrail than an agent deciding on its own that something looks worth remembering.

This is where a privacy technique like k-anonymity has a real, narrow job - not on the live store itself, but on what an agent is allowed to surface from it before a human ever signs off. It generalises or suppresses fields until any individual is indistinguishable from at least k others (primer here), which is a one-way, point-in-time transform meant for releasing a dataset, not for a live store agents read and write continuously - anonymising the store itself fights the thing that makes it useful, since provenance and forget need to keep pointing back at who said what. But say three different employees each separately taught the brain that a vendor was slow to respond, none of them aware the other two exist. No single report is worth surfacing with a name attached - that's someone's private complaint. An agent noticing the pattern across all three, and proposing "three independent reports flag vendor X as slow" without naming any of them, is a genuinely useful escalation an organisation would want ahead of renewing that contract. That's k-anonymity doing its actual job: stripping identity from a derived aggregate an agent proposes to promote, not anonymising the memory that has to keep full provenance to function at all.

It's not a substitute for governance, and it can leak on its own - k-anonymity is brittle under homogeneity, background knowledge, and aggregation across releases, so a pattern that looks anonymous in isolation can still be re-identifiable once combined with something else the reader already knows. Which is why, even as agents take on more of the curation work, a human stays the actual gate: an agent can propose, an aggregate can be scrubbed of names, but something with the authority to say yes or no to what enters a shared brain has to still be a person, at least for as long as forget and provenance remain as unsolved as they are.

None of these is optional in an enterprise, least of all a government one, and none can be bolted on after the retrieval is nice. They shape the storage (you can't add per-contributor forget to a store that discarded provenance), the sharing, and the interface (the consent moment has to live somewhere a person sees it). Building the memory is the part everyone is racing on. Making it governable is the part that decides whether an organisation can turn it on. If you're building here, the unglamorous version of the advice is to settle your write policy, your namespacing, and your forget story before you fall in love with your retrieval. Those three are painful to retrofit. The ontology, the embeddings, the fusion strategy, you can change later. The boundaries you can't.

Whose memory, governed by whom

The models will keep getting better, and so will the context tooling, and I doubt either is what we'll be arguing about a year from now. We'll be arguing about whose memory an agent is allowed to read, who's allowed to write to it, and who has to sign off before a fact crosses a boundary. Personal memory let one person stop remembering so they could think. Shared memory lets an organisation do it, which is a larger prize but a harder thing to hold safely. We're at the early stages of working out what governance for that looks like, but it's a problem worth tackling early.

Going back to that robot at the blank whiteboard at the very beginning, we see that every day it does good work, fills the board, hands over the result, and wipes it clean, and every day it starts from nothing. The whole purpose of shared memory is that the board doesn't have to be wiped: that what one agent worked out is still there for the next one, kept and governed rather than quietly lost. Whether your organisation's agents get that board, and who is allowed to write on it, is something that you have to intentionally build for, before you find out by accident that everyone has been starting from blank every time.