AI Memory Is Becoming Portable. Continuity Still Isn't.

Moving your chats is progress. Moving your AI life is a different problem.

Published: 2026-08-12

August 12, 2026

AI services are finally starting to make switching less painful.

Google now lets eligible Gemini users bring over preferences, remembered facts, general context, and full chat history from other AI platforms. The chat-history flow explicitly supports exports from ChatGPT and Claude, and Google says imported chats can be searched and continued inside Gemini. ^[1]

That is real progress.

For years, the practical answer to “Can I move my AI history somewhere else?” was often little more than “Download an archive and keep it somewhere safe.” Now a major AI provider is treating another provider's history as something that can become useful context again, not just a backup file.

But a useful question follows immediately:

What, exactly, has moved?

Export Is Not Portability

ChatGPT can export a ZIP containing chat history and other relevant account data. ^[2] Claude lets individual users export conversation data and account user data. ^[3] Gemini can export chats, generated media, uploads, Gems data, and other Gemini Apps activity through Google Takeout. ^[4]

Those features matter. They reduce the chance that a service becomes the only place where a user's past exists.

But an archive is not yet a working environment.

OpenAI's own guidance for moving exported conversations between personal ChatGPT accounts makes the distinction unusually clear. A user can upload exported conversation JSON into a new chat so ChatGPT can use it as reference. OpenAI explicitly says that this is not a full account migration: it does not recreate the old chats as separate conversations, restore the original sidebar, or move settings, memories, GPTs, files, subscriptions, or workspace access. ^[5]

You can carry the record of the past without recreating the environment that produced it.

Export is not portability. And portability is not continuity.

Four Different Problems

It helps to separate four layers that are often collapsed into one word.

1. Exportability

You can get a copy of your data out: JSON, ZIP, HTML, media files, or another documented archive format.

This is the minimum condition for avoiding total captivity, but by itself it is closer to backup than migration.

2. Importability

Another system can accept the exported material. Gemini's new import flow is an important example because it accepts memory-like context and full chat-history ZIP files from another AI platform. ^[1]

3. Portability

The imported material remains useful in the destination. It is not merely an inert attachment. It can be searched, referenced, or used as context for future interaction.

Gemini is moving meaningfully in this direction. Imported memory is used to help personalize future conversations, while imported chats appear in chat history and can be searched. ^[1]

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.

This is a different engineering problem.

Chat History Is a Record of the Past. Continuity Is the Ability to Resume From It.

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 and which one is obsolete;
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 chat archive.

That is not the same as having current state.

A transcript can tell 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.

Work State Exists Outside the Chat

Browser state provides a simple example.

When OpenAI announced the end of Atlas, it told users to save important Atlas data before the August 9, 2026 stop date. Bookmarks would not transfer automatically, open tabs might not transfer, and browser history might not transfer. ChatGPT conversation history, meanwhile, was explicitly described as separate from Atlas browser data. ^[6]

This is not an argument that Atlas handled migration badly. It illustrates a broader point.

The state of an AI-assisted task does not live only in the transcript. It can also live in open pages, files, tabs, tools, credentials, pending actions, local artifacts, repositories, and external systems.

Chat history is not work state.

Memory Is Not the Whole Continuity Layer Either

Portable memory is another important step, but memory alone is still too narrow.

A memory such as “the user prefers concise answers” is useful and portable.

Now compare it with this:

For this project, approach B replaced approach A because of constraint X. The decision was accepted in issue 123. Later implementation assumes B unless that decision is explicitly superseded.

That is not merely a fact about the user. It is part of project authority and decision state.

A durable personal AI environment may need to preserve several kinds of state:

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 import feature deserves credit precisely because it reduces switching cost.

But look at the architecture.

ChatGPT / Claude
       ↓
     Gemini
       ↓
  Provider C

ChatGPT and Claude exports become portable into Gemini because Google built an importer for them. If a user later wants to move to Provider C, Provider C needs to understand enough of the previous system's exports to make the next migration useful.

This is provider-to-provider portability.

It is much better than no portability. It is still different from user-owned continuity.

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 must survive 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:

a local model;
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 a continuity layer 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?

And if memory, preferences, and working state move to a very different model, in what sense is the result the “same” personal AI?

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 path for reusing exported conversations in another personal ChatGPT account. ^[1] ^[2] ^[3] ^[4] ^[5]

This is not evidence that portability has failed.

It is evidence that portability is becoming important enough for major providers to build it.

The next question is whether the user can own the layer above it.

Your AI should not merely let you export the past. It should let you continue from it.

Notes and Sources

Product behavior and availability described here were checked against the linked official help pages on August 12, 2026. Gemini's cross-platform import feature is limited by account type, age, region, and surface; Google's help page says it is not currently available in the EEA, Switzerland, or the United Kingdom. The distinctions between exportability, importability, portability, and continuity, and the architecture proposed for doll, are this article's analysis rather than terminology claimed by those providers.