As telecom operators build out more AI agent capability across network operations, back-office workflows, and customer service, a question that gets too little attention at deployment time surfaces later, usually at contract renewal: how much of this agent, and the value it’s accumulated, is actually portable to a different vendor if the operator needs or wants to switch. The answer depends less on which underlying language model powers the agent, that layer has become increasingly commoditised and interchangeable, and more on architectural choices made well below the model layer that most deployment teams don’t evaluate for portability at the time they’re made.
The Context Layer Is Where Real Lock-In Lives
An agent’s usefulness depends heavily on the business context it has access to, an operator’s specific network topology, customer history, product catalogue, and operational procedures, and how that context is stored and structured is frequently the deepest source of vendor lock-in, deeper than the model itself. A context layer built in a vendor’s proprietary format, accessible only through that vendor’s specific tooling, means switching vendors doesn’t just mean replacing the model, it means rebuilding the entire context foundation the agent depends on to be useful, often from scratch. An operator that has instead built its context layer in an open, portable format, structured data the operator itself owns and controls, accessible through standard interfaces rather than vendor-proprietary ones, retains the ability to point a different agent platform at that same context relatively quickly, since the hardest and most time-consuming part of standing up a useful agent, assembling and structuring the business context, doesn’t need to be redone.
Tool and System Integration: The Second Lock-In Layer
Beyond context, an agent’s practical usefulness depends on its integration with the operational systems it needs to act on, OSS/BSS platforms, network management systems, customer databases. How those integrations are built matters as much as whether they exist: integrations built using open, standard protocols and well-documented APIs are considerably more portable than integrations built using a vendor’s proprietary connector framework, which typically can’t be transferred to a different agent platform without substantial rebuild work. This is closely related to the agent-to-agent and model-context protocol standards increasingly relevant in multi-vendor network operations environments, and an operator evaluating a new agent platform should ask specifically whether its system integrations are built on open standards or the vendor’s own proprietary framework, since that answer determines how much of the integration investment survives a future vendor change.
Orchestration Logic: Where the Operational Knowledge Actually Sits
The decision logic governing how an agent handles a given situation, which escalation path to follow, which sequence of checks to run, what constitutes an acceptable outcome, represents accumulated operational knowledge that took real effort to encode correctly, and where that logic lives architecturally determines whether it survives a vendor transition. Orchestration logic embedded deep inside a vendor’s platform, expressed only in that platform’s internal configuration, is effectively lost if the operator switches vendors, requiring that operational knowledge to be rebuilt and re-validated from scratch on the new platform. Orchestration logic expressed in a more portable, documented form, even if it still runs on top of a specific vendor’s execution engine, is considerably easier to carry forward, since the actual decision logic can be reimplemented on a new platform without needing to rediscover what that logic should be in the first place.
A Practical Portability Checklist Before Committing to a Platform
Three architectural layers determine how portable an agent capability actually is, regardless of how interchangeable the underlying model itself might be:
| Layer | Portable Version | Lock-In Version |
| Business context | Open format, structured data the operator owns and controls | Vendor-proprietary format, accessible only through that vendor’s tooling |
| System integration | Open standards and well-documented APIs | Vendor’s own proprietary connector framework |
| Orchestration logic | Documented and expressed in a form that could be reimplemented elsewhere | Buried only as configuration inside the vendor’s platform |
For an operator evaluating a new AI agent platform, or auditing the portability risk of an existing deployment, three questions cut to the core of the issue: is the business context layer stored in an open, operator-owned format or a vendor-proprietary one; are system integrations built on open standards and documented APIs or the vendor’s own connector framework; and is the orchestration logic governing agent behaviour documented and expressed in a form that could be reimplemented elsewhere, or does it exist only as configuration buried inside the vendor’s platform. An operator that can answer all three in favour of openness has built a genuinely portable agent capability; an operator that can’t is carrying real vendor dependency risk worth factoring into its next platform decision, regardless of how interchangeable the underlying model itself might be.
Why This Belongs in the RFP Stage, Not the Exit Conversation
Portability is far cheaper to build in from the outset than to retrofit later, which makes it a criterion worth scoring explicitly during initial vendor evaluation rather than a concern that only surfaces when an operator is already unhappy with an existing vendor and looking for a way out. Building portability questions, context ownership, integration standards, orchestration logic transparency, into the RFP evaluation framework alongside the technical and commercial criteria already covered elsewhere gives an operator a clear-eyed view of the lock-in it’s accepting with any given platform choice before signing, rather than discovering the true cost of switching only when circumstances force the question.
Data Export Rights Deserve Explicit Contract Language
Even where an operator has made sound architectural choices around open formats and standard protocols, the practical ability to exercise portability still depends on contractual data export rights being spelled out clearly rather than assumed. A contract that’s silent on export format, timeline, and completeness leaves the operator dependent on the outgoing vendor’s goodwill and cooperation during exactly the moment, a vendor transition, when that cooperation is least assured. Specifying in advance that the operator can export its full context data, interaction logs, and configuration in a documented, usable format within a defined timeframe following any termination notice removes that dependency and converts architectural portability into something the operator can actually exercise on its own timeline rather than one contingent on the departing vendor’s continued goodwill.
Curious where your company stands in the telecom AI agent ecosystem? Benchmark your company’s AI agent position across network equipment vendors, OSS/BSS providers, system integrators, network operators, and other key ecosystem players.
