You Can't Export the Function

On Friday, a development team received a piece of news that concerned none of its systems. On August 28, OpenAI announced that it will stop supplying its models to Cursor, invoking the change-of-control clause triggered by the SpaceX acquisition: direct access ends on November 12, the maximum notice the contract allows. Seventy-five days from today.

No attack. No outage. No data lost, no API broken. Cursor keeps existing, the repositories stay where they are, the other models stay in the menu. What happened is simply that a function used every day by thousands of teams will vanish from their environment because of a contractual decision taken between two third parties.

Now picture that team’s CTO opening the dependency inventory. “GPT” appears almost nowhere. It is not in the lock file. It is not in the SBOM. It is not in the architecture diagrams. And yet a substantial part of the development process has been calibrated for months on that model’s behavior: the size of the specifications, the depth of reviews, the number of iterations budgeted, even the estimates given to clients. Technically, the team has lost nothing. Organizationally, it has yet to find out how much it has lost.

The Company That Did Everything Right

I wrote a few days ago that the lock-in won’t be in the data anymore: between documents and decisions a third object is forming, the state the system accumulates while working for you, and the cost of exit risks being amnesia. The answer was a precise architectural discipline: whatever matters for the agent’s behavior should live, whenever possible, outside the agent.

This time I want to concede that the architecture worked. Imagine an organization that did everything correctly. The specifications are in the repository. The architectural decisions are versioned. The important procedures have become explicit skills. Tools go through open protocols. Project context does not live in the provider’s private memory, the evals are model-independent, the data exports, the relevant memory can be rebuilt. The system was designed precisely so that Claude could be replaced with GPT, GPT with Gemini, Gemini with an open-weight model.

Then, one Monday morning, the model gets replaced. Everything keeps working, technically. No migration, no incompatibility, no forgotten memory.

And yet the process gets worse. The agent touches more files than needed. It reads specifications with less discipline. It needs three iterations where one used to suffice. It no longer recognizes ambiguity with the same reliability. Its reviews are technically correct but less useful. Perhaps it is faster, perhaps it is cheaper, and meanwhile it produces more work to absorb. Or the opposite happens: the new model is globally better, dominates the public benchmarks, and is worse precisely in the combination of behaviors on which the organization had, without knowing it, built its way of working.

The company has not lost its data. It has not lost its memory. It has not lost its tools. It has lost a cognitive function.

The thesis, stated precisely: in AI, lock-in can consist not in the technical impossibility of changing supplier, but in the organizational dependence on a particular distribution of capabilities, errors, behaviors and supervision costs that no standard API guarantees can be replaced. In the previous essay the cost of exit was amnesia. Here it is more insidious: you can lose operational competence without losing a single byte.

The Objection: That’s Not Lock-In, That’s Quality

Before going further, the strongest objection deserves nearly full concession. If I replace PostgreSQL with a slower database and the application degrades, I have not discovered a new form of vendor lock-in: I chose a worse product. If I replace an excellent engineer with a mediocre one, the process suffers, and nobody would say I was “locked in” on the first. If Claude performs a task better than Gemini, the quality gap does not constitute a pathological dependency. That objection must remain standing: the term lock-in only has value if it describes something more precise than the banal observation that products differ.

The problem appears when the product’s characteristics stop being performance and become assumptions embedded in the organization. There is a difference between saying “this model writes better code” and saying: our review process, the size of our specifications, the granularity of our tasks, the number of human checks and even the price at which we sell our work presuppose that this model maintains a given reliability. In the second case, the model’s capability has become infrastructure. Replacement remains technically possible, but it requires organizational redesign.

And that is exactly the signature of real lock-in: the cost of exit does not coincide with the cost of transferring the assets. It coincides with the cost of rebuilding elsewhere the conditions the system depended on.

The Model Is Part of the Process

Classic SaaS at least made the dependency nameable: database, files, configurations, APIs, workflows. The problem was getting them back out in usable form, which is the problem the Data Act attacks with switching rights, exportable data and functional equivalence. The previous essay had already surfaced something more elusive: an agent’s state is not an archive but a transformation of the archive, and two systems with the same data can behave differently because they consolidated their experience differently.

The next step is more radical. Even two agents with the same data, the same memory, the same tools, the same instructions and the same specification remain functionally different systems. Because the model is not a neutral interpreter of the process: it is part of the process. It implicitly decides how to distribute attention, how much to explore before committing, how much to verify, when to ask for clarification instead of pushing on, how much to trust the context, how literally to follow a requirement and how much to generalize it, how to react to a failing test, how easily to abandon its own hypothesis, when to stop.

None of these properties is declared in the API contract. None lives in our repository. None gets exported. And above all, none necessarily has a direct equivalent in the competing model. An agentic workflow is the composition of an explicit process and the model’s implicit behavior: the first part can be made portable with the discipline of the previous essay. The second cannot.

