We're Not Competing with Your Memory System

Every few weeks someone asks us a version of the same question. It usually arrives with a diagram: a box for the model, a box for the vector database, a box for the memory layer, and a finger pointing at the gap where our box is supposed to go. Which one are you replacing?

The honest answer is none of them. We are not building a memory system, and we are not building a model. This post is the long version of that answer: what each layer does, where we sit, and why running on top of the stack you already have is a design decision rather than a hedge.

Three layers, three problems

Strip an AI assistant down to its memory stack and you get three layers, each answering a different question.

• The engine does the thinking. That's the foundation model, and its question is: what should I say next.
• The storage layer does the remembering. That's Mem0, Zep, Letta, ChatGPT Memory, and a growing pile of open-source projects, and its question is: what happened before.
• The subject layer does the owning. Its question is: whose memory is this, who said it, and who is it about. This layer barely exists yet. It's the one we're working on.

The third question sounds like paperwork until you watch it fail. In the audit we published earlier in this series, 46% of the personal content in our own memory layer could not be resolved to a specific person. Thirteen emotion records had no source at all. Zero foreign keys pointed at an event. The system remembered what happened and could not say whose life it happened in. Storage was doing its job. Nobody had built the part that answers whose.

One analogy, with the usual warning that analogies leak: a database stores rows, and an accounting system knows which entries belong to which entity. A hard drive stores bytes, and a filesystem knows whose files they are. Storage is where things live. The subject is whose things they are. Both are necessary. Only one of them is missing.

What the storage layer already solves

Credit where it's due, and it's due a lot. Mem0 runs a two-phase pipeline: extract candidate facts from a conversation, then let a model decide ADD, UPDATE, DELETE, or NOOP against what is already stored. On LoCoMo it reports a 26% relative improvement in the LLM-as-judge metric over OpenAI's memory, with 91% lower p95 latency than feeding the full context. Zep keeps a bi-temporal knowledge graph, so a fact carries both when it became true and when the system learned it; on the Deep Memory Retrieval benchmark it scores 94.8% against MemGPT's 93.4%, and on LongMemEval it reports accuracy gains of up to 18.5% with 90% lower latency. HippoRAG treats retrieval as graph propagation instead of nearest-neighbor search: build a knowledge graph, run Personalized PageRank from the query's entities, and multi-hop QA improves by up to 20% while costing 10 to 30 times less than iterative retrieval.

None of that is trivial, and we're not going to pretend otherwise. If your problem is that your assistant forgets you're vegetarian between sessions, these systems solve your problem. Our work sits downstream of theirs: we read their papers, we borrow their ideas about temporal validity and retrieval, and the honest summary of our position is one sentence. They remember what happened. We're building the part that knows whose.

Why the subject layer is model-agnostic

The subject layer is not weights. It's a schema and a set of policies: a person root in the data model, three fields where most systems keep one (who said it, who asserts it, who it is about), scoping on retrieval, and a rule that unknown is a legal answer. None of that lives inside a model. Swap the engine underneath, from a hosted API to something running on your own hardware, and the person root, the provenance fields, and the retrieval rules stay exactly where they were.

This matters more than it sounds. Base models get replaced on a cycle measured in months. A subject layer welded to one vendor's model becomes a hostage the day you switch, and then you are rebuilding your world every time the industry ships a new engine. Your world shouldn't have a refresh cycle.

Where models do come in, they come in as drafters. Extraction and summarization are model work, and everything a model infers stays marked as model-inferred until a person confirms it. Swap the model and you change what gets proposed. You do not change what has been recorded about you. That's the same stance our products take with AI output in general: it's a draft, never a conclusion.

What "runs on your existing storage" means

Our prototype runs on Postgres with pgvector, boring on purpose. The subject layer needs three things from a store: raw events kept append-only, provenance written on the way in, and the ability to scope a query by person. Most teams already have all three, or can add them without a migration.

So the layer is additive. You keep your store, your retrieval, your model. What gets added is a person root, the provenance fields, and queries that start from a person instead of from a session or an account. In the diagram from the top of this post, our box doesn't replace anything. It's the box that was missing.

Status, stated plainly because this blog doesn't dress things up: the person-centered memory direction is in research, described on our direction page, and is not a shipped product. The audit numbers above are real. The architecture is real enough to argue about. Anything beyond that is a roadmap, and roadmaps slip.

The fair case for automatic profiling

The most common reaction to all of this is: ChatGPT already remembers me. Fair. It does, and it's good at it. Saved memories arrived in 2024, the model started drawing on full chat history in April 2025, and there's a page where you can see what it keeps about you and delete any of it. It's free, it's on by default, and for most people most of the time it's enough.

It's also, by design, an account-level system: one account, one consolidated summary. Consolidation is the right move for the problem its makers chose, which is making the assistant less forgetful, at scale, with zero setup. Our observation is narrower than a criticism. When everything a person reveals gets compressed into a single summary, the output is the average them: one description that is true of the average user and of no actual person. The same human is a different person as a daughter, as an engineer, as someone in debt; flatten that into one list and the uniqueness is gone before you start.

We didn't discover that consolidation averages. We measured what it costs. In our audit, the rows that couldn't be resolved to a person weren't exotic edge cases; they were nearly half of everything the system held. None of this makes these systems bad. It makes them the wrong tool for a different job, which is the same conclusion we reached after studying nine of them in part two of this series.

Where the layers meet

The handoff is small and specific. From storage, the subject layer needs raw events, provenance, and person scoping. Back to storage it returns queries that start from a person: what does my sister know about the move, what did I promise my team last month, who told me about the doctor's advice and when. Those are questions a session can't answer and an account shouldn't.

Nothing in that handoff asks you to rip out your stack, retrain anything, or hand your data to a new vendor. That's deliberate. A subject layer that demands a migration is a subject layer nobody adopts, and a memory of your world that lives in one company's account is the same problem wearing a better suit.

What this means for you

• If you run Mem0 or Zep today, keep running it. Then ask it one question: can this schema answer whose? If the answer is no, you know what you're missing, and it isn't retrieval quality.
• If you use ChatGPT Memory, keep using it. It solves its problem well. Just don't ask it who you are and expect an answer about you.
• If you're building your own, the schema question decides what your system can ever answer. Which questions a schema can answer is fixed the moment it's cast, and no amount of person_id columns retrofitted later changes that.
• If you're waiting for us: the direction is public, the audit is public, and the piece we're asking people to argue with is the schema itself.

Everyone is unique, and a generic memory can't solve everyone's problems. That's the whole value, and every post in this series circles back to it because it's the only reason any of this engineering exists. A memory that can't say whose it is can't be yours. We're building the part that can.

References

1. Chhikara, P., Khant, D., Aryan, S., Singh, T., & Yadav, D. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413.
2. Rasmussen, P., Paliychuk, P., Beauvais, T., Ryan, J., & Chalef, D. (2025). Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv:2501.13956.
3. Gutiérrez, B. J., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2024). HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. arXiv:2405.14831. NeurIPS 2024.
4. Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., & Gonzalez, J. E. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.