You can swap the model under an agent now. What you cannot easily move is its memory and the skills it wrote

The more interchangeable models become, the more locked in an enterprise can end up.

That sounds backwards, so start with the fact. On October 8, Google described its Gemini agent as an orchestration layer that runs “across our Gemini family of models and Claude models from Anthropic today, and other leading private and open models in the future”, with a routing tool that sends each workload to “the model that delivers maximum performance at the lowest possible cost”. Switching models, in that design, is a setting.

Now the second fact, from the same keynote. The agent “maintains a single set of memories, context, and one personalization graph” across every device and channel, and it keeps four kinds of memory: session, semantic, episodic and procedural, the last “including skills it writes for itself”. Coworker agents get persistent storage of their own.

Put the two together and the switching cost has not disappeared. It has moved.

What accumulates now

A year into running agents like these, the valuable thing in the runtime will not be the model. It will be what the agents have learned and recorded about the organization:

• Memory: what happened, what people prefer, which supplier is always late, which approver wants the summary first.
• Self-written skills: procedures the agent composed to do recurring work. In practice, these become the working description of how a process runs, often more current than the official one.
• Personalization and routing history: which model handled which task, how well, at what cost.

Our view, and it is a view rather than a fact: this is a stickier form of lock-in than data lock-in. Data has formats and export tools. Accumulated agent state is partly generated by the vendor’s own system, stored in the vendor’s format, and its value depends on the runtime that interprets it. A skill written for one runtime may mean nothing to another.

What is easy to move, and what is not

Easy to swapHard to move

1. The modelRouters and multi-model runtimes
2. Prompts and toolsText and standard protocols such as MCP
3. Business definitionsPortable if you own them where they live
4. MemoryVendor format, mixed provenance
5. Self-written skillsEncode how your work gets done

Why this matters more in regulated work

In a bank or a pharmaceutical company, a procedure that is followed is a procedure, whoever wrote it. If an agent writes a skill for itself and then follows it on regulated work, the organization has a procedure that nobody reviewed, approved or versioned. That is a control finding waiting to happen, and it is a portability problem at the same time: the knowledge of how the work is done lives only in the vendor’s runtime.

This extends two positions we already hold. We argued that agent memory is enterprise data storage, with retention and access duties. And that custody is the first question in AI architecture. Self-written skills add a third duty: they are not only data to keep; they are procedures to govern.

What to own, and how to test the exit

Ask for export in a usable form before you sign. Skills as readable text with their history, memory as records with provenance (who or what wrote each item, and when), routing logs per task. “You can export your data” is not the same answer.

Mirror the skills that matter. Treat agent-written skills on important processes like code: copy them into your own repository, review them, version them. That is the same change discipline we recommended for agents as authors of production changes, applied to the agent’s own procedures.

Keep the definitions outside. Business definitions read in place, as the new catalogs from Google and Databricks propose, stay portable because they never moved. Keep it that way.

Own the routing policy. A vendor router optimizes for performance and cost. Your policy may need to put data classification first, as we argued in managing models as a portfolio. The router can execute the policy; the policy should be yours.

Run an exit test once a year. Take one agent’s exported skills and memory, load them into a different runtime or a plain repository, and see what survives. The first time will be humbling. That is the point of doing it before you need to.

The model is becoming the easiest part of the stack to replace. Plan for the parts that are becoming the hardest.