One memory, every agent — and a policy that actually holds

Four agents, four memories, none of them shared

Look at one engineer's actual week. Claude for thinking a problem through and drafting the write-up. Claude Code or Cursor in the editor all afternoon. ChatGPT for a research detour into a vendor's API. And, increasingly, the agents their own company built — the one that triages incidents, the one that answers questions about the product.

Every one of those remembers something. None of them remember the same thing.

So the preference you corrected on Monday — we don't use that library any more, here's what we use instead — is known to exactly one of them. The architecture decision your internal agent captured in an incident review is invisible to the assistant you ask about it on Friday. The context your team pays to build, one careful correction at a time, is scattered across four products that cannot see each other.

The fix is easy to describe: one memory, behind all of them. The reason it isn't already everywhere isn't the plumbing. It's the second half of the sentence — the moment a single memory serves every agent and every person in a company, you have built a system whose defining requirement is who is allowed to see what.

Connecting every agent to one memory is a weekend of protocol work. Governing it is the product.

The easy half: one memory, reached over MCP

Since the Model Context Protocol became the common plug, this part stopped being interesting in a good way. Any compliant client — Claude, Claude Code, ChatGPT, Cursor, or an agent someone on your team wrote last month — can call the same memory server without a bespoke integration for each one.

The tool surface should stay small, because a large one is a surface agents get wrong: search the memory, ask it a question and get an assembled answer with the evidence attached, write facts back with the evidence that supports them, inspect the ontology when the agent needs to know what kinds of things the organization tracks.

Two properties matter more than the tool list.

Memory is bound to identity, not passed as an argument. None of the user-memory tools take a user, tenant or graph parameter. The target is fixed by whoever signed in, at connection time. That isn't a convention agents are politely asked to respect — it's the difference between a rule and a hope, because an argument an agent can set is an argument an agent can set wrong.

Both directions are the same memory. Context written from an assistant is read by the agents you build against the SDK, and what those agents learn is there the next time a person asks. There is no "assistant memory" and "agent memory" to reconcile later, because there was only ever one graph.

The hard half: the organization remembers too

Personal memory is only half of what an agent needs. The other half belongs to the company: product knowledge, customer history, incident history, the conventions that only exist because somebody got burned once.

That context doesn't live in any one person's memory — it lives in shared corpora. And an agent that can reach more than one of them needs a way to know which is which, without reading them all first.

So there's a directory: a catalog of the corpora a project holds, each with a stable identifier and a name and description a human wrote. We don't generate those descriptions from the contents. Routing metadata is exactly the kind of thing a person should be accountable for, and a summary inferred from a graph tends to describe what happens to be in it rather than what it's for.

The flow an agent follows is two steps, and it matters that they're separate. First it searches the directory — that search matches routing metadata only. Then it picks one corpus and searches inside it, and that search touches content. Discovery and retrieval are different operations with different blast radii, so they get different tools.

Why we're building this inside the engine

Here's the argument the whole product rests on.

Almost every memory layer in this category is composed from storage somebody else wrote — a hosted vector database, a graph database, a queue. That's a perfectly reasonable way to build a memory API, and it puts a hard ceiling on how well you can govern one, for two reasons.

Filtering after the match is not access control. Retrieval is a ranking operation over the whole index. If scope is applied to the result set afterwards, out-of-scope data has already voted: on which neighbours came back, on how they were ranked, on the counts, and on any summary assembled over them. The rows are gone from the response; their influence isn't. Enforcing scope during the match — as a predicate the planner pushes down into the index traversal — requires owning the planner and the index.

Deletion you can't propagate isn't deletion. Delete a source document from a typical memory stack and you've removed one row. The facts derived from it, the edges those facts support, the summaries compacted over them and — most stubbornly — the embeddings in the vector index all survive. No mainstream vector store offers provable removal of an embedded record; the honest description of what happens is that the vector is tombstoned and filtered at query time. That is a difference between "we no longer return it" and "it is gone", and only one of those two sentences is what a GDPR erasure request asks for.

We wrote our own graph database for reasons that were mostly about operational weight at the time. This turned out to be the more important consequence: because Axon owns the Cypher planner and the HNSW vector index sits in the engine rather than beside it, scope can be applied while matching, and erasure can propagate through the index instead of around it.

Scroll the table sideways on a narrow screen.

That is an architectural difference, not a feature gap — which is a useful thing to know in both directions. It's not something a competitor ships next quarter, and it's not something we can bolt onto the parts we didn't write.

Where this actually is

The category has a bad habit of describing the roadmap in the present tense, so here is the boring version.

The engine is not a prototype: it runs EdgeX11's own organizational memory every day, and the agents in this company read and write it through exactly the MCP path described above. The governance tier on top of it — the part this post is really about — is what we're building now, under the name Corpus. It isn't shipped. We'd rather write that sentence than let a launch post imply otherwise.

Why we're doing it in this order

Because the deadline is external. The EU AI Act reaches full application this month, and it brings record-keeping duties measured in years for systems that land in its high-risk categories. Those duties sit directly alongside the GDPR's right to erasure, and the two pull in opposite directions: keep a durable, inspectable record of what the system did and why — and, on request, remove one person's data from it.

You can only satisfy both if you can say precisely what was derived from what. Provenance stops being a nice property for debugging and becomes the mechanism that lets you delete a person without deleting the audit trail, and prove afterwards that you did.

What it adds up to

One memory across every agent is the visible half — the half your engineers feel immediately, when the thing they explained on Monday is still true on Friday no matter which window they're typing into.

The half that decides whether a company can actually deploy it is the one underneath: memory bound to an identity rather than a parameter, organizational context discoverable but scoped, policy applied while matching rather than after it, and deletion that propagates all the way down to the vectors and leaves a receipt.

That's not a feature you add to a memory API. It's a property of the database, which is why we're building one.