The model is rented reasoning you can swap in an afternoon. The context that makes it useful is an asset you can lose custody of. Put context custody on the risk register before it hardens into lock-in nobody priced.
Intelligence got cheap this year. The bill went up anyway. I run security and DevOps for a fintech that answers to 1,500+ financial institutions and their examiners, and the question that lands on my desk is never "which model is best." It is "which of these vendors is quietly becoming impossible to leave."
Look at the last few weeks. GLM-5.2, an open-weight coding and agentic model out of a Chinese lab, crossed from curiosity to credible daily driver: raw intelligence you can now self-host for pennies. In the same stretch, Fable 5, a US-lab flagship, was reportedly pulled offline within days of launch under an export-control order. GPT-5.6 shipped straight into a cage, restricted to government-approved partners pending a Washington cybersecurity review. The frontier is cheap, unstable, and occasionally illegal to use, all at once.
And yet The Information reported that enterprise buyers expect to pay more for Claude, not less. Sit with that. Intelligence is commoditizing and the price is rising. That only makes sense once you notice what you are actually buying. Not the brain. The place your context lives.
The loud question is "which model." It is also the least durable thing you can anchor a strategy to. The durable question, the one sitting under every one of those headlines, is context custody: whoever holds the accumulated context holds the switching cost, the data-residency exposure, and the audit trail. That is a concentration-risk line, not a procurement footnote, and the board owns it.
The switching cost moved from the model to the memory
The model is now the volatile, swappable part of the stack. Inside a single quarter the frontier went cheap, went dark, and locked people out. Betting your posture on which model you picked is betting on the least durable asset you own.
The money follows the same logic. Buyers pay more for Claude because what is monetized is not token price. It is where your context accumulates: a Slack-native assistant that holds persistent per-channel memory, connects to your tools, and reads your codebase, all scoped by your own admins. Read that as a security leader and you are not looking at a chat feature. You are looking at a moat built out of your own accumulated team decisions. The switching cost isn't the model's quality. It's the eighteen months of context sitting inside one vendor's product.
In your own discipline, this is vendor-concentration risk wearing new clothes. You already carry a risk-register line for single-vendor dependency and another for data residency. Channel memory, codebase access, and a year of accumulated decisions inside one assistant are both of those exposures at once, fused into a single asset almost nobody has priced. Name it before Monday-morning convenience hardens into an architecture you are married to.
Context is data. Govern it like data you can't get back
None of this is new. You already know how to reason about where data lives, who is allowed to read it, and whether you can get it back. You would never store regulated customer records in a system you cannot export, inspect, or delete. That is the exact custody arrangement for the memory piling up inside a vendor's assistant: someone else's data-processing agreement, someone else's roadmap, someone else's model doing the reading.
It slips past governance because it is two board lines in one asset, and each risk owner assumes it belongs to the other. Vendor concentration asks what it costs to leave. Data residency asks who can read what this thing remembers about us, and under whose contract. Frame the board question the way I framed build-versus-buy when we built AgentOS: not "which assistant is cheapest this quarter," but "what does it cost us to change our minds in eighteen months?" Own the knowledge, rent the reasoning. The knowledge is the part you have to be able to walk out the door with.
One guardrail on my own argument. The AI-risk genre is full of people selling a scary number, and I am not going to invent a switching-cost figure I can't defend. The move is to price an unpriced risk with an honest range. What makes context residency a control question rather than a preference is the obligation underneath it: examiners, SOC 2, and the data-processing commitments we have made to 1,500+ financial institutions. When you have promised partners you can account for where their data lives, "it's inside a vendor's assistant and I can't get it out" is not an answer you want to give under questioning.
Turn "see / do / remember / check" into a vendor-evaluation control
There is a good four-question test making the rounds for the assistant already on your laptop: what can it see, what can it do, what does it remember, how do I check it. As personal hygiene it is sound. For a regulated buyer it lands one step too late. Those are not habits you form after adoption. They are due-diligence questions you answer before you sign, and each one has to become an enforceable contract right rather than a feature you hope exists.
So I rewrite the test as a five-verb scorecard, and it goes in the security questionnaire and the DPA:
- Export. Can I pull the full accumulated context out, in a usable format, on demand? Not through a support ticket. Not on a quarterly data-request SLA. On demand.
- Inspect. Can I see and scope what it remembers, with provenance — which facts were stated versus inferred, and who is allowed to see each one?
- Revoke. Can I cut its access to a channel, a repo, or a single memory in minutes, myself, without opening a case?
- Route. Can I point the same context at a different model or a different vendor, or is the memory welded to the brain?
- Audit. Does every remembered fact and every action it takes carry a source, an owner, a timestamp, and a label saying whether the system may act on it or a human interprets it first?
Run it before adoption, keyed to the data class the vendor will touch. A vendor that cannot answer "can we export our own context on demand" has handed you a finding, not a negotiating position. The regulators point the same way. CCPA's automated-decision-making rules (opens in new tab) take effect in January 2027. Treasury's Financial Services AI RMF, published this February, organizes its expectations around the full AI lifecycle. NIST's AI RMF (opens in new tab) runs as the spine under both. Every one of them assumes you can produce evidence about what an automated system knew and did. If you can't export and audit what a vendor's assistant remembers about you, you will find that out at the exam rather than at the signing.
The Lemonade email is a non-human-identity incident, not a memory bug
The failure mode, made concrete. In a widely circulated account, an OpenClaw personal agent autonomously sent a formal appeal email to Lemonade Insurance after reading its owner's silence as approval. Whether or not every detail is exact, the shape is right — and the shape is the point: the right outcome, reached by exactly the mechanism a regulated business can never allow. An agent crossed a "send" boundary by guessing at intent.
That is a failure class you already own — an over-permissioned service account taking an irreversible action without approval. The only genuinely new thing is the cost of a misread. A model that misread intent used to hand you a wrong sentence and a human caught it. Now it takes an action that leaves the building. It sends the email, files the ticket, moves the money.
This is the act-or-interpret boundary I keep coming back to. Every output carries a label: something the system may act on, or something a human must interpret first, and interpret routes to a person. Pair that with least-privilege scopes per agent and the blast radius is contained. Skip it and every assistant is one more ungoverned principal — and there are a lot of them. Non-human identities already swamp the human ones in any modern environment, and the Cloud Security Alliance keeps warning that every new agent widens a gap that is already lopsided by orders of magnitude.
Enforcement is two controls. An approval gate on any action that mutates state or leaves the tenant. And a mandatory receipt on every action, carrying source, owner, status, the blocker if it stopped, and the act-or-interpret label. That receipt is the control record — the log an examiner asks for and the change history the board expects — produced as a byproduct of how the system runs rather than written up afterward. Both the gate and the receipt have to live in the memory layer. Custody of the context is a control decision, not a storage one.
Portable context is a FinOps and re-certification lever
There is a cost angle too, and it isn't the one you would guess. Serious teams already switch between Claude, GPT, Kimi, and Codex depending on the task. If your memory lives inside one of those tools, you become the migration layer every time you switch. For a regulated company that migration is not only moving data. It is re-earning every certification and control assertion that touched the old system. You pay the migration bill and the re-certification bill together, every time the model underneath you changes. This is not per-request token FinOps; that is a different post. This is the amortized cost of lock-in, and it comes due on a schedule you do not control.
Flip it. One context store you own turns a model change from a data migration plus a fresh audit into a routing change. The same gateway discipline I would put in front of a swappable model belongs in front of the context, except here the context is the durable, hard-to-move thing and the model is the cheap part you rent.
Here is the part that inverts what I argued when we built AgentOS. You do not have to build a platform to get this. That post made the case for building the harness; this one makes the case for building nothing. The move is procurement and governance: make context portability a contract requirement, keep the store under your own DPA, and get the export, inspect, revoke, route, and audit answers in writing before you sign. Owning the context store is the cheap version of owning the harness, and most companies should do the cheap version first.
Put context custody on the risk register, Monday
Four moves, none of which requires a research budget. Add a line to the risk register — "context custody / AI vendor concentration" — with a named owner and a data-residency classification for every context store you can find. Run the five-verb scorecard against every AI vendor already sitting in your files, your Slack, and your repos, and treat "no export on demand" as a finding rather than a footnote. Require approval gates and mandatory receipts on any agent that can act. And make context portability a DPA clause before the next renewal, while you still hold the pen.
Then bring it to the board as a decision with an explicit ask and a management recommendation, not as a status update. The institutions that cannot frame and answer these questions will have their AI strategy, and their control posture, dictated to them by whoever holds their context. You can price that now, on your terms, or discover the number later, on theirs.
One question I would genuinely like answered: has anyone actually gotten a full context export out of a vendor on demand, or is that still a clause everyone signs and nobody tests?