The portable-memory problem
Your context is trapped inside whichever assistant you told it to. As people use more than one AI and switch models constantly, that fragmentation is becoming the real bottleneck. What portability actually requires, what the Model Context Protocol does and doesn't solve, and why this is a data-ownership question.
By Jackdaw Team
The short version: Every assistant builds its own private memory of you, and none can read the others — so you end up as the integration layer, re-explaining yourself to each new tool. Real portability needs a store you own, a shared interface for any AI to read it (MCP is the emerging one), and controls you hold.
Almost everyone using AI is now in the same situation: their context is scattered across several assistants. One knows your writing style. Another knows your current project. A coding tool knows your codebase but nothing about your preferences. Each built its own private picture, none can see the others, and the thing stitching them together — re-explaining, copy-pasting, repeating yourself to each new tool — is you.
This is the portable-memory problem, and it's becoming the limiting factor faster than any individual model's capability. The models are getting good enough that the bottleneck is no longer how smart they are; it's how little they know about you, and how much of what one learns is invisible to the rest.
Why the fragmentation happens
It isn't an oversight. Every provider has a strong incentive to build memory into its own product, because memory makes their assistant stickier and better — and no incentive whatsoever to build a shared layer that would also make a competitor's assistant better. So memory accrues inside walled gardens by default. Your context lands in each provider's store, in each provider's schema, under each provider's controls and retention policy. There is no shared substrate because the market doesn't reward building one.
Two consequences follow directly, and both get worse the more AI you use.
Switching costs harden into lock-in. The more an assistant has learned about you, the more it costs to leave — not because its model is better, but because your accumulated context is held hostage to it. That's lock-in by data gravity, and it's lock-in you built yourself, one conversation at a time. The better the memory feature works, the more trapped you are.
The copies drift apart. Tell one assistant you changed jobs and the others still think you work somewhere else. Update a preference in one and the rest are now stale. Maintaining several private profiles by hand is a losing game: they diverge, and you have no way to know which one is current. You end up not with a model of yourself but with several inconsistent ones, and no source of truth among them.
You shouldn't be the integration layer
The deeper problem is whose job the stitching is. Right now it's yours. You carry context between your AIs in your head and your clipboard. Every new tool starts from zero and has to be re-taught who you are, what you're working on, and what you've already decided. As the number of AI tools per person climbs — and it is climbing — that re-explanation tax climbs with it, linearly, forever.
That's backwards. In every other part of computing, your data lives in a place you control and the applications come to it; you don't keep a separate copy of your files inside each program that wants to read them. Context about you should work the same way: it should live in one place that you own, and every AI you choose to use should be able to read the relevant slice of it — and propose writes back to it — through a common interface. You explain yourself once. Each new tool inherits the picture instead of rebuilding it from scratch.
What portability actually requires
Three things, none exotic, all necessary:
A store independent of any single model. Your memory cannot live inside an assistant if it's meant to outlive your choice of assistant. It has to be a separate layer that persists across model switches, provider changes, and tools that don't exist yet. The moment the store is owned by one provider, you're back to a walled garden with extra steps.
A standard interface to read and write it. Independence isn't enough on its own — a store every assistant accesses through a different, proprietary API is just a slightly larger silo. Portability requires every AI client speaking the same protocol to the same store. That's the piece that makes "explain yourself once" actually work across tools.
A trust and control boundary you own. If many AIs can read your context, you need to govern what's in it, what each one is allowed to see, and what gets written back — with the ability to review, correct, and revoke. A shared, readable store without that boundary isn't portability; it's a single large leak. Control is not a feature bolted on afterward; it's a precondition for the whole thing being safe to use.
What MCP does, and what it doesn't
The interface problem, at least, is now being solved in the open. The Model Context Protocol, introduced by Anthropic in late 2024 and since adopted broadly across the industry, is an open standard for connecting AI applications to external context and tools. The shape is deliberately familiar: it's a client–server protocol (built on JSON-RPC) in which a server exposes capabilities — resources to read, tools to call, prompts to use — and any MCP-capable client, meaning the assistant, can connect to it and use them. A single server can expose a body of knowledge once, and every assistant that speaks the protocol can reach it, without each one needing a bespoke integration.
That is exactly the "common interface" portability needs. It decouples where your context lives from which AI is using it. A memory store can sit outside any single assistant, expose itself as an MCP server, and be read by Claude, by a coding tool, by your own agent — all through the same protocol, none of them owning the data. The structural reason memory had to be trapped in one product is gone.
What MCP doesn't do is equally important to be clear about. It standardizes the connection; it says nothing about what the memory contains or how good it is. The hard problems don't disappear: what's worth storing, how to keep it faithful as facts change, how to honor a correction rather than pile a new claim on top of an old one, how to retrieve the right slice for a given request — those remain exactly as hard as they were (we've written about what makes memory hard and how today's assistants handle it). A protocol can carry garbage between systems as easily as it carries something good. MCP removes the plumbing excuse for fragmentation. It doesn't build the thing the plumbing connects to.
This is a data-ownership question
Strip away the technical framing and what's left is a question about who owns the accumulating record of your life with AI. Today the answer is: whichever providers you happened to talk to, separately, in formats you can't easily export or reconcile. As that record grows more valuable — as it becomes the thing that lets an agent act usefully on your behalf rather than a nicety that makes chat smoother — the case for it being yours, portable, and inspectable rather than scattered across vendors' private stores gets stronger.
Where this goes
The trajectory is fairly clear. Memory started as a per-product feature and proved that people want it. The next step is memory as a layer — owned by the user, standardized in how it's accessed, faithful enough to act on, and readable and writable across every AI a person uses. The walled-garden version will keep existing, because lock-in is valuable to the people building the walls, and they're not wrong to build them from where they sit. But the pull toward portability is strong, because the alternative is a future in which every person manually maintains a dozen diverging copies of themselves, one per assistant, forever.
The model you use should be a choice you can change without penalty. Your context — the part that's actually about you — shouldn't have to be re-earned every time you make it.