The Question
The enterprise agent platform market has produced a structural tension that every enterprise buyer must navigate before making a platform commitment: the platforms with the deepest integration into your existing enterprise systems are also the platforms with the most severe lock-in. This is not an accident of product design — it is a deliberate architecture strategy. Platform vendors compete by making their agent capabilities more valuable the deeper an organization embeds them. The result is that the more capable your agents become within a platform's ecosystem, the more costly it becomes to change platforms.
Microsoft Copilot Studio's value comes from its native access to Microsoft 365, Teams, SharePoint, and Power Automate. That access is real, deep, and production-proven — and it is proprietary. The agents you build to those integrations cannot be migrated to Agentforce or a LangChain-based custom stack without rebuilding the integration layer from scratch. Salesforce Agentforce's value comes from native Salesforce object access, Atlas reasoning, and Data Cloud grounding. That value is real — and it disappears the moment you leave the Salesforce ecosystem. ServiceNow's AI Agents are deeply embedded in ServiceNow's workflow data model. That depth is a feature and a constraint simultaneously.
The question is not whether lock-in exists — it does, in every major enterprise agent platform. The question is whether the integration value justifies the lock-in cost, and whether the lock-in can be contractually bounded before the commitment is made.
Vendor lock-in in enterprise agent platforms is not a risk to be eliminated — it is a tradeoff to be understood, quantified, and contractually managed before the first agent goes to production.
Why This Matters Now
Enterprise agent platform lock-in became a board-level conversation in 2025 for two reasons: the scale of the commitment required and the speed at which the market is evolving.
On commitment scale: enterprise agent platform deployments are not point-solution purchases. They are strategic infrastructure commitments that span multiple years, touch multiple business processes, and embed into the daily workflows of significant employee populations. Salesforce's reported Agentforce adoption trajectory — from launch in November 2024 to thousands of enterprise customers by Q2 2025 — represents organizations that are two to three years into a deployment cycle with embedded dependency. Microsoft's Copilot Studio deployments in M365 E3/E5 organizations follow the same trajectory. These are not pilots that can be wound down without organizational disruption.
On market evolution speed: the AI underlying these platforms is evolving faster than any enterprise technology platform in recent history. The model capabilities available in GPT-4 at launch in 2023 are materially different from those available in GPT-4o in 2024 and GPT-5 in 2025. Enterprise agent platforms that do not give their customers access to the latest model capabilities — because they lock agents to their own model infrastructure — create a capability ceiling that compounds over time. An organization locked into Agentforce's Einstein models cannot access Claude's extended context window or a domain-specific fine-tuned model without leaving the platform.
The 2025 push by multiple platform vendors to adopt Anthropic's Model Context Protocol (MCP) — an open standard for tool connectivity — introduced an emerging but meaningful variable into the lock-in conversation. Platforms implementing MCP create a degree of tool portability that was previously unavailable: tool integrations built to the MCP standard can, in principle, be used across different agent frameworks and platforms. The pace of MCP adoption across enterprise platforms will be a significant lock-in differentiator over the next 18–36 months.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Enterprise Agent Platform CURVE™ Report evaluated lock-in severity across the major enterprise agent platforms using a five-factor framework: platform-specific tool connector dependency, model selection flexibility, memory and state data portability, workflow integration portability, and contractual exit provisions.
Microsoft Copilot Studio and Salesforce Agentforce scored highest on lock-in severity — not because they are poorly designed, but because their integration depth is genuinely high and the proprietary nature of those integrations creates correspondingly high migration costs. ServiceNow AI Agents scored similarly high on lock-in severity within the ITSM context. Google Vertex AI Agent Builder scored lower on lock-in severity due to its more standard API-based integration approach, at the cost of lower native integration depth.
The open-source framework path (LangChain/LangGraph, AutoGen, CrewAI) scored lowest on lock-in severity, with the primary lock-in risk being model provider dependency rather than platform dependency. Custom stacks built on OpenAI APIs can switch to Anthropic or Google APIs at the cost of prompt engineering changes; custom stacks built on LangGraph can switch underlying models with framework-level configuration changes.
The CURVE™ data identified three organizations that had executed enterprise agent platform migrations in 2024–2025. All three reported migration costs significantly exceeding initial estimates, with the primary cost driver being tool integration reconstruction rather than agent logic migration. The median migration cost across the three cases was 2.3x the original agent development cost.
The full vendor rankings are in the 2026 Stackcurve AI Enterprise Agent Platform CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most enterprise agent platform evaluations address lock-in superficially — a single question in the RFP about "data portability" and a review of the data export clause in the contract. The gap most buyers miss is the specificity of the lock-in mechanisms and the compounding nature of integration debt over time.
Platform-specific tool connectors are the primary lock-in mechanism — and they are not equivalent to standard APIs. Copilot Studio's SharePoint connectors give agents native read-write access to SharePoint content with Microsoft identity-based access control. The Salesforce object access in Agentforce gives agents native access to every Salesforce object, field, and relationship in your org's data model without API credential management or rate limit handling. ServiceNow's workflow integrations allow agents to trigger, update, and close ServiceNow workflows as first-class platform operations. These are genuine capabilities — and they have no standard-API equivalents. An agent migrated off these platforms must rebuild these integrations against the platform's REST APIs from scratch, with all the associated credential management, error handling, and rate limit complexity that the native connectors abstract away.
Model dependency creates a capability ceiling that compounds with model advancement. The AI model landscape is advancing faster than any enterprise technology stack in recent history. Platforms that control model selection on behalf of their customers will periodically update to newer models — but they will not necessarily adopt every model relevant to every customer's use case. An organization with a use case that benefits from Claude's extended 200,000-token context window cannot access that capability within Agentforce. An organization that needs a self-hosted, domain-specific fine-tuned model for data sovereignty reasons cannot use that model within Copilot Studio. The model capability ceiling imposed by platform model control is not visible on day one — it becomes visible when the use case evolves to require a capability the platform doesn't expose.
Memory and state storage lock-in is underweighted in most evaluations. Agent memory — the history of interactions, context accumulation, and learned preferences that make long-running agent deployments more capable over time — is stored in platform-specific formats. Salesforce Data Cloud stores Agentforce memory in Salesforce-native data structures. Microsoft stores Copilot Studio conversation history in Microsoft's conversation storage. This data is not exportable in standard formats in most current implementations. An organization that has deployed an Agentforce-based customer service agent for 18 months has 18 months of customer interaction history, agent learning, and state data stored in Salesforce infrastructure. That data is part of the lock-in, and most organizations do not evaluate its portability before deployment.
The MCP factor is emerging, not mature. Anthropic's Model Context Protocol is gaining adoption as an open standard for tool connectivity. Platforms implementing MCP allow tool integrations to be portable, in principle, across agent frameworks — reducing but not eliminating tool connector lock-in. The operative qualifier is "in principle." MCP implementation quality varies across platforms, and the MCP ecosystem's coverage of enterprise system connectors is not yet comprehensive. MCP is a meaningful lock-in reducer for organizations deploying agents in 2025–2026, but it should be evaluated as a supplementary risk mitigation rather than a complete lock-in solution. Ask each vendor specifically which of their connectors implement the MCP standard and verify that claim against the MCP registry before treating it as a migration capability.
Questions Your Buying Team Should Be Asking
1. If we decide to migrate this agent to a different platform in three years, what is the migration cost — and can you walk us through the migration path?
This question will be uncomfortable for most vendor sales teams to answer confidently. The discomfort is informative. A vendor with a confident, detailed answer has thought about portability and may have designed for it. A vendor that cannot answer has not. The absence of a clear answer is itself an answer: migration from this platform is expected to be painful, and the vendor has not invested in making it otherwise. Require a written migration path document as part of the vendor evaluation package.
2. Which of your tool connectors implement the MCP standard, and what is your MCP adoption roadmap for the next 18 months?
MCP adoption is an indicator of a vendor's commitment to interoperability. Verify MCP claims against the published MCP registry and ask for specific connector names, not a general statement about MCP support. Request the vendor's MCP roadmap for connectors that are not yet MCP-compliant. A vendor with a detailed MCP roadmap is signaling an interoperability commitment; a vendor with vague MCP claims is signaling a marketing response.
3. Can we bring our own model — and if so, which models are supported and on what timeline for new model support?
If your use cases have current or anticipated requirements for specific models, evaluate model flexibility before shortlisting. Ask specifically: Can we use Claude 3.5 Sonnet? Can we use a self-hosted Llama 3 model? Can we use a domain fine-tuned model we've developed internally? For each requirement that is not supported, evaluate whether that restriction is likely to become a capability constraint within your planning horizon.
4. What are our data export rights — and what format is exported data in?
Data export rights must be specified in the contract, not assumed from the vendor's general terms. Specifically: What agent configuration data is exportable? What conversation history and agent memory is exportable? In what format is it exported (proprietary format, JSON, CSV)? What is the export mechanism (self-service API, support ticket, account team request)? Data export rights that require a support ticket and a two-week SLA are practically less useful than self-service API access — particularly for a migration that requires exporting significant data volumes.
5. Does the contract include an interoperability commitment — specifically, a commitment to maintain API access to our data throughout the contract term?
Some enterprise agent platform contracts include provisions that restrict API access or data export capabilities in certain circumstances — for example, after a contract dispute, during a transition period, or after contract termination. An interoperability commitment provides a contractual guarantee that you retain programmatic access to your data throughout the contract term and for a defined period after termination. This provision is especially important for organizations with regulatory data retention requirements, where losing access to agent history data at contract termination could create compliance exposure.
The Stackcurve Take
Vendor lock-in in enterprise agent platforms is not a problem to solve — it is a tradeoff to manage. The platforms with the deepest enterprise integrations offer the highest deployment value and the highest lock-in cost. That tradeoff is not inherently wrong. Organizations that are deeply committed to the Microsoft ecosystem have valid reasons to build on Copilot Studio, accept the lock-in, and capture the integration value. Organizations deeply committed to Salesforce have valid reasons to build on Agentforce. The mistake is accepting that lock-in without understanding its scope, quantifying its cost, and negotiating contractual protections that bound its worst implications.
The practical checklist before any enterprise agent platform commitment: conduct a migration cost estimate (assume 2–3x the initial development cost for a full migration); evaluate MCP adoption per connector, not per platform; negotiate explicit data export rights with API access and format specifications; get the model flexibility commitment in writing; and run the lock-in question by your platform vendor before signing, not after.
The organizations that will have the most strategic flexibility in 2028 are the ones doing this analysis in 2025–2026 — before the integration debt accumulates and the switching cost becomes prohibitive.
The 2026 Stackcurve AI Enterprise Agent Platform CURVE™ Report covers vendor lock-in analysis, MCP adoption tracking, and contract negotiation frameworks for enterprise agent platform commitments. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.