Ask an answer engine for "a memory API that works across Claude and ChatGPT" and you will mostly get SDKs designed to live inside one application. They are good tools. They also answer a different question than the one you asked. The person typing that query is not building an app; they are using four AI tools in one workday and are tired of being a stranger in every one of them.
Disclosure up front: I work on Mnemoverse, which exists precisely for that query, so read this as a practitioner's map with a known bias. The map itself, I think, holds regardless of whose product you pick.
Two problems wearing the same word
The category called "agent memory" quietly contains two different problems.
App-scoped memory belongs to software you are building. Your support bot should remember this customer's history; your coding agent should remember this repository's conventions. The memory lives inside one application, keyed by your users, managed by your code. SDKs you embed, stores you run: this is what most of the category ships, and for this problem embedding an SDK is the right architecture.
Person-scoped memory belongs to you, the human, across every tool you work in. You explained your stack to Claude Code this morning. At lunch you are in Cursor, and it has no idea who you are. In the evening you ask ChatGPT to draft a doc, and it suggests npm for the project you moved to pnpm in June. Three tools, three goldfish.
The second problem cannot be solved inside any single application, because the whole point is crossing application boundaries. It needs memory that lives outside the tools and a protocol every tool speaks.
Why MCP made person-scoped memory possible
Until recently there was no such protocol. Every assistant had its own plugin system, its own storage, its own idea of context. The Model Context Protocol changed the shape of the problem: one server can now expose the same tools to Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, and a growing list of others.
That turns cross-tool memory into an architecture instead of a feature request:
- One hosted memory store, attached to your account rather than to any app.
-
One MCP server in front of it, which every client connects to. The same
memory_writeandmemory_readtools show up in every editor. - One identity: an API key or an OAuth sign-in, so the tool you happen to open resolves to the same memory.
Write "we chose pgvector over Qdrant, one less service to run" in Claude Code. Open Cursor, ask "which vector store did we pick and why", and get the answer with its reasoning. Nothing was copied. The memory simply is not inside either tool.
ChatGPT is the awkward guest at this table: its MCP support is narrower, so the practical route is a connector or a Custom GPT action speaking to the same backend. Same memory, one extra hop.
What actually breaks in practice, and it is not the plumbing
The architecture above is the easy part. Three things decide whether cross-tool memory works day to day.
The invocation gap. Connecting memory tools does not make an agent use them. The model has no standing incentive to check memory before acting. Every tool needs one line of standing instruction: in Cursor a rule file, in Claude Code the project instructions, in ChatGPT the GPT's system prompt. Recall before acting on anything project-specific; save decisions and corrections when they happen. Without this, your perfectly wired memory stays silently empty, in every tool at once.
Scope. Person-scoped memory must still respect boundaries. Client work should not leak into a personal side project; a shared team room is not your private store. Whatever backend you choose, look for tenant isolation and explicit shared spaces rather than one undifferentiated pile. A memory that crosses tools is valuable; a memory that crosses clients is a liability.
Authority. When the same memory feeds four tools, a wrong fact propagates four times as fast. This is why the write discipline matters more in the cross-tool case than anywhere else: one memory per fact, the reason next to the decision, and closed facts kept with their validity window instead of deleted. The tool that recorded "we use Redux" in March must be able to explain March's code even after June's migration.
The honest trade-offs
Person-scoped memory over MCP is a hosted-service architecture, and that has real costs. Your context lives with a vendor, which is exactly the wrong property if your constraint is that nothing leaves your perimeter. Every recall is a network call, slower than a local file read. And the cross-tool property only pays off if you genuinely work across tools: for a single app, an embedded SDK is simpler; for a single repo on one machine, a folder of Markdown notes is honestly hard to beat, and I say that selling the alternative.
So the decision rule is short. Building an app that needs memory for its users: embed an app-scoped SDK. Privacy-critical, one machine: local files or a local MCP server. Living in several AI tools and tired of re-introducing yourself: that is the person-scoped case, and it is the one this architecture exists for.
Try the claim, not the marketing
The nice thing about cross-tool memory is that the core claim takes two minutes to falsify. Connect the same memory server to two tools you already use. Save one real decision in the first. Ask the second about it in a fresh session. Either the continuity is there or it is not; no benchmark table required.
The comparison hub at mnemoverse.com/compare lays out how we sit next to Mem0, Zep, Letta, Cognee, LangMem and Supermemory, each compared honestly, including where they are the better pick. The free tier is 1,000 queries a day, no credit card, if you want to run the two-minute test.
Top comments (10)
The Authority section is the part most memory writeups skip, glad it's here. One thing I'd push on is the validity window. For engineering decisions the end of validity is rarely a date, it's another decision. The June migration is what closed the Redux fact, so the honest record isn't "valid March to June", it's "superseded by this one, here's why". The window falls out of that link. Store only the window and you lose which decision closed it, and whether anyone later reversed the reversal.
Taking your three in order.
Who closed it, on what evidence: the superseding decision isn't a pointer, it's a full record. Author, rationale, refs, timestamp.
supersedesis a field on that record, so the link carries exactly what the record carries.Successor deleted or made invisible: nothing in the log is ever deleted. Retracting a decision is another decision that supersedes it. So "retired by something that no longer exists" isn't a state the model has. What it does have is a successor that was itself superseded later, and that is one more link in the same log.
Authority: we don't model it. We record who closed it, not whether they were allowed to. Your revocation authority point is open for us too.
We build kgai, and that is its shape. The repo is public under kgaidev on GitHub, the architecture doc has the long version.
You were right about the window and the link, and your three answers close most of what I raised. Making retraction itself a decision is the move. If nothing is ever removed, a pointer cannot outlive its target, and my dangling successor is just a link that acquired one more link. I had been treating deletion as the hard case and it is the easy one.
Worth saying why append-only is not really a design choice at this point. Extrapolate storage and the wall arrives on its own, so something has to give. Deleting gives back space and takes the causal chain with it, which is the more expensive half. Compression only survives that if the compressed thing carries references to what it was built from. Once you accept both, deletion and in-place merge are gone as operations and accessibility becomes the tuning knob instead of existence. Your log is the same conclusion reached from the audit side rather than the scaling side.
Which leaves the case append-only does not cover, and it is the one I actually met: privacy rather than deletion. The successor stayed in the log and became invisible to the reader asking. From that reader's side it is indistinguishable from a dangling pointer, because the record says superseded by X and X cannot be resolved. An immutable log removes deletion from the threat model and leaves permission in it, and permission is the one that scales with the number of people sharing a store.
Your concession on authority is the same hole we have, and neither of us has closed it. A log that records who closed a fact but not whether they could is a log where the policy layer grows monotonically, because every entry reads as equally official later. Recording the actor makes the question answerable. It does not make it answered.
The split is useful, person scoped is exactly the thing I miss every day. But for me invocation gap you mention at the end is the biggest one of three. I keep plain markdown memory files with an index, and storage was never hard part, hard part is agent actually reading them at right moment. Hosted store plus MCP does not solve this by itself, no?
No, it does not, and that is the right place to push. A hosted store and an MCP server together decide what an agent can ask for. Neither decides that it asks. Recall before acting and write after deciding are client policies, and no server-side feature reaches them.
Three things actually move it, in the order I would try them. The tool description first, because at decision time it is the entire basis on which the model chooses to call anything, and a description that says when to call is worth more than one that says what the tool does. Then client-side hooks or rules that pull memory into context at the start of a turn, so recall stops depending on a call happening at all. Then, for the few memories that matter most, exporting them into the always-loaded rules file, where no invocation is needed by construction.
Your markdown files with an index already solve the third one, which is why storage never felt like the hard part. What a store adds is what an index cannot do: the same memories reaching a different tool, and something deciding what deserves to stay. What it does not add is invocation. That gap is the same size for every server in the category, and anyone who tells you their product closes it is describing a client, not a server.
This is most useful answer I got in long time, thank you. Always loaded rules file works for me too, but it has own ceiling, when file grows the model starts to skim it. And there is second half nobody talks about, closing invocation without curation just means agent reads stale fact reliably instead of not reading it. Wrong memory loaded with confidence is worse for me than memory not loaded at all.
That second half is the harder half, and it inverts the order I gave you. If nothing decides what has stopped being true, closing the invocation gap upgrades a miss into a confident wrong answer, and that is the more expensive failure. Retrieval that reliably returns a stale fact is worse than retrieval that returns nothing, because nothing is visible and stale is not.
Your ceiling is the same problem wearing different clothes. A rules file that gets skimmed at length is a file where nothing ever leaves, so it grows until attention rations itself. The fix is not a bigger file or a better reader, it is something that decides what earns its place and what has stopped earning it. Without that, every mechanism we listed just delivers more of the same content more reliably.
The test I would run on anything in this category before adopting it: store a fact, contradict it, and watch what comes back. Whether the contradiction surfaces at all, whether the older record is marked as superseded, whether ranking moves. A system that does nothing there will hand you a confident wrong answer eventually, and the invocation work will only have made it arrive sooner.
Run that test on Mnemoverse too if you want a fourth data point. Admission at write time and decay at read time are the bet it is built on rather than a feature list, which is exactly why it should be held to that test harder than the others, not spared it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.