Cross-Vendor AI Memory: The Opening No Vendor Can Address

Anthropic shipped Projects and Memory. OpenAI shipped Memory. Cursor has its own context system. Every serious AI tooling company is racing to own the memory layer.

This is rational behavior. Memory is the new moat. The longer your AI product remembers your work, the harder it becomes to switch to a competitor. Model quality converges; memory does not.

But there's a structural problem with all of this from the user's perspective: every vendor's memory is locked to their product. Claude's memory doesn't surface in Cursor. ChatGPT's memory doesn't surface in Claude. The user, who runs across six products in a day, ends up with six fragmented memory systems and no portability between them.

Why the vendors can't fix this

Imagine you're Anthropic. You've built great memory inside Claude. Should you ship a deep integration with Cursor, so a user's Claude conversations and Cursor sessions share context?

You probably shouldn't. Reasons:

1. You're competing with Cursor's likely future products. Anthropic ships coding products. Why would you build the bridge that makes Cursor better?
2. You can't be a neutral broker. Even if you wanted to, your incentives are to keep users inside Claude, not to make Claude one of many tools they pass through.
3. Integration burden is asymmetric. You'd have to build and maintain N integrations with N competitors, each of whom has incentive to break them.

The same logic applies to OpenAI, to Cursor, to everyone. Vendor-built cross-vendor memory is structurally impossible — not in a "they could but won't" way, but in a "their business model actively punishes it" way.

What the user actually needs

The user needs a memory layer that is not owned by any model vendor. One that can:

• Capture context from any source (Claude Code sessions, Cursor logs, ChatGPT exports, GitHub, Google Docs)
• Store it in a form that's queryable across all of them
• Deliver scoped slices to whatever AI tool is currently active
• Belong to the user, not to any vendor

This is infrastructure, not a product feature. It is the role of a neutral third party.

The storage / compute analogy

Cloud computing went through this. Compute and storage were originally bundled — you bought a server, you got disks attached. The first cloud providers kept the bundle, then specialized providers emerged who decoupled them. AWS S3 was the wedge. The market for "storage that any compute layer can talk to" turned out to be larger than the market for any bundled compute-plus-storage product.

We think AI memory plays out similarly. The bundled era — "Claude's memory inside Claude" — is current. The decoupled era — "your context graph that any model can query" — is coming. The standard that enables the decoupling is MCP.

Why MCP matters here

The Model Context Protocol is the first serious standard for how AI clients request context from external sources. Before MCP, every integration was bespoke; every AI tool spoke a different dialect. After MCP, a context provider can serve any MCP-aware client.

This is the protocol-level enabler. Once it exists and matures, the question becomes which provider has the best implementation — best capture, best routing, best lineage, best portability.

That's where we're building. Memplex is destination-agnostic by design: one context graph, served through MCP, scoped per destination, governed by the user.

What it takes to win this position

Cross-vendor positioning is a defensible moat only if you genuinely never compete with the model vendors. The moment a memory provider ships its own model, the neutral position collapses. The moment it gives one vendor preferential treatment, the cross-vendor pitch hollows out.

The discipline is to stay in the infrastructure lane. Build the context substrate. Serve any MCP-compatible client at full quality. Let the user own the data. The competitive advantage isn't a feature the vendors could copy — it's a structural position they cannot occupy.