Open protocols can connect agents across vendors and clouds, but CIOs still need portable context, controls and business logic to avoid deeper dependencies.
As enterprises connect AI agents across applications, clouds and vendor platforms, open protocols are making it easier for those systems to communicate. But interoperability does not necessarily make the surrounding architecture portable.
Swapping an AI model might be the easy part. For CIOs, the harder question is what happens to everything the enterprise builds around it. Context, memory, identity, integrations, evaluations and business rules can create deeper dependencies than the underlying model itself.
CIOs face a layer-by-layer control decision
Agentic AI is complicating the traditional build-or-buy decision. CIOs now have to determine what belongs under enterprise control and what can safely reside with a vendor.
Enterprises are generally comfortable relying on vendors for foundation models and model safety because most aren't developing their own models, said Lian Jye Su, chief analyst at Omdia, a division of Informa TechTarget. But they increasingly want control over the data, knowledge and business processes surrounding those models.
"What enterprises increasingly want to take control over is the rest of the agentic AI system, from the data and knowledge engineering processes to context and memory, business workflow, and the harness engineering layer," Su said.
That harness engineering layer includes identity management, orchestration and lifecycle management, observability, evaluation and audit trails, according to Su.
The distinction matters because those surrounding layers can become harder to separate from a vendor than the model itself.
"The biggest risk lies in context engineering, memory management, and harness engineering," Su said. "Enterprises must always have visibility into these critical components, as they significantly impact an agent's output."
Ryan Gross, vice president of Anthropic Consulting & Engineering at Caylent, a cloud services provider with a dedicated Anthropic practice, also sees the model as less of a sticking point than the infrastructure surrounding it.
"Swapping the model is rarely where the lock-in sits," Gross said.
Instead, dependency tends to build around integrations, memory and evaluations, he said. Integrations can tie agents to particular tool connectors, gateways and permission settings, while persistent memory can effectively become a store of regulated enterprise data.
Evaluation sets can help enterprises determine whether another model can do the same job. Without one, Gross said, prompts and workflows can become tuned to the behavior of the model already in use.
"Our view is that a real eval is what makes model or platform portability possible at all," Gross said.
Swapping the model is rarely where the lock-in sits.
Ryan Grossvice president of Anthropic Consulting & Engineering, Caylent
Gross pointed to an airline client as one example of how an enterprise can maintain control over those layers. The company is building a shared source of context for its agents, starting with software development, rather than letting that information live within individual agent sessions.
Different teams contribute information to collections that agents access through a common retrieval interface. Business rules are stored as retrievable context, while outputs are written back to the enterprise's store so that information can be reused rather than rebuilt for each interaction.
Identity, model and data access run through the airline's existing AI gateway, Gross said. An evaluation set measures the quality of the agent's work.
"The airline owns the data, the platform, the gateway and every build decision," he explained.
The approach keeps the airline's business context and controls separate from the individual model or agent using them, Gross said.
What CIOs need to keep portable
Model choice is only one part of AI portability. CIOs should know whether the following layers can move with the enterprise:
• Context and memory. The retained information agents use across interactions and workflows.
• Evaluation sets. The tests used to determine whether another model or platform can perform the same work.
• Identity and permissions. The rules defining who an agent represents and what it may access or do.
• Integrations and business logic. The connectors, workflows and policies that turn model output into enterprise action.
• Audit and governance records. The evidence needed to reconstruct behavior, demonstrate compliance and maintain control during a transition.
Interoperability doesn't guarantee portability
Keeping enterprise context under company control becomes more complicated when agents need to work across multiple applications, platforms and vendor ecosystems.
Open protocols such as Model Context Protocol and Agent2Agent can make those connections easier, but they don't necessarily make the underlying architecture portable, Su said. MCP standardizes how AI systems connect to tools and data, while A2A supports communication and coordination among agents.
"A system can be fully MCP- and A2A-compliant and still trap context and policy inside one vendor's control plane," Su said.
Gross sees a similar distinction in enterprise implementations. He said Caylent worked with a global alternative asset manager whose agents operate across three technology stacks and two clouds, with regulated information barriers separating business lines.
"Getting agents to talk to each other turns out to be the easy part," Gross said. "The complex work is identity and access policy enforcement on every hop."
The architecture federates identity across both clouds so each agent call carries who it is acting for, he noted. Information barriers are then enforced on each call so an agent serving one business line can't reach another business line's data by passing the request to an agent on another platform.
Replaceability becomes a resilience issue
The ability to replace a vendor or component isn't only a procurement concern. It can also become a security and resilience issue.
"Replaceability is becoming a resilience and security requirement with increasing cyberattacks worldwide," said Anup Kumar, CEO of Optiv Consulting, the former advisory and consulting business of Optiv Security. Organizations need to be able to isolate a vendor that suffers a cyberattack without losing critical controls, he said.
Kumar said vendor dependency often resides in the prompts, guardrails, orchestration, memory and permissions surrounding the platform. Many of those components also serve as security controls.
Identity is particularly challenging because most identity programs weren't designed for non-human actors operating with delegated authority, Kumar said. Memory can also become an unmanaged data store, while governance brings together policy, logging and threat detection.
But deliberately designing agent architectures so individual components can be replaced isn't yet the norm.
Enterprises can build for that flexibility, but approaches remain fragmented and organizations have varying levels of expertise with agentic systems, Su said. Some are building with open source tools such as LangChain and CrewAI, while others are building directly on SaaS platforms.
"Better-run enterprises build a harness around a measurable workflow with governance first before choosing a vendor platform," Su said.
The choice for CIOs is not whether to own every layer. It is which layers must remain visible, exportable and replaceable if a model, platform or vendor changes.
A replaceable model does not create a portable AI system if the enterprise cannot take its context, memory, evaluations, identity policies and business rules with it. By the time those dependencies become obvious, the architecture might already have made the decision.
Liz Hughes is an award-winning editor and writer covering AI and emerging technology and the former editor of AI Business and IoT World Today.