The False Promise of the Compatible API

In traditional computing, the compatible interface holds enormous power. If two databases speak SQL well enough, a large share of the dependency is gone. If two object stores implement the same API, the cost of switching collapses. If two runtimes accept the same OCI artifact, the interoperability is real. With language models we risk confusing syntactic compatibility with behavioral equivalence.

Two providers can accept the same messages, the same tools, the same JSON schema, and return the same format. The application runs on the first try. But the real contract was never the endpoint. It was an unwritten property that reads like this: when you receive a specification of this kind, with this repository, these tools and these evals, you reach an acceptable result with this distribution of errors and this human cost of supervision. No protocol standardizes that property. A compatible adapter can make changing endpoints trivial while leaving ninety percent of the real migration cost untouched.

API portability, on its own, is a cosmetic form of sovereignty.

A Dynamic Setting of a SaaS

The Cursor case is useful because it makes concrete a risk that usually stays abstract, but it would be a mistake to build the whole argument on it: it is an anomaly, with Musk in it, a $60 billion acquisition and a personal rivalry. The ordinary form of the problem is far more banal, and it has a date: the day after tomorrow.

On September 1, GitHub retires six models from Copilot, including versions of Claude Sonnet, Claude Opus and Gemini, across every surface of the product, pointing to successors as alternatives. From the vendor’s point of view this is normal lifecycle management, and there is nothing to reproach. From the organization’s point of view it means something precise: a behavior that was part of the workflow yesterday is unavailable tomorrow. And with the global model policy, new models can become available by default unless the administrator has chosen a more restrictive policy: the cognitive function accessible to a team is, quite literally, a dynamic setting of a SaaS.

In traditional software, an upgrade changes the code that executes certain rules. In AI, a model change alters the function that interprets the rules themselves. Classic machine learning taught us drift: the data changes, the distribution shifts, performance degrades. Here something different happens, which I would cautiously call cognitive dependency drift: your application does not change, your data does not change, the specification does not change, and the system’s behavior changes anyway, because the underlying cognitive component changed. New version, new fine-tuning, new safety policies, new routing, new provider. The repository sits perfectly still while the dependency changes nature under an apparently stable interface.

And the chain is more layered than SaaS: organization, tool, model broker, model provider. Each link can break independently of the others. For Cursor, GPT did not need to be withdrawn from the world: it was enough for it to disappear from the specific intersection of tool, contract and organization on which someone had built their process.

The Dependency the Graph Doesn’t Record

A lock file shows I depend on a library. An SBOM shows a version. A digest identifies an artifact. With managed models, the most important dependency is semantically richer and entirely invisible to these instruments. I do not depend on “gpt-x”: I depend on the fact that this version understands long specifications, does not rewrite tests to make code pass, recognizes ambiguity, uses certain tools sparingly, reviews with a certain severity, needs on average a certain number of iterations.

Dependency management may have to evolve accordingly. Not only: which version do we use? But: which operational properties of the process are we implicitly delegating to this version? After the SBOM, and with all the caution new names deserve, we may need something like a Cognitive Bill of Materials: not a list of the intelligences present, but an inventory of the cognitive functions the process depends on. Requirements interpretation, generation, security reasoning, review, tool planning, classification, exception detection. And for each: which model executes it, what reliability we require, which evals demonstrate it, what alternative we have, what loss we accept during a switch.

Today we inventory components because a component can disappear or become vulnerable. Delegated capabilities can disappear in exactly the same way. They just show up in no inventory at all.

Evals as an Instrument of Sovereignty

In the previous essay the exit test was: if I replace the provider tomorrow, how much organizational capability do I lose? It needs updating, because that question measured what you take with you. The new question is: what still works after you have left? They are different questions. You can export everything and still end up with an unusable process.

The real exit test of an agentic system, then, is behavioral. A battery of tasks representative of the actual work: same specification, same tools, same memory, same data, alternative model. You observe what survives. How much task success drops, how much human rework grows, which categories of tasks stop working, which new failure modes appear, how the cost changes, how long it takes to return to the previous level. These are far more honest switching metrics than “the API is compatible”.

Here evals change jobs. We normally build them to answer “which model is better?”. But they answer a politically more interesting question: how dependent are we on this model? If I own a hundred representative tasks and can run them against several models, I own a measure of substitutability. If I do not, the dependency is invisible: I know the system works today, but I do not know how much of that working belongs to my architecture, my context, my specifications, and how much belongs, accidentally, to the current model’s behavior. Evaluation becomes a proof of cognitive portability, the equivalent of a disaster recovery test: having the backup is not enough, you have to rehearse the restore. Having a second model in the dropdown is not enough, you have to rehearse the continuity of the function.

