Pick any week in 2026 and you can find a post about which foundation model just took the crown. Claude shipped a new long-context Sonnet variant; Gemini refreshed its Deep Research mode; Perplexity’s most recent answer-engine model edges out the previous leader on a specific benchmark. The reigning king of frontier AI changes by month, sometimes by week.

That’s not a problem. That’s how a healthy market works.

The problem is the assumption underneath most enterprise AI commitments — that you have to pick the right model first, build everything on it, and accept the lock-in. That assumption was already shaky in 2024. By May 2026, it’s wrong.

The thesis of this piece: a foundation model that’s best today won’t be best in eight weeks. Your context engineering layer should not care.

Pick the model the team wants for the task at hand. Switch when something better ships. Keep the work product, the conventions, the decisions, and the audit trail — the substrate — completely separate from whichever model is doing this turn’s thinking. The substrate is the asset that compounds. The model is the part you replace.

Two axes that keep getting conflated

When people talk about “AI portability,” they usually conflate two different things into one:

Foundation model — the underlying LLM that does the actual reasoning. Claude. GPT. Gemini. Perplexity. Codex. The five names that show up on every benchmark leaderboard for the kind of work most teams do.

Client / surface — the place you happen to be working when you talk to the model. Claude Code in your terminal. Claude Desktop on your laptop. Claude Web in your browser. Cursor in your editor. VS Code with an AI extension. The mobile assistant on your phone.

These are not the same axis. The foundation model is the strategic choice — it determines what the model is capable of, what it costs per token, what its training cutoff is, what guardrails it carries. The client is the tactical choice — it determines what kind of surface you have to work in, what integration points it offers, what hotkeys it gives you.

A team needs both kinds of portability, for different reasons.

Foundation-model portability matters because the leaderboard moves. A workload that runs cheaper on Gemini today might run better on Claude next month. A research task that calls for Perplexity’s grounded retrieval has nothing to do with the coding task that calls for Claude. Locking your team into one model is locking yourself out of the choice.

Client portability matters because the work happens wherever it happens. A practitioner moves through five surfaces in a typical day. Locking the AI experience to one of them — and resetting context every time they switch — is the productivity tax most enterprise AI rollouts are quietly paying without measuring.

The portability story that matters most for compounding value is the foundation-model one. But both have to be solved, and most “AI memory” or “AI workspace” products only solve one — and only weakly.

What MCP changed

The reason foundation-model portability is finally real in 2026 is the Model Context Protocol. MCP standardized the wire format between AI clients and the substrate underneath them. Anthropic shipped it first; OpenAI, Google, Microsoft, and AWS joined the governance under the Linux Foundation; SDK downloads are now in the tens of millions per month. MCP is the TCP/IP moment for agentic AI — the protocol that lets any compliant client talk to any compliant substrate without bespoke integration.

What that means in practice: a context engineering layer that speaks MCP is a context engineering layer that works with Claude and with the next model that ships next month, without per-model engineering work. The substrate stays. The model rotates.

This is the architectural unlock. Before MCP, “model portability” was a slogan you put in a sales deck and quietly defaulted to whichever vendor you started with. After MCP, it’s a default of the protocol.

It also means the “AI memory” products that store conversations and hand them back as pre-baked context are competing in a market that’s about to expect more. If the memory is locked to a single model’s quirks, it’s not portable. If the cycle that produces the context isn’t model-agnostic, it’s a vendor commitment dressed up as a feature.

The portable layer has to be the substrate, not the integration.

What the substrate actually is

When this post says “the substrate,” it doesn’t mean “your old conversations” or “a vector database of every prompt you’ve sent.” Those are storage, not substrate.

The substrate is the part of your work that has durable structure. The conventions your team has converged on. The decisions you’ve made about your stack, your architecture, your tone. The runbooks for how things get deployed. The patterns for how research gets done. The standards your output has to meet. The preferences and corrections you’ve validated over time.

These are not session-bound. They don’t expire when the model context window fills up. They survive model swaps, client changes, team turnover, and product launches. They are the part of your AI-augmented work that compounds.

The asset is the substrate. The model is the engine that uses the substrate to do this turn’s work. Confusing the two is how organizations end up paying for AI three times over.

What practitioners are actually doing now

