How to give your AI assistants one shared memory

You explain your stack, your clients, your constraints to one assistant. Two weeks later you switch to another model because it is better at the thing you now need — and you start from zero. The memory you built is not yours; it lives inside a product.

That is the actual problem. It is not that assistants forget: most of them remember quite well now. It is that each one remembers separately, in a store you cannot read, move or point somewhere else.

Built-in memory versus a memory you own

Native memory features are convenient and cost nothing. They also have three properties worth being clear-eyed about: the vendor decides what gets remembered, the data stays inside that vendor, and nothing carries over when you leave. For casual use that is a fine trade. For work you are building on for years, it is a lock-in you chose without noticing.

The alternative is to keep the memory outside every assistant and let each one read from it. That requires a protocol both sides agree on, which is where MCP comes in.

What MCP actually is

The Model Context Protocol is an open standard for connecting an assistant to outside tools and data. Anthropic published it, and it has since been adopted well beyond Claude. From the model's point of view, an MCP server is just a set of callable tools: store this, search that.

A memory server exposes something like four tools — write a memory, search memories, list a project, surface what is relevant right now — and the assistant calls them on its own when a conversation needs it. You do not paste context; the model fetches it.

MCP servers come in two shapes, and the difference matters more than any feature comparison:

• Local (stdio). The server runs as a process on your machine. Fast, private, free — and invisible to anything that is not a desktop app on that machine. Not your phone, not a browser tab.
• Remote (HTTP + OAuth). The server lives at a URL. Any client that supports remote connectors can sign in and use it, from any device.

If you want one memory shared across assistants and devices, you want the second kind. If you want one memory on one laptop that never leaves it, the first kind is genuinely the better answer, and it is free.

How a remote memory gets wired up

There is no installation. A remote MCP server is a URL plus an OAuth sign-in, the same flow as connecting a calendar to an app:

1. Paste the server URL into your client's connector settings.
2. The client fetches the server's OAuth metadata and registers itself automatically.
3. You approve access in a browser window, once.
4. The tools appear. The assistant starts calling them when relevant.

Repeat step one in a second client and both now read and write the same memory. That is the whole trick: the memory is a service, not a file. Our own step-by-step version, with screenshots per client, is in the connection guide.

Storing is easy. Retrieval is the product.

Anything can append text to a database. The hard part is answering, months later and in the middle of an unrelated conversation, which five of your four thousand notes matter right now. Get that wrong and you have built an archive nobody reads.

Two failure modes, both common:

• Keyword-only search misses everything phrased differently from how you stored it.
• Vector-only search returns things that are vaguely on-topic and misses exact names, error codes and identifiers — precisely the details you needed.

Serious implementations run both and merge the rankings — reciprocal rank fusion is the usual method — then re-score the shortlist with a reranking model that actually reads query and candidate together. It costs more per query and it is the difference between a memory and a pile.

If you work in more than one language, check this specifically. A stack tuned on English embeddings will quietly degrade on French or German, and the failure is invisible: you just get worse results and assume you wrote the note badly.

Five questions before you commit

1. Local or remote? Decide this first. It eliminates most of the market either way.
2. Where does the data sit, and under which jurisdiction? If the answer is not on the website, assume you will not like it.
3. Can you get it out? Export in a usable format, on demand, without asking support.
4. Hybrid retrieval and reranking, or plain vector search? Ask; it is rarely advertised.
5. What happens at the free tier's edge? Deleted, frozen, or read-only — three very different outcomes.

Where Pryzm sits

Pryzm Memory is the remote kind: one hosted endpoint, OAuth sign-in, shared by every client you connect. It runs on servers in Germany under EU jurisdiction, encrypted at rest, with one database schema and role per customer enforced by PostgreSQL itself. Retrieval is hybrid with a multilingual reranker, across eight languages.

It is also not open source and you cannot self-host it today — which is disqualifying for some people, and we would rather say so here than have you discover it after signing up. We keep an honest side-by-side with the alternatives, including the ones that beat us on exactly those two points.