Moving your chats is progress. Moving your AI life is a different problem.
AI services are finally starting to make switching less painful.
Google now lets eligible Gemini users import memory-like context and chat history from other AI platforms, including exports from ChatGPT and Claude.
That is real progress.
For a long time, “portability” often meant little more than downloading a ZIP file and keeping it somewhere safe. Now a major AI provider is treating another provider’s history as something that can become useful context again.
But that raises a more important question:
What exactly has moved?
Export is not portability
ChatGPT can export your history and account data.
Claude can export conversation and user data.
Gemini can export chats, generated media, uploads, Gems data, and other activity through Google Takeout.
Those features matter.
But an archive is not a working AI environment.
OpenAI’s own guidance for moving conversations between personal ChatGPT accounts makes this distinction clear. You can upload an exported conversations.json file into a new chat and use it as reference material.
But OpenAI explicitly says this is not a full migration.
It does not recreate the original chats, sidebar structure, settings, memories, GPTs, files, subscriptions, or workspace access.
You can carry the record of the past without recreating the environment that produced it.
Export is not portability. And portability is not continuity.
There are really four different problems
I think AI portability is easier to understand if we separate four layers.
1. Exportability
You can get your data out.
JSON, ZIP, HTML, media files, or another documented archive format.
This protects against total lock-in, but by itself it is closer to backup than migration.
2. Importability
Another system can accept that exported material.
Gemini’s new cross-platform import flow is an important example.
3. Portability
The imported material remains useful in the destination.
It can be searched, referenced, or reused as context instead of sitting there as an inert archive.
This is where the industry is starting to make real progress.
4. Continuity
You can change the model, provider, application, runtime, or machine and still resume from where you were.
Not merely recover what you once said.
That is a different engineering problem.
Chat history is not current state
Imagine someone who has spent a year building software with an AI assistant.
They successfully move ten thousand old conversations to a new provider.
That is valuable.
But does the new system now know:
- which issue is currently being worked on;
- which pull request is authoritative;
- which specification is current;
- which design was rejected and why;
- which decisions are final and which are provisional;
- which failure must not be repeated;
- what has already been tested;
- what should happen next?
Some of those answers may exist somewhere inside the transcript.
That is not the same as having current state.
A transcript tells a new model what happened.
A continuity layer must also preserve what remains true now, what has been superseded, where a claim came from, and what work is still open.
Chat history is a record of the past. Continuity is the ability to resume from it.
Chat history is not work state
Browser state is a simple example.
When OpenAI ended Atlas, users were told to save important Atlas data before shutdown. Bookmarks would not transfer automatically, open tabs might not transfer, and browser history might not transfer.
Meanwhile, ChatGPT conversation history was separate.
That illustrates a broader point:
The state of an AI-assisted task does not live only in the transcript.
It may also live in:
- open pages;
- files;
- tabs;
- repositories;
- pending actions;
- tools;
- local artifacts;
- external systems.
Chat history is not work state.
Memory is not the whole continuity layer either
Portable memory is important, but memory alone is still too narrow.
A memory like:
The user prefers concise answers.
is useful.
But compare that with:
Approach B replaced approach A because of constraint X. The decision was accepted in issue 123, and later implementation assumes B unless explicitly superseded.
That is not just “memory.”
It is part of project authority and decision state.
A durable AI environment may need to preserve:
- memory and preferences;
- project state;
- decision history;
- provenance;
- unresolved work;
- relationships between records;
- current authority;
- recovery information;
- tool and workflow state.
Remembering who the user is and knowing where the user currently is in a long-running body of work are related problems.
They are not the same problem.
Provider-to-provider portability is still provider-dependent
Gemini’s importer deserves credit because it reduces switching cost.
But look at the architecture:
ChatGPT / Claude
↓
Gemini
↓
Provider C
ChatGPT and Claude data become portable into Gemini because Google built the importer.
If the user later moves again, Provider C needs to understand enough of the previous provider’s exports to make that migration useful.
This is much better than no portability.
But it is still provider-to-provider portability.
Put the canonical state outside the provider
A different architecture is possible:
User-owned continuity
memory / decisions / projects / state
↓
doll
↙ ↓ ↘
Local AI ChatGPT Gemini / Claude / ...
In this model, the canonical copy of durable state does not live inside whichever AI service happens to be active today.
The provider is a capability layer.
It receives the context it needs, does the work it is good at, and can be replaced later.
The continuity layer remains under the user’s control.
If an import format changes, an adapter can change.
If a model is discontinued, another model can be used.
If cloud access disappears, the durable state does not disappear with it.
What doll is trying to separate
This distinction is central to doll.
doll is not trying to become the foundation model that survives forever.
It is trying to make the foundation model replaceable.
The continuity layer belongs on the user’s side:
- memory;
- preferences and personality settings;
- project state;
- DecisionRecords;
- provenance;
- work state;
- user-owned data and recovery state.
The capability layer can change:
- local models;
- OpenAI;
- Anthropic;
- Gemini;
- future models that do not exist yet.
The principle is simple:
Own the continuity. Rent the capability.
Continuity is harder than portability
None of this means continuity is solved.
It creates harder questions:
What deserves to become durable memory?
How should stale information be superseded?
How should conflicting records be resolved?
Which state is authoritative and which state is only evidence?
How should continuity adapt to models with different context windows, tools, safety boundaries, and capabilities?
How much provider-specific state can be translated before the translation becomes fiction?
Those questions are harder than exporting a ZIP file.
That is exactly why portability and continuity should not be treated as synonyms.
From a portable past to a resumable one
The direction of the industry is encouraging.
ChatGPT, Claude, and Gemini all provide meaningful ways to export user data.
Gemini now goes further by importing memory-like context and full chat histories from other AI platforms.
OpenAI provides a reference-based way to reuse exported conversations in another personal ChatGPT account.
This is not evidence that portability has failed.
It is evidence that portability has become important enough for major providers to build it.
The next question is whether users can own the layer above it.
Your AI should not merely let you export the past. It should let you continue from it.
Sources
Google — Import from other AI platforms to Gemini Apps
https://support.google.com/gemini/answer/16868299?hl=enOpenAI — Exporting your ChatGPT history and data
https://help.openai.com/en/articles/7260999-how-do-i-export-my-dataClaude Help Center — Export your Claude data
https://support.claude.com/en/articles/9450526-export-your-claude-dataGoogle — Download your Gemini Apps data
https://support.google.com/gemini/answer/16920332?hl=enOpenAI — Transfer exported conversations between ChatGPT accounts
https://help.openai.com/en/articles/9106926-transferring-conversations-from-1-chatgpt-account-to-another-chatgpt-accountOpenAI — Evolving Atlas into ChatGPT for browser-based agentic work
https://help.openai.com/en/articles/20001371
Originally published on the official doll site:
https://doll.badjoke-lab.com/notes/ai-memory-portability-continuity/
Top comments (0)