AI Portability in 2026: Breaking Up Is Hard to Do

Jon Peck

Oct 21, 2026

1

1

Share

Recently, Mark Cuban asked on X if consumer AI switching costs would ever approach zero without a standard way to export what a model remembers. He pointed out that the more you use a model, the more it stores, making it tougher to switch.

Craig Tracey, founder and CEO of SixDegree, replied on LinkedIn that Cuban was missing the point. He said AI memory today is just a bunch of random facts, like “prefers aisle seats” or “has a dog named Biscuit.” Moving that around is just like relocating a messy junk drawer. Cuban disagreed. He argued that each Claude project has its unique skills, chats, and repeatable tasks; dismissing that as junk is like saying everything in a spreadsheet is trash.

Portability is going to become a big deal in the next 6 to 12 months, not just between providers, but across teams, workstreams, and time. So, what’s the state of portability today? Most of the literal commands you give to AI tools can be transferred easily. But the insights those tools get about you and the work you’ve done together? Not so much. And the companies that could fix this have mostly created pathways that only work in one direction.

Most people still choose one AI tool and stick with it. I think this won’t last, and there are a bunch of reasons piling up.

Local models are improving. More tasks will run on personal computers or private servers, and your context needs to go with it.

Frontier models are leveling out. When the best models are nearly the same in quality, people start choosing based on price and features. If switching isn’t easy or cheap, it limits your options.

Projects grow beyond their limits. A long-term project often breaks into multiple streams, each needing its own context. That’s a portability challenge even if you keep the same vendor.

Tools are evolving quickly. In the past year, Google replaced its Gemini CLI for personal, Pro, and Ultra users with Antigravity CLI. Windsurf turned into Devin Desktop. Cursor dropped its Memories feature while Roo Code shut down. If your context is tied to a single tool, it’s at the mercy of that tool’s updates.

There’s also the slow problem of outdated context.

As projects age, irrelevant facts and old instructions build up, creating clutter. Past attempts become dead ends, which are especially frustrating: when you lose track of what didn’t work, the next time (or the next tool) is likely to try it again. This increases your context window, costing you time and money, while muddying the project’s original goals.

And then there’s the issue of team handovers. Passing an AI-driven project to someone else these days often feels like a scavenger hunt through various vendor platforms, chat histories, dotfiles, and external datastores.

So when I talk about portability, I’m not just talking about swapping one chatbot for another: I mean being able to switch platforms and devices, hand off work to a teammate, and break apart big projects without dragging along the entire convoluted history.

Cuban and Tracey were focusing on different layers of the same problem. Tracey was concerned with learned facts, while Cuban dove in specifically on projects, skills, and chats. All are types of context, but they are very different forms.

Instructions (high portability): AGENTS.md, CLAUDE.md, copilot-instructions.md, GEMINI.md, Cursor rules, Claude and ChatGPT Project instructions

Skills and commands (medium-high): Agent Skills (SKILL.md folders), Copilot prompt.md files, slash commands

Tools (medium): MCP server configs, stored in different files and formats depending on the client

References and artifacts (medium): project knowledge files, generated outputs, links

Memory (low): facts learned and stored by the specific agent or tool

History (very low; easy to export, hard to import): JSONL transcripts, SQLite databases, chat exports

Metadata (very low): the who, what, when, and why of conversations and decisions

The closer a layer is to simple text you wrote, the easier it is to move around. The more the tool generated or understood, the harder it becomes.

Tracey’s junk drawer situation is found in the lower three rows. Most of what Cuban talked about is near the top, with the exception of chat histories.

Good news first: the top layer’s format is fairly consistent, and getting better.

Files like AGENTS.md are used by various platforms like Codex, Copilot, and others, with around 60,000 repositories sharing it. It now has partnerships with the Linux Foundation’s Agentic AI Foundation (AAIF), which includes major players like AWS and Google. The SKILL.md format from Anthropic works in about 46 clients. Almost every tool speaks MCP.

Generating configurations for multiple tools from a single source is also solved, though it’s a crowded field: rulesync has a million npm downloads each month, and convert bidirectionally between 70+ targets. Also available: Microsoft’s APM, Ruler, Vercel’s skills CLI, and skillshare cover much of the same ground. And add-mcp can build native MCP configs for 22 different agents.

But there are some catches. Here’s the short list:

Claude Code might ignore AGENTS.md: if a CLAUDE.md is in your project directory, it ignores all AGENTS.md files. The workaround? A CLAUDE.md that simply imports @AGENTS.md … adding bloat to every single project.

MCP isn’t always universal: some clients want different formats (YAML vs TOML) for their configurations. There are competing formats for packaging skills (Agent Plugins by Vercel vs claude-plugin). And credentials don’t transfer at all.

Skill folders are confusing: some clients check root, some expect a named folder, some check multiple folders, and collisions can occur.

.agents/skills/ is used by Codex, Copilot, Cursor, Gemini/Antigravity, Devin, OpenCode, Goose, Amp, Junie

.claude/skills/ can be understood by Claude Code, Copilot, Cursor, OpenCode, Goose, Amp, Cline

