The Cost of Leaving

The cost of changing an AI assistant can grow every time the assistant becomes more useful.

It learns how you work, which projects remain unfinished, and which mistakes you have already corrected. Rebuilding that context elsewhere takes attention. A lower subscription price may barely matter if leaving means explaining your working life again.

This creates a particular kind of dependence. The value accumulates through the relationship, while the ability to carry that value elsewhere may remain limited.

My position is that users should be able to move a usable account of their own context between providers. A file export is a necessary starting point. The more demanding test is whether the next system can resume useful work without recreating the same misunderstandings.

Export moves information; migration must preserve meaning

A transcript can tell a new assistant that a conversation happened. It may not tell it which conclusion still governs the work.

Consider a hypothetical project history containing three delivery dates. The first was proposed, the second rejected, and the third approved. A plain archive preserves all three. A useful migration preserves their status and the evidence for that status.

The same applies to preferences. “Keep messages short” might be a general instruction, a request about one email, or an old preference the user later reversed. Text without its scope can become misleading context.

This is why portability needs more than volume. A successful transfer should preserve the distinctions that prevent the new assistant from turning an abandoned idea into an active commitment.

At minimum, I would want explicit instructions separated from inferred preferences, active work separated from completed work, and claims connected to sources where those sources exist. Dates and later corrections matter because context has a useful life.

That is an argument for a migration standard, not a claim that today's assistants already preserve every distinction.

The first practical bridge is already visible

Anthropic's documented memory import and export flow offers a concrete example of movement between assistants. Its import process asks users to obtain memory from another service, paste the exported text into Claude, and review the resulting entries.

The documentation also describes exporting Claude memory. This is a meaningful step toward making accumulated context less captive to one service.

It does not establish that every detail transfers faithfully. A destination system extracts and interprets information; the result needs checking. Documentation of a migration feature is different from a comparative test of migration quality.

I have not conducted such a benchmark here. The argument is that we should make one part of how these products are evaluated.

For example, take a small set of user-approved facts and active tasks, export them through the documented route, and inspect the destination's behavior. Does it honor the current instruction? Does it identify a superseded deadline? Does it ask before acting on information that arrived without a source?

The result should be reported as preserved, altered, omitted, or uncertain. A successful upload is too weak a definition of success.

Where intelligence runs is only part of ownership

In our conversation, Maxime Labonne discussed the practical tradeoffs of running models locally: latency, model quality, specialization, privacy, and the limits of the device.

Local execution creates useful options. Some information can stay on hardware the person controls, and some tasks can continue without a cloud service. Those advantages deserve to be taken seriously.

They do not settle portability. A local application can store important context in an opaque format. A cloud service can provide a clear, useful export. The location of computation and the ability to move accumulated state are separate properties.

Ramesh Raskar's Agent Zero vision adds the other half: personal agents should operate across surfaces and services, with authenticated identities and the ability to interoperate.

Taken together, these conversations suggest a more demanding account of ownership. The person needs practical choices about where work runs and what happens to the useful context when that choice changes.

A system that lets me choose a model but makes my accumulated working state unusable elsewhere has opened one door and left another locked.

Permissions should not travel as hidden authority

Portability has a security problem that a simple “export everything” slogan misses.

An assistant's context can contain information about colleagues, customers, and family members. It can also refer to systems where the user has conditional access. Moving the context should not silently transfer all of that authority to a new provider.

A migration should distinguish the information being carried from the permissions required to use it. Credentials should be reauthorized through the receiving service's normal controls. References to shared records should remain subject to the source system's access rules.

Some material should be excluded or redacted. Some should travel only with a clear record of its origin and permitted use. The user should be able to inspect those decisions.

This imposes friction, but it is specific friction with a purpose. It is very different from making the entire archive impossible to use elsewhere.

The same care applies to stale instructions. A request that was appropriate inside one project can become dangerous if imported as a global command. A destination assistant should treat imported context as information to classify and review, not a bundle of instructions with automatic priority.

An honest migration preserves uncertainty. Where the source cannot establish whether a statement is still active, the destination should not manufacture certainty to make the onboarding feel smooth.

Portability cannot promise an identical mind

The strongest objection is that no export can reproduce the entire service. Different models interpret instructions differently. Providers have different tools, safety constraints, and proprietary systems. Some useful personalization may not be stored as a neat list of facts.

All true. Requiring identical behavior would turn portability into an impossible standard.

The appropriate obligation is narrower: preserve the user-controlled material that can reasonably be represented, explain what has been omitted, and let the person test the consequences before relying on the new system.

Providers need not export model weights or reveal proprietary reasoning systems for this to be useful. A clear account of explicit preferences, active commitments, user-supplied documents, and relevant corrections would already reduce reconstruction work.

Nor should migration require the old provider to guarantee a competitor's results. The source is responsible for a faithful export within its stated scope. The destination is responsible for showing how it interpreted the material. The user needs a way to compare the two.

The goal is useful continuity with visible limits. That is achievable enough to become a product requirement, even though perfect continuity is not.

Make leaving part of the product test

For a team choosing an AI assistant, I would add a small exit exercise to the pilot.

Use a non-sensitive sample project. Establish a few preferences, revise one, complete one task, and leave another open. Then move the permitted context through the supported export and import paths.

Ask the destination to describe what is current, what is uncertain, and what authority it still needs. Measure the human effort required to restore a usable working relationship.

This is a proposed evaluation, not a test result. Its virtue is that it makes switching cost observable before the team has accumulated years of dependence.

The exercise can also improve the original product. If it cannot distinguish completed work from open commitments for an export, it may struggle with that distinction during ordinary use.

The Representation Gap argued that remembered context should remain correctable. Portability adds a second requirement: the value of those corrections should not vanish when the user chooses a different assistant.

Earn the right to keep the relationship

Deep personalization can make an assistant genuinely useful. Easy exit can weaken the provider's hold on the customer. There is no need to pretend those interests always align.

The ethical choice should favor the person's ability to leave with the usable parts of their own working history. A provider can compete through better service, better tools, and better judgment without making reconstruction costs its main defense.

This does not eliminate switching effort. It makes that effort proportionate to real technical differences rather than avoidable opacity.

The right to leave becomes real when you can take enough with you to keep going.

Personal AI should be designed around that standard. The more important the relationship becomes, the less acceptable it is to make the person's accumulated context the price of departure.

Abundance in Practice · Essay 4 of 5. Previous: The Software That Stays · Next: The Robot’s Full Bill.

Abundant intelligence should expand a person's choices, including the choice of who provides it. We keep that question open to scrutiny in the Masters of Automation newsletter.

all signal, no spam.