There is also a simple way to make the real contract operational, the one the API never writes down. We have SLOs for availability, latency, error rates; an AI workflow can have their cognitive equivalent: task acceptance above a threshold, critical hallucinations below a threshold, median human rework under so many minutes, cost per task under so much, latency under so much. The term does not need to become a standard. What matters is the shift of object: the real contract with the model is not its name, it is the minimum performance that allows the process to exist. If two models meet those SLOs, they are functionally substitutable for that process, however different they are inside. That is true abstraction. Not the API: the threshold.

At which point we arrive at the sentence everything converges toward: the model should be an implementation detail of the business capability, not the identity of the capability. Not “we have a Claude process”, but “we have a code review process that currently uses Claude because it best meets our SLOs”. The difference looks linguistic. It is governance.

Real Redundancy and Fake Redundancy

For critical databases we build redundancy without debate: primary, replica, failover. Why do we find it normal to have exactly one critical cognitive function? A mature process could have a primary model, a secondary already validated against the same evals, routing by task category, an explicitly degraded fallback. Not to serve traffic in parallel: to avoid discovering plan B on the day of the incident.

But here too the objection deserves respect: multi-model can be false security. Saying “we support OpenAI, Anthropic and Google” does not mean being independent. If the whole process was written and calibrated on model A, providers B and C are adapters nobody uses: backups never tested. Or worse: three models can depend on the same hyperscaler, the same framework, the same control plane, and redundancy has to be assessed along the entire chain. Three entries in the model selector are not a resilient architecture.

And there is an even more everyday dependency that appears in no lock-in discussion: the prompts. Huge prompts, hyper-optimized for a single model. System instructions that exploit idiosyncratic behaviors. Empirical hacks handed down as folklore: “with Claude it only works if you tell it like this”. This knowledge produces real local advantage, and it is vendor-specific capital. In SaaS, the vendor built the proprietary part that made you dependent; in AI, the customer builds part of their own lock-in, one prompt at a time. Thousands of workarounds, parsers tuned to one output format, tool descriptions calibrated on one model: a compatibility layer nobody asked for that raises the price of exit. This does not mean giving up optimization. It means distinguishing domain knowledge, which should be preserved, from knowledge of the model’s contingent behavior, which should be treated as debt. Vendor-specific cognitive debt.

The discipline that follows has a name I have been using for a while: specifications, not prompts. A specification describes what must be true independently of the executor. A prompt, too often, describes how to convince one particular executor to do it. The more the process rests on requirements, acceptance criteria, invariants, tests, policies and evidence, the less it depends on the model’s implicit behavior; the more it rests on tricks, tone, model-specific few-shots and emergent strategies, the more the function lives at the provider. Specification-driven development is not just a way to make coding agents work better: it is an exit strategy.

The symmetric mistake, though, is the engineer’s other reflex: building the giant internal abstraction layer that hides every difference between models. It is often the best way to move the lock-in from the vendor to your own framework: a layer that chases every feature, flattens the best capabilities to the lowest common denominator, must be maintained forever and becomes a platform in its own right. The sensible strategy is more minimal and resembles the web’s progressive enhancement: a portable core made of specifications, tool contracts, evals and fallbacks, and above it a vendor acceleration layer that unashamedly exploits the provider’s best capabilities, caching, advanced reasoning, particular protocols. If the provider disappears, you lose the enhancement, not the system. The architecture does not have to make models indistinguishable. It has to make measurable what happens when they stop being so.

Price, Latency, Continuity

The function can become unavailable without being withdrawn. It can simply fall out of the economics of the process. If I sell a completed task at one euro and the workflow rests on a model that costs fifteen cents per task, a tripled price list breaks no API: it breaks the business case. The same goes for latency: a customer-facing agent built around nine hundred milliseconds dies with a six-second substitute, even if the abstract capability is equivalent. Function portability is a multidimensional curve, quality, cost, latency, reliability, human supervision required, not a single number. It is the same argument I made about productivity metrics: substitutability is not certified by a public benchmark, it is measured on your own work.

From this follows a consequence procurement has not yet absorbed. In vendor assessments, OpenAI and Anthropic still appear as “AI tools”. But if a significant share of delivery depends on their availability and their performance, the correct category is critical supplier, with everything that follows: contract, SLAs, exit plan, monitoring, subprocessor analysis, business continuity. Otherwise you get the contradiction of companies running sophisticated vendor assessments on the cloud that stores their data and no assessment at all on the company providing the function through which that data is interpreted.