Portability issues really show up with memory and history, where vendor export/import features highlight the problems. Consider what each platform can export and import:

Export: ZIP of conversations, projects, and memory (if allowed by admin)

Import: experimental “Import Memory” (March 2026), where you paste another assistant’s response to a prompt

Export: JSONL transcripts and memory folders

Import: claude import brings instructions, rules, skills, and MCP from Codex, Gemini, and Cursor

Export: session JSONL in ~/.codex/sessions

Import: instructions, skills, plugins, MCP, memories, and 30 days of chat from Claude Code, Cowork, and Cursor

Import: paste a prompt, or import chat ZIPs from ChatGPT and Claude

Export: JSON or links (VS Code chat); CLI sessions (GitHub sync)

Getting raw chat data out is usually doable, but clean memory exports? Not a chance. And none of these platforms has APIs for reading or writing memory.

Transferring memory often involves pasting results in, but it’s like a game of telephone: results vary. This process isn’t true portability.

Plus, memory can shift on its own. Some tools drop unused entries after a while. Whatever you get today is a snapshot of something that changes regularly.

History isn’t in much better shape. Different platforms have various proprietary transcript formats that can change without notice. Moving records to another machine often requires rewriting paths.

Proposed standards are abundant, but actual adoption is the real hurdle. There are lots of solutions out there, but progress is slow:

STS format (Hugging Face): minimal but easy to adopt

Conversation history schema (Data Transfer Initiative): one major adopter

ATIF (Harbor Framework): lossy native-format conversion

Agent File (Letta): bundles prompts, memory, history, and tools; only Letta uses it

Portable Memory (MacPaw): supports supersession and deletion tombstones; five GitHub stars

As for metadata, it’s often just not recorded at all, leaving target platforms unsure who said what, when, and what’s still true. This is the messy reality Tracey was pointing to.

Where vendors end, the open-source world rushes in.

Let’s start with memory. There are tons of external memory systems sitting next to your agents, usually connected via MCP and other tools, and many have stats that would make any project envious. For instance, claude-mem has about 102,000 GitHub stars. Mem0 is close to 67,000 and has raised a hefty $24 million. Hindsight is about 52,000. And agentmemory, which just popped up in February, is nearing 30,000 (with provenance on every memory).

The bright side is many of these are using plain Markdown files with git-style versioning as the go-to method. Projects like Basic Memory, Letta’s MemFS, EverOS, and Serena all work this way, so at least you can open your memories in a text editor.

But there’s a downside: churn. ByteRover archived its repo on September 27. Meta bought Limitless, the brains behind Rewind, last December and pulled the plug on its capture product. A memory layer that you choose to avoid vendor lock-in can become another dead end.

History has its own crowd. SpecStory saves sessions from about 15 agents as Markdown in your repo, and with specstory resume, you can rebuild a session in another agent’s format. Entire keeps transcripts as git refs that move along with your code. Traces offers shared hosting and session resuming across 19-plus agents.

Then you’ve got handoff tools that let you stop in one agent and continue in another. ai-memory combines work from over 20 systems into a shared, git-backed Markdown wiki with typed handoffs: stop in Claude Code, pick up in Codex. cli-continues reads 16 agents and puts a structured summary into the next one. Mem0’s openmemory allows you to move coding sessions back and forth between Claude Code, Codex, and OpenCode. Amp’s Handoff is interesting: you set a goal, and it creates a prompt and a file list for a new thread. It only works in Amp, but it inspired opencode-handoff.

Picking up a session in a different coding agent on the same machine is becoming more common. Most of this action is aimed at developers, though; regular chat users don’t have as many options, mostly browser extensions like MemoryPlugin (costing $89 to $180 a year across 21-plus chat apps) and smaller tools to copy a transcript from one app and paste it into another.

If vendors won’t open things up from the inside, someone else will.

The Data Transfer Initiative put out AI portability principles back in August 2025 and this year has been pushing for both chat and memory import and export. In September, they called for a full agent harness (tools, memory, workspace, and guardrails) to be the unit of portability, which is pretty close to the layered view we talked about. DTI’s members include Amazon, Apple, Google, and Meta, but not Anthropic, OpenAI, or Microsoft.

On another note, the Agentic AI Foundation hosts MCP, AGENTS.md, goose, and A2A, and has Agent Skills in the works. They’ve got groups focused on identity and trust as well as workflows, but none for memory or user context.

Regulators are starting to pay attention, but they’re not very clear yet. GDPR’s portability right includes the data you provided, like your prompts; however, the memory a model infers about you might only falls under the right of access. The EU Data Act’s switching rules, effective since September 2025, cover inputs, outputs, and metadata… but nobody’s definitively figured out if a chatbot counts as a “data processing service.” The Digital Markets Act is the one to keep an eye on. ChatGPT was flagged above the gatekeeper thresholds in July but hasn’t been officially labeled yet. If it is, Article 6(9) would demand real-time data portability. In the US, I haven’t found any laws on chatbot portability or any industry commitments.

Cuban kicked off his post with that question, so here’s my take.

He’s spot on that switching costs aren’t going to drop without standard formats. For the top of the stack, we’