You explain your pricing to Claude on Monday, explain it again to ChatGPT on Wednesday, and give Gemini a third version on Friday. None of the three can see what you told the others, and by next month none of them will remember any of it.
None of this is a bug. Each assistant keeps its memory inside its own vendor's account, in its own format, and none of them can read another's. If you want all three grounded in the same facts about your company, those facts have to live somewhere all three can reach.
Below are the four ways people handle that, what each costs, and which assistants can connect to a shared store today. We build one of the tools in the last category (Tatara, a document store that agents read and write over MCP), so read that section as a worked example, not a verdict.
Why don't Claude, ChatGPT and Gemini share memory?
Claude, ChatGPT and Gemini don't share memory because memory is a per-vendor product feature, and there is no interchange format between vendors. Claude's memory sits in your Anthropic account, ChatGPT's in your OpenAI account and Gemini's in your Google account. No vendor exposes its memory store to another, and none of them has proposed a standard for doing so.
In practice a second reason matters more. These features are built to remember you: how you like to be written to, what you're working on this week, the phrasing you keep correcting. They're tuned to carry a conversation forward, which is a different job from keeping an accurate record. You can't review anything in them as a document, and nobody ever signed any of it off.
They're also per-user. Whatever Claude has learned about your business in your account, your colleague's Claude hasn't. Every new person on the team starts the same explaining from scratch.
What actually goes wrong when each assistant has its own copy?
When each assistant keeps its own copy, you end up with three versions of your company's facts, no way to tell which is current, and no way to correct all three at once. In practice it goes wrong in four specific ways.
- Drift. You raise a price. Claude has the new number because you mentioned it, ChatGPT has last quarter's, and Gemini has whatever you typed in a hurry. All three answer confidently.
- No provenance. When two assistants disagree, there's nothing to check. You can't see where either version came from, when it was written, or whether a person ever read it.
- Corrections evaporate. You correct the ideal customer profile mid-conversation, get good output, and close the tab. The fix went nowhere. The next conversation, in any of the three, starts from the old version.
- Nobody else benefits. The context you've built up in your own account never reaches the person who joined last week, or the coding agent in someone else's editor.
Three assistants holding three versions of your pricing gives you three chances to quote a customer the wrong number.
What are the real options for sharing context between AI assistants?
There are four ways to share context between AI assistants: paste it in each time, set up each tool separately, rely on each assistant's built-in memory, or keep one store they all read from. They trade effort against how long the context survives.
| Approach | Survives a new chat | Shared across all three |
|---|---|---|
| Paste it in each time | No | Only if you paste it again |
| Per-tool setup (custom instructions, projects, custom GPTs, Gems) | Yes, inside that tool | No, configured separately in each |
| Built-in memory | Usually | No |
| One store the assistants read from | Yes | Yes, where the client can connect |
Paste it into every chat
Pasting works, costs nothing and needs no setup. For one-off context, like a document you want summarised or a thread you want an opinion on, it's the right answer and always will be.
Where it fails is durable facts. Pasted context is write-once, read-once: the hundredth paste costs exactly what the first did, and that cost multiplies with every person and every tool. The version you paste is whatever you happened to have to hand, which is how drift starts. We wrote about that cost separately in Stop pasting context into every chat.
Set each tool up separately
Custom instructions, projects, custom GPTs and Gems are all real answers to this problem, and people underuse them. Context you put in them survives a new chat inside that tool, some of them can be shared across a team, and setup takes minutes.
The cost is three copies you now maintain by hand. A pricing change means three edits in three places, and you'll forget one, usually the tool you use least and a colleague uses most. The ceiling is low too. These fields hold a few thousand characters, which is enough for a page of guidance and nowhere near enough for a company's knowledge.
Rely on each assistant's memory
Memory features pick things up from your conversations automatically, with no setup at all. For working style and recurring preferences they earn their place.
For company facts they're the weakest option. You don't choose exactly what gets stored or when it goes stale, you can't review it as a document or hand it to a new joiner, and none of it crosses to the other two assistants. It's also the option where a wrong fact is hardest to notice, because there's no artefact to read.
Keep one store that the assistants read from
Put the facts in one place outside all three, and let each assistant read from it during the conversation. The context stops being something you carry into the chat and becomes something the chat fetches.
It's the only option here where correcting a fact once corrects it everywhere, and the only one where a teammate's assistant benefits from work you did. The catch is that each assistant has to be able to reach the store, and until recently that meant building a separate integration for every one of them. That part has changed.
What is MCP, and how does it change this?
MCP, the Model Context Protocol, is an open standard for connecting AI clients to outside systems, and it's the reason one context store can now serve more than one assistant. Anthropic published it in November 2024, and it's now used well beyond Anthropic's own products.
A server exposes a set of tools, and a client calls them during a conversation. A remote server lives at one HTTPS address. Any client that speaks MCP can be pointed at that address and authenticate to it, usually over OAuth or with a bearer token, and the server doesn't care which client is calling. The store and the tools stay the same whichever assistant is on the other end.
The part people get wrong is that MCP support is a property of the client, not the model. "Gemini supports MCP" doesn't mean anything on its own: Google's Antigravity CLI supports it, and the consumer Gemini app doesn't. Every vendor has the same split, which is why the next section lists clients rather than companies.
Which assistants can connect to an MCP server today?
Claude can connect to an MCP server on every plan. ChatGPT can on paid plans, once developer mode is switched on. Gemini is split: Google's developer and enterprise surfaces can, and the consumer Gemini app can't.
| Client | Can it reach your own MCP server? | How |
|---|---|---|
| Claude (web, desktop, mobile) | Yes | Custom connectors, on Free, Pro, Max, Team and Enterprise. Free is capped at one connector. |
| Claude Code | Yes | The server is added to the client's MCP configuration. |
| ChatGPT (web) | Yes, on paid plans | Developer mode, available on Plus, Pro, Business, Enterprise and Education. Not on Free. Gives full read and write tool access. |
| Gemini app (gemini.google.com) | No | Its connectors are Google partnerships. There is no self-serve way to add your own server. |
Antigravity CLI (agy) | Yes | Local and remote servers in mcp_config.json, including OAuth. Replaced Gemini CLI on 18 June 2026. |
| Gemini Enterprise | Yes | As a custom MCP server data store. Streamable HTTP only, with no-auth or OAuth 2.0. |
| Other MCP-capable clients | Usually | Most editors and coding agents that speak MCP take the same server URL. |
One practical consequence: hosted clients such as Claude on the web and ChatGPT on the web connect to your server from the vendor's cloud, not from your machine, so the server has to be reachable on the public internet. An MCP server running on your laptop works for a local client and is invisible to a hosted one.
We checked all of this on 29 August 2026, and it's the part of the page most likely to age. All three vendors have moved or renamed these settings in the last year. OpenAI's connector surface has changed its name more than once, and Google retired Gemini CLI in June 2026 in favour of Antigravity CLI. The mechanism is stable even though the menu paths aren't, so treat each vendor's own documentation as the authority on where the setting lives now.
How do you set one up?
Setting up a shared context store takes four steps, and only the last one takes real thought.
- Choose where the context will live. It needs a public HTTPS address, MCP over streamable HTTP (the transport hosted ChatGPT and Gemini Enterprise both require), separate credentials per client so you can revoke one without touching the others, and a storage format you can read yourself and take with you.
- Point each assistant at the same address. In Claude, add it as a custom connector. In ChatGPT, turn on developer mode and add it there. In a CLI or an editor, it goes in the MCP config. So the answer to "how do I give ChatGPT my company's context" is the same as for the other two: one address, added three times.
- Put the durable facts in it. That's less than you'd think, and the next section is the filter.
- Decide what is settled. Somebody has to say which documents are agreed and which are still drafts, or you've built a faster way to spread a bad answer.
Tatara is our version of that store. It serves one MCP endpoint over streamable HTTP:
https://www.tatara.app/api/mcp
That address works from Claude, from ChatGPT in developer mode, from Antigravity CLI and from any other MCP-capable client. A client either signs in through your browser over OAuth or carries an access token. Revoke the token and the client is cut off on its next request. Documents are plain Markdown with YAML frontmatter, with no proprietary format to lock you in.
Two parts of it are there because agents do most of the writing. Every write is stamped with the credential that made it, so an agent's work can't pass as a person's. Every agent write also has to declare a type, title, description and tags, and a rejected write comes back saying what was wrong and how to fix it. The agent corrects itself instead of leaving a half-written document for you to find. The connection docs cover both ways of connecting.
What should actually live in the shared store?
A shared store should hold the facts you find yourself re-explaining. That's the whole test, and it gives a shorter list than people expect: usually ten to twenty documents, not a wiki.
- What you sell, and what you charge for it.
- Who you sell to, and what disqualifies a lead.
- The objections you hear every week, and the answers you've settled on.
- Decisions you've made and the reasoning behind them, not just the outcome.
- How you write: product names, spellings, the words you refuse to use.
What doesn't belong: anything with a short half-life, anything nobody has checked, and anything you wouldn't want an assistant repeating word for word to a customer. A shared store that's mostly stale is worse than none, because all three assistants are then confidently wrong in exactly the same way, and their agreement looks like corroboration.
What sharing context does not fix
Sharing context doesn't make it true. A shared store makes review possible, but it doesn't do the reviewing, and a document nobody has read doesn't become knowledge because three assistants can now reach it.
Nor does it give you one conversation across three assistants. Each keeps its own chat history, and switching tools still means restating what you're doing right now. The knowledge is shared. The thread isn't.
It doesn't remove per-tool setup either. You still add the connector in each client, each vendor gates that step differently, and a client that can't speak MCP leaves you pasting. That list of clients is getting shorter, but it isn't empty.
Once it's running, there's a simple check: ask all three the same question and compare the answers. What do we charge, and who is this not for? If the three answers match, the context really is shared. If they don't, you've found the stale copy, which is worth knowing too.