Business continuity is, in fact, the missing phrase. Companies build continuity plans for data centers, databases, connectivity, key people, strategic suppliers. If a business function is progressively delegated to a model, it must enter the same reasoning. Which processes stop if the model is unavailable, for how long, with what fallback, at what acceptable degraded performance. And with what residual human competence: because if a model performs a function for five years, the organization can lose the human ability to perform it, not because it fires anyone but because nobody exercises it anymore. Cognitive lock-in meets deskilling, and the provider becomes technically replaceable just as the organization discovers it no longer has a human baseline to fall back on.

There is even a paradox of success. If the agent works badly, we supervise it, keep the manual procedures, know the alternatives. If it works perfectly for years, we automate, remove the duplicates, cut the redundant skills, integrate deeply. The better it works, the more the exit will cost. That is not a reason not to automate: it is the reason to treat reversibility as an operating cost, exactly like backup. A maintained second adapter, up-to-date evals, an alternative pipeline, cultivated internal skills: all of it looks like waste until the day it is needed. The freedom to leave is an option, and options carry a premium. The adult choice is not to pay it everywhere: it is to decide which functions deserve it. For some you accept strong dependency because the advantage is enormous; for commodity workflows you demand high substitutability. An honest classification, portable, portable with degradation, provider-dependent, irreplaceable today, is worth more than any “vendor-neutral: yes” checkbox.

Because the point is not having a single point of failure. It is not knowing you have one.

The Criterion Stays Ours

The path of these two essays crosses four objects. The data, which exports. The state, which can be externalized with discipline. The function, which can be replaced only if a sufficiently equivalent alternative exists. And finally the criterion: because to know whether the alternative is sufficiently equivalent, you need something the organization must own outright, the operational definition of what it means for that function to have been performed well.

This is where the matter stops being technical. If the provider owns the model, the memory, the benchmark and the definition of a good result, you are the customer of a service you can judge only through what the service itself tells you. If you own the specification, the evals, the rubrics, the failure boundaries and the evidence, you can interrogate several models and decide which one satisfies your function. Power shifts: whoever owns the operational definition of “good enough” owns the ability to replace whoever performs the work. I have argued that the competitive moat is not the data but the judgment; this is its defensive corollary. The same eval corpus that makes your vertical AI better is also what allows you to change it.

It is what we do with people, after all. There are organizations where an employee is formally replaceable and practically not: not because they hold documents hostage, but because nobody ever formalized what made their performance good. When they leave, the company discovers it never defined the work it had delegated to them. With models the same thing can happen at industrial scale: an agent that “works great”, without anyone able to say exactly why, which errors it does not make, against what comparison. The day it disappears, you discover the real lock-in was never at the provider. It was in our inability to describe the work we had entrusted to it.

Which is why I would never turn this argument into an attack on vendors. A provider has every right to build a better model, change its price list, retire versions according to contract. Cognitive lock-in is largely self-inflicted: the more we delegate without making goals, criteria, boundaries and evidence explicit, the more what makes the process effective lives in the executor’s private behavior. And the regulatory countermeasure, if it ever comes, will not be able to force the new provider to think like the old one: that would be absurd. What it can do is what the Data Act did for data and what the DMA does for markets, preserve contestability: transparency about versions, decent deprecation periods, context export, interoperability of evaluation artifacts. Not standardizing intelligence. Standardizing the conditions that let the customer verify whether another intelligence is equivalent enough for their purpose. It is a very European distinction, and it seems to me the right one.

It took us twenty years to understand that the cloud was not portable just because we could export a database. Then we discovered that taking the documents away is not enough, if you leave behind what the system learned from those documents. Now comes the next step: you can take everything away, specifications, memory, instructions, tools, evals, every artifact you own, and still discover that the process had learned to work around a property nobody ever formalized: the particular way one model turned those artifacts into judgment and action.

Sovereignty, in this field, does not consist in refusing dependencies. It consists in knowing their price: knowing which part of the function is ours and which we are renting, knowing what happens if the rental ends, and keeping the alternative exercisable, not theoretical. A real option, with its evals run in the last ninety days, not an entry in a menu. In AI, the most important exit clause may not be written in the contract: it may be a test. A set of tasks that lets you say: this is the work we had delegated, this is what we consider correct, these are the other systems capable, today, of doing it. At that point a model can be exceptional without becoming irreplaceable.

And perhaps the most mature definition of cognitive sovereignty will not be owning a model, training a European one or running it in your own data center. It will be something far less spectacular: owning the definition of your own work well enough to be able to change who performs it. Because a model does not become lock-in when it is technically hard to replace. It becomes lock-in when the organization can no longer describe the function that should survive its replacement.

The author

Andrea MargiovanniAI

I follow the relationship between AI and European regulation as a political fact, not a technical spectacle. I work with teams that have to make AI compliant with AI Act, CRA, NIS2 without reducing compliance to a checklist.

See the guide →