The Lock-in Is Not in the Agent

With every autonomous agent that goes into production in sales, service, or commerce, a concern travels along: does this make us dependent? The question is legitimate — but it almost always aims at the wrong layer. Instinctively, the suspicion points to the visible level: the platform the agent runs on. Yet anyone who suspects vendor lock-in there is looking precisely at the point where the dependency is smallest.

This week, two unrelated events showed where the lock-in actually sits. Both are instructive — precisely because neither of them concerns the agent itself.

What an Agent Is at Its Core

Viewed soberly, an agent is a combination of three components: a logic (what should happen, and in what order), a prompt (how the task is framed and bounded), and a tool connection (which systems the agent is allowed to read from and write to). These three elements are remarkably portable.

An agent logic can be described, documented, and transferred to another platform. A prompt is text. A tool connection increasingly follows standardized interface patterns. Compared with what we know from classic CRM projects — deeply wired customizations, proprietary extensions, integration logic grown over years — an agent is a comparatively light construct. Anyone who has to move an agent from one platform to another faces a manageable problem. Anyone who has to migrate a customization grown over ten years faces a real one.

This defuses the obvious concern: the agent layer is not the place where you lock yourself in. It is the most replaceable part of the entire setup.

The First Real Dependency: The Model

One layer down, things get more serious. An agent needs a model to execute its logic — and that model is not something you control yourself.

This week, a leading model provider had to shut down its most capable model within a matter of hours — not for technical reasons, but on government order. An export-control directive prohibited access for foreign nationals, whereupon the provider deactivated the model for all customers in order to remain compliant. The first to be affected were precisely the users outside the country of origin — including every European company that had built on that model.

The lesson is uncomfortable: the model beneath your agent can be taken away from you without you having done anything wrong, and regardless of how clean your architecture is. The dependency here is not technical — you could technically switch to another model. It is regulatory in nature, and it hits you without warning. For an industrial company embedding agents in business-critical processes, this is the first question that deserves to be taken seriously: what happens to my process if the model is no longer available tomorrow?

The Second Real Dependency: Data Access

One layer deeper lies the hardest dependency — and it is the one least often named in agent discussions.

In the same period, a market-leading ERP system tightened the rules for access to its data. An established data path used for years, through which third-party systems extracted data from the ERP, is now contractually prohibited — and will be technically blocked from the summer of 2026. The restriction explicitly applies not only to the cloud, but also to on-premise and private-cloud landscapes. Anyone who wants to pull data out of the system is funnelled back onto the vendor-provided, vendor-controlled paths.

This is lock-in in its purest form — but it sits neither in the agent nor in the model; it sits at the source. An agent is only as capable as the data it is permitted to access. If access to that data is controlled, the portability of the agent is secondary. You can move the agent at any time — but if it can no longer reach the data in its new location, you have gained nothing.

What This Means in Practice

The three layers produce a clear hierarchy of dependency, and it stands on its head compared with the conventional concern. You are least bound to the agent. You are more strongly bound to the model. You are most strongly bound to access to your own data.

From this follow three questions to examine, for any B2B industrial company working seriously with agents:

1. Do we deliberately keep the agent layer portable — logic and prompt separated from the specific model, so that a switch remains possible without a rebuild?
2. Do we treat model interchangeability as a design principle, rather than stitching ourselves architecturally to exactly one provider?
3. Do we understand our data layer as the actual strategic dependency over which sovereignty is decided?

The last question is the one asked too rarely. In all the attention devoted to selecting an agent, it is easily lost that long-term ability to act is not decided by the agent, but by the data access beneath it.

Anyone haggling over lock-in at the agent platform is negotiating at the wrong table.