Watch a serious AI user for a day in May 2026. You don’t see one tool open. You see a constellation:

  • Claude Code for the technical work where Anthropic’s training is strong
  • ChatGPT for the writing where GPT’s voice fits
  • Gemini for the research where its grounded retrieval pulls weight
  • Perplexity for the answer-engine flows it does better than anyone
  • Cursor or VS Code with an AI extension for editing
  • A mobile assistant for the chat that happens away from a keyboard

This isn’t a vendor’s idealized roadmap. It’s how the front of the AI-using market already works. The practitioner switches between foundation models in the same day, sometimes the same hour. If their preferences, conventions, and prior decisions don’t travel with them — if every model resets the context tax — the practitioner pays the tax three to five times every day.

The portable substrate is what makes that pattern sustainable. Same conventions. Same decisions. Same standards. Whichever model the practitioner picks for this turn.

The lock-in trap the AI industry is about to fall into

Every dominant AI vendor in 2026 is racing to build a deeper moat than the protocol allows. Closed memory features in their flagship product. Proprietary context retention that lives only inside their cloud. Custom integrations that work brilliantly in one client and not at all in another. These are rational moves for an individual vendor — they slow churn, they raise switching costs, they tie subscription revenue to a single relationship.

For the customer, these moves are exactly the trap they should avoid.

A team that buys deeply into a single vendor’s closed memory and integration system is committing to that vendor’s training trajectory, that vendor’s pricing trajectory, that vendor’s strategic priorities, and that vendor’s product decisions — for years. When the leaderboard changes, the team can’t change with it without throwing away every substrate they built.

This is the same lesson the cloud market learned in the 2010s. The companies that bought deepest into a single hyperscaler’s proprietary services found themselves locked in when the market matured. The companies that built on portable abstractions — Kubernetes, open standards, multi-cloud architectures — kept their options.

The AI market is approaching the same fork. The portable substrate is the multi-cloud strategy of 2026.

What to build instead

If you’re an enterprise decision-maker reading this, the operational implication is simple:

Build substrate. Don’t bet on a model.

That means picking a context engineering layer that speaks MCP, that operates on every supported client surface, that stores your team’s preferences and conventions and decisions outside any one foundation model, and that doesn’t lose anything when you switch the model underneath it.

It means evaluating AI vendors on their substrate portability, not on which model they happen to use under the hood today.

It means refusing the soft lock-in pitch — “we have great integration with Vendor X” — and asking instead, “what happens to my data, my conventions, and my audit trail when I switch to Vendor Y?”

It means treating the foundation model as the most replaceable component in your stack, and treating the substrate as the most durable.

The framing the AI industry sells you is “pick a winner.” The framing that survives 2026 is “build something that doesn’t need a winner.”

How gramatr fits this

This is a gramatr blog, so let me be explicit about how the product fits the thesis.

The five-stage Loop — Classify, Deliver, Execute, Shape, Learn — runs the same way on every supported AI surface. The substrate it operates on is yours, scoped to your team, governed by your admins, queryable by your audit reviewers. The foundation model is something the Loop talks to; the Loop is not something the model owns.

A practitioner using gramatr can work in Claude Code in the morning, switch to ChatGPT at lunch, run a research flow in Gemini after, check something in Perplexity at the end of the day, and the substrate is the same in every surface. Their preferences are present in every model’s response. Their conventions are enforced. Their audit trail is captured consistently across surfaces. The tax of switching is paid once, when they install — not three times every day.

When a better foundation model launches next month, they use it. The substrate, the conventions, the audit trail, and the productivity floor all come with them.

That’s the operational meaning of foundation-AI portability. Not a marketing claim — a default property of the architecture.

What to take from this

The AI industry’s lock-in moves in 2026 will be quieter than the cloud lock-in moves of 2014. Same shape, less visible. The customers that recognize them early and build on portable substrate will compound; the customers that buy into a single vendor’s closed memory will rebuild every twelve months as the leaderboard shifts.

The model is the part you replace. The substrate is the part that compounds. The cycle that produces and protects both is the layer you license.

If you want to see how the cycle holds up across surfaces, /how-it-works walks through it. If you want to see what twelve months of running it produces in public data, /proof carries the chart. If you want to try it across the AI tools your team already uses, private access is open by application.

The foundation model you start with isn’t the one you’ll finish with. Make sure your substrate doesn’t care.