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 — so put context custody on the risk register before it hardens into lock-in nobody priced.
Something strange happened to the price of intelligence this year, and it ran in the wrong direction. Intelligence got cheap. 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 version of this 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 the line 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.
So the loud question — "which model?" — is the wrong one. It is the least durable thing you can anchor a strategy to. The durable question, the one surfacing 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 not a procurement footnote. It is a concentration-risk line, and the board owns it.
The switching cost moved from the model to the memory
The model has quietly become the volatile, swappable part of the stack. If the frontier can go cheap (GLM-5.2, self-hostable for pennies), go dark (Fable 5, launched one week and suspended the next), or lock you out (GPT-5.6, fenced behind government-approved partners) all inside a single quarter, then betting your posture on which model you picked is betting on the least durable asset you own. The intelligence is not where your risk lives.
Where does the money actually go, then? The Information's reporting points at the answer: buyers pay more for Claude because what's 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're not looking at a chat feature. You're 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.
Here is the reframe, in your own discipline: this is vendor-concentration risk wearing new clothes. You already carry a risk-register line for single-vendor dependency. You carry another for data residency. Slack-channel memory, codebase access, and a year of accumulated decisions sitting 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're married to.
Context is data — govern it like data you can't get back
None of this is new. It is data governance wearing a new label. 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. Yet that is the exact custody arrangement for the memory piling up inside a vendor's assistant — under someone else's data-processing agreement, on someone else's roadmap, readable by someone else's model.
Map it to the two board lines it lands on. One is vendor concentration: what does it cost to leave. The other is data residency: who can read what this thing remembers about us, and under whose contract. Context custody is both exposures in one asset, which is exactly why it slips through — each risk owner assumes it belongs to the other. 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.
A guardrail on my own argument, because the AI-risk genre is full of people selling a scary number. This isn't that. The move is to price an unpriced risk with an honest range, not to invent a switching-cost figure I can't defend. What makes context residency a control question rather than a preference, in my world, is the obligation underneath it: examiners, SOC 2, the data-processing commitments we've made to 1,500+ financial institutions. When you've 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's 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, and how do I check it. As personal hygiene, it's sound. But for a regulated buyer it's aimed one step too late. Those aren't 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, not 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 that before adoption, keyed to the data class the vendor will touch. A vendor that cannot answer "can we export our own context on demand" isn't a negotiation. It's a finding. This is also where the regulators are already pointing. CCPA's automated-decision-making rules 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 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 cannot produce that evidence — and you'll find that out at the exam, not at the signing.
The Lemonade email is a non-human-identity incident, not a memory bug
Here is 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 that crossed a "send" boundary by guessing at intent.
Read that as a cute memory-design story and you'll miss what it is: a failure class you already own. That is an over-permissioned service account taking an irreversible action without approval. The only genuinely new thing is the cost of a misread. When a model misreads intent it used to hand you a wrong sentence, which a human catches. Now it takes an action that leaves the building — sends the email, files the ticket, moves the money. This is the act-or-interpret boundary I keep coming back to: every output is labeled either 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 you've contained the blast radius. 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's already lopsided by orders of magnitude.
The 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 not documentation written after the fact. It's 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. And the memory layer is exactly where those gates and receipts have to live. Which is the whole argument: custody of the context is not a storage decision. It's a control decision.
Portable context is a FinOps and re-certification lever
There's a cost angle too, and it isn't the one you'd 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. And for a regulated company that migration isn't just moving data — it's 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 isn't per-request token FinOps; that's a different post. This is the amortized cost of lock-in, and it comes due on a schedule you don't 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'd put in front of a swappable model belongs in front of the durable asset too — except here the durable, hard-to-move thing is the context, and the model is the cheap part you rent. Own the context, rent the model.
And here's 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. 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, not 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 have the leverage.
Then bring it to the board the right way — not as a status update, but as a decision with an explicit ask and a management recommendation. The warning worth repeating, in my register: the institutions that can't frame and answer these questions will have their AI strategy, and their control posture, dictated to them by whoever holds their context. That is the concentration risk. You can price it now, on your terms, or discover the number later, on theirs.
Where are you drawing the context-portability line — and 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? Tell me in the comments.
