---
title: "The Lock-in Is Not in the Agent"
author: "Daniel Gorld"
author_role: "Consulting Director, cbs CX — The cbs Group Salesforce Consultancy"
author_url: "https://cx-waves.com/about"
publisher: "CX-Waves"
canonical_url: "https://cx-waves.com/nodes/lock-in-is-not-in-the-agent"
date_published: 2026-06-14
date_modified: 2026-09-20
language: en
---

# The Lock-in Is Not in the Agent

Source: Daniel Gorld, CX-Waves — https://cx-waves.com/nodes/lock-in-is-not-in-the-agent (published 2026-06-14, updated 2026-09-20)

## Where is the real vendor lock-in when using AI agents?

- **The Agent Itself is Highly Portable**: The logic, prompts, and tool connections of an AI agent are relatively easy to transfer between platforms. Compared to traditional software customizations, agents are light constructs, making their platform a low-risk area for vendor lock-in.
- **Underlying Models Pose Regulatory Risk**: The AI model powering an agent can become a source of lock-in due to external factors like government regulations or export controls. A model can be withdrawn or become inaccessible regardless of technical architecture, impacting agents built upon it.
- **Enterprise Data Access is the Primary Lock-in**: The most significant and often overlooked vendor lock-in lies in access to your own enterprise data. If a vendor controls the pathways to your data, the portability of an agent becomes irrelevant, as the agent cannot function without its necessary data feeds.
- **Strategic Dependency Lies in Data Sovereignty**: The long-term ability to operate effectively with AI agents is determined not by the agent itself, but by the control and accessibility of the underlying data. Vendors who control data access points can effectively lock in an organization, regardless of agent or model flexibility.

## What an Agent Is at Its Core

An AI agent fundamentally combines three components: a logic dictating the sequence of actions, a prompt framing the task's scope, and tool connections enabling interaction with other systems. These elements are inherently portable, distinguishing agents from deeply customized legacy systems. Unlike complex CRM projects with proprietary extensions and deep integrations, an agent is a relatively lightweight construct. Migrating an agent from one platform to another is a manageable task, as opposed to the significant challenge of moving a decade-old software customization. This inherent portability indicates that the agent layer itself is the least likely source of vendor lock-in, making it the most easily replaceable part of an AI setup.

## The First Real Dependency: The Model

A more substantial dependency arises from the underlying AI model that executes an agent's logic. This dependency is not directly controlled by the user. A recent incident highlighted this when a leading model provider had to deactivate its most advanced model due to a government export-control directive, affecting all foreign users. This demonstrates that an agent's foundational model can be suddenly withdrawn due to non-technical, regulatory reasons, even if the user's architecture is sound. For industrial companies integrating agents into critical processes, this raises a crucial question: what is the contingency if the essential model becomes unavailable without warning?

## The Second Real Dependency: Data Access

The deepest and most significant dependency, often overlooked in discussions about AI agents, lies in access to enterprise data. Simultaneously with the model incident, a major ERP system tightened its data access rules, effectively blocking previously established third-party data extraction paths. This restriction applies across all deployment types—cloud, on-premise, and private-cloud—forcing users onto vendor-controlled data access channels. This scenario represents pure vendor lock-in, independent of the agent or model. An agent's effectiveness is directly tied to the data it can access; if that access is controlled or restricted by a vendor, the agent's portability becomes meaningless, as it cannot perform its function in a new location without its data.

## What This Means in Practice

The hierarchical dependencies reveal that conventional concerns about AI agent vendor lock-in are often misplaced. The agent layer itself presents the lowest degree of dependency, followed by the model, with enterprise data access representing the highest and most critical dependency. For B2B industrial companies utilizing agents, this implies three key considerations. First, deliberate efforts should be made to keep the agent layer portable by separating logic and prompts from specific models to facilitate switching without rebuilding. Second, model interchangeability should be a core design principle to avoid architectural reliance on a single provider. Third, and most crucially, the data layer must be recognized as the true strategic dependency where sovereignty is determined. Overlooking data access in favor of focusing on agent selection can undermine long-term operational autonomy.