--- title: "AI-Ready Context for Telecom: Should You Build or Buy?" url: "https://atlan.com/know/ai-agent/context-layer-for-telecom/" description: "Telecom AI agents fail from OSS/BSS fragmentation and CPNI compliance load, not weak models. See when to build an AI-ready context layer, and when to buy one." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-07-29" updated: "2026-07-29" --- --- Top-quartile AI-adopting telecom operators see 4 to 7 percentage points higher EBITDA margin than the median, according to McKinsey's 2025/2026 analysis of telco AI leaders. Telecom hits the AI-context wall faster and harder than most verticals: OSS/BSS fragmentation, real-time network telemetry running against batch-oriented billing cycles, multi-vendor and multi-region system sprawl, and a stack of CPNI, GDPR, and data-residency obligations pile on top of the same "what does customer mean here" problem every industry faces. Telecoms weighing this question are choosing between paths that already include Ericsson-style OSS/BSS platforms, TM Forum's Open Digital Architecture standards, Databricks or Snowflake-based custom builds, and unified context layers like Atlan. This guide covers two flagship use cases, NOC copilots and churn-prediction agents, where the gap shows up first, how native OSS/BSS tools compare to a unified context layer, when building your own is genuinely the right call, and why most telcos underestimate the multi-year cost of building and running that path alone. | Industry | Telecom (mobile, fixed, cable, MVNO) | |----------|---------------------------------------| | Key regulations | CPNI (US), GDPR (EU subscribers), Singapore IMDA agentic-AI framework (2026) | | Primary stakeholders | Chief Data Officer, CTO, VP Network Operations, Data Engineering Lead | | Typical data challenges | OSS/BSS fragmentation, real-time telemetry vs. batch billing cycles, multi-vendor and multi-region sprawl | | Data maturity level | Most telcos are piloting single-team agents (NOC or churn), not yet sharing context across them | See context agents live Watch how a governed context layer connects OSS, BSS, and network data to AI agents in real time, across systems and vendors. Watch a live demo --- ## Why does telecom need an AI-ready context layer? Telecom AI agents fail for a structural reason, not weak models. A NOC copilot, a churn-prediction agent, and a customer-service agent can each run on a capable model and still act on conflicting information, because network inventory, billing and CRM, and order management systems each define "subscriber," "service," and "account" differently, without a shared [governed context layer](https://atlan.com/know/agent-context-layer/) to settle it. This is the same ambiguous-definition problem the [context layer for retail AI](https://atlan.com/know/ai-agent/context-layer-for-retail-ai/) and [context layer for financial services](https://atlan.com/know/context-layer-for-financial-services/) pages describe, applied to a legacy stack that runs deeper: cloud, on-prem, and acquired systems, often all at once. ### Fragmented OSS/BSS and network telemetry mismatch Most billing and CRM systems still load on a nightly batch cycle, while network alarms and topology data integrate in seconds to minutes through the OSS layer, according to Wavelo's 2026 analysis of AI-ready OSS/BSS architecture. An agent that blends both without reconciling the two speeds inherits whichever timestamp is fresher, not the one that is correct, the same [context freshness](https://atlan.com/know/ai-agent/context-freshness/) gap that breaks agents everywhere, except telecom runs it across more systems and faster-moving data than most. ### Multi-vendor, multi-region system sprawl According to Microsoft's 2025 analysis of AI's impact on OSS and BSS, telecom operators often run Ericsson, Nokia, or Huawei OSS stacks alongside Salesforce or ServiceNow BSS layers, frequently inherited through acquisitions rather than chosen deliberately. Each platform is internally consistent and mutually incompatible with the others, a version of the [context portability](https://atlan.com/know/ai-agent/context-portability/) problem that worsens as the vendor count grows. Vamsi Duvvuri, Americas TMT AI Leader and Managing Director for AI and Data at EY Americas, put it directly: "AI transformation rarely fails from a lack of ambition. It fails from a lack of architecture and alignment across workflows, people and systems." Ibrahim Eldeftar, Global Head of Solution Line Cognitive Software and Services at Ericsson, frames Ericsson's own strategy as "AI for networks and networks for AI," describing the two priorities as inseparable given rising complexity across radio access, core networks, and operations, according to Fierce Network's MWC 2026 coverage. Microsoft's own telecom content frames this same problem as an [ontology layer](https://atlan.com/know/context-graph-vs-ontology/), different vocabulary, the same fix. ### CPNI, GDPR, and the 2026 agent-specific regulatory wave US carriers must certify CPNI compliance annually, with the 2026 deadline requiring telecom carriers and interconnected VoIP providers to certify their customer data privacy and security controls, according to The CommLaw Group. That framework, like most telecom compliance regimes, assumes a human reviews a screen before data moves. Singapore's Infocomm Media Development Authority launched the first governance framework written specifically for autonomous AI agents in January 2026, according to Bronston Legal's analysis, the first regulatory signal that human-review-era compliance does not reach an agent chaining tool calls across provisioning, billing, and network systems on its own. [AI agent governance](https://atlan.com/know/ai-agent-governance/) and [GDPR compliance for AI agents](https://atlan.com/know/ai-agent/gdpr-compliance-for-ai-agents/) both need to extend to this agent-driven pattern, not just the human-facing one. | Regulation | What it requires | Data implication | |------------|-------------------|-------------------| | CPNI (US) | Annual certification that carriers protect customer proprietary network information, due March 2, 2026 | Agents touching subscriber data need access controls checked at query time, not just certified once a year | | GDPR (EU subscribers) | Lawful basis for processing and data minimization for EU telecom customers | Cross-border subscriber data needs the same portability and versioning a shared context layer provides | | Singapore IMDA agentic-AI framework (2026) | First regulatory framework written specifically for autonomous AI agents | Assumes agent-driven, not human-reviewed, data access, a gap most existing telecom compliance regimes do not cover | For telecom specifically, the model choice is secondary to whether OSS, BSS, and network systems agree on what a subscriber, a service, and an active connection actually are, before any agent is asked to act on that data. ![Fragmented telecom OSS, BSS, and network systems feeding AI agents inconsistently versus a unified governed context layer](/img/context-layer-for-telecom-1-fragmented-systems.webp) *The same OSS/BSS, network, and policy sources produce conflicting answers when an agent queries them separately, and one consistent answer once they're reconciled through a governed telecom context layer. Source: Atlan* --- ## What are the key use cases for build vs buy in telecom AI context? Two telecom AI agent categories expose the same context-fragmentation failure in different vocabulary, NOC copilots and churn-prediction agents, and a third, customer-service agents, shows it again at smaller scale. ### NOC copilot: network operations agents **The challenge:** A NOC copilot recommending a network fix pulls from alarm feeds, topology data, and field-workforce tools with mismatched refresh cycles and inconsistent asset IDs across systems. Practitioners commonly describe this pattern as "a chatbot over log files," not a real agent, because there is no observability into what recommendation the agent actually acted on. **The solution:** Governed network topology and inventory context, with lineage from the raw network event to the agent's recommendation checked at query time, closes that gap. According to Ericsson's 2025 analysis of multi-agent AI in OSS/BSS, this kind of grounded, traceable recommendation is what separates a production NOC agent from a demo, the same distinction a [knowledge graph for AI agents](https://atlan.com/know/ai-agent/knowledge-graph-for-ai-agents/) supports that an [agent context layer compared to plain RAG](https://atlan.com/know/ai-agent/agent-context-layer-vs-rag/) makes explicit: lineage and review, not just retrieval. **The outcome:** A wrong recommendation traces back to the source system that caused it in the flow, not in a postmortem written after the fact. ### Churn prediction: subscriber retention agents **The challenge:** Basic churn models degrade quickly because "churn" itself is defined inconsistently. SIM inactivity, contract termination, port-out, and silent churn all get conflated across CRM, billing, and network systems, so a model trained on one definition scores against another. **The solution:** One governed, certified definition of churn that every agent references, the same [semantic layer for AI agents](https://atlan.com/know/ai-agent/semantic-layer-for-ai-agents/) approach used elsewhere, closes the gap. According to McKinsey's telco reinvention research, AI-driven approaches to churn and customer retention report reductions of 10 to 25%, and the shift for leading operators is moving from pure prediction toward prescriptive next-best-action. **The outcome:** Retention agents act on the same subscriber-status definition marketing, billing, and service teams already use, with no reconciliation step after the model scores. ### Customer service and subscriber-support agents **The challenge:** A support agent answering "why was I charged twice" needs billing, provisioning, and network-incident data reconciled in real time, not three separate lookups across systems that were never built to talk to each other. **The solution:** The same governed [context repository](https://atlan.com/know/ai-agent/context-repository-for-ai-agents/) serving NOC and churn agents extends to support, so a fourth team does not rebuild subscriber context from scratch, the [agent sprawl](https://atlan.com/know/ai-agent/agent-sprawl/) pattern that shows up whenever agent context isn't shared. **The outcome:** Fewer escalations caused by the agent working from a stale or partial subscriber record. Three agents, three vocabularies, and one shared root cause: without a governed [context versioning](https://atlan.com/know/ai-agent/context-versioning-for-ai-agents/) history behind each definition, every team pays the fragmentation cost separately instead of once. --- Build your AI context stack Get the blueprint for connecting OSS, BSS, and network context across systems, with a four-layer architecture from data foundation to agent orchestration. Get the stack guide --- ## How do telecom-native OSS/BSS tools compare to a unified context layer? Ericsson, Amdocs, Netcracker, and TM Forum-aligned OSS/BSS platforms already handle a great deal well within their own system boundaries. The gap shows up at the seams between them, the same distinction that separates [agent context layer tools](https://atlan.com/know/ai-agent/agent-context-layer-tools-compared/) built for cross-system delivery from a system that only serves its own users. **What native tools provide:** real-time network topology within their own system, structured billing and provisioning data, and vendor-specific automation across Ericsson, Amdocs, and Netcracker deployments. **Where gaps remain:** | Capability | Native tools | What's missing | |-----------|-------------|-----------------| | Cross-system entity definition | Each OSS/BSS system defines subscriber, service, and account independently | No single governed definition every agent can query | | Real-time and batch reconciliation | Native tools reconcile within their own refresh cycle | No mechanism to reconcile real-time telemetry against batch billing cycles across systems | | Policy enforcement at query time | Native tools enforce rules for human users through their own interface | No check for CPNI, GDPR, or residency status before an agent acts | | Lineage from network event to agent decision | Native tools log transactions inside their own system | No trace from a wrong recommendation back to the source system that caused it | Closing these gaps takes a layer that sits above any single OSS/BSS system, the same principle behind [agent context layer design](https://atlan.com/know/ai-agent/agent-context-layer-design/) more generally. CodiLime's guide to build vs. buy in network automation makes a related argument, that differentiation has moved to the surrounding infrastructure, data, tools, and guardrails, but it stops short of the context-layer-for-agents framing this decision needs. Omdia's analysis for TM Forum of agentic AI in OSS/BSS reaches a similar conclusion from the vendor side: the risk concentrates at the boundary between systems, not inside any one of them. The case for a [context layer for AI agents](https://atlan.com/know/context-layer-for-ai-agents/), compared against a plain [knowledge base](https://atlan.com/know/ai-agent/agent-context-layer-vs-knowledge-base/), does not change by industry, only the entities being unified do. Native OSS/BSS tools are not the problem. The seams between them are, and no single-vendor platform is built to own the seam. --- ## When does it make sense to build your own AI-ready context layer in telecom? Buy is the stronger default for most telecoms, but three specific conditions genuinely favor building instead, and an honest page names them rather than dismissing them. Genuine telecom-specific ontology modeling is a real competitive differentiator in some operators, not a generic data model, and building it in-house is the point rather than a workaround. Sovereignty and data-residency requirements push some telecoms toward on-prem or hybrid builds regardless of vendor claims, a legitimate driver rather than a fear-based objection. TM Forum's Open Digital Architecture and Shared Information/Data Model represent a genuine middle path, an industry-standard, vendor-neutral data model that is neither pure custom build nor a single-vendor buy. | Signal | Favors build | Favors buy | |--------|---------------|------------| | Ontology differentiation | Telecom-specific entity model is a genuine competitive edge | A generic subscriber and service model is good enough | | Sovereignty or on-prem requirement | Data-residency rules require on-prem or hybrid regardless of vendor | No hard residency constraint blocking a managed layer | | TM Forum ODA/SID path | A standards-based, vendor-neutral build is already underway | No existing ODA/SID investment to extend | | Time to value | A multi-year runway is acceptable | Agents need governed context in months, not years | | Ongoing operating cost | A team is staffed to run ingestion, governance, and certification indefinitely | No dedicated platform team to own that loop long-term | This mirrors how the [enterprise context layer](https://atlan.com/know/context-layer-enterprise-ai/) pattern holds regardless of industry: model choice is secondary to whether context reaches every agent as one governed source. The [cost to run AI agents at scale](https://atlan.com/know/ai-agent/cost-to-run-ai-agents-at-scale/) compounds every year the ingestion loop stays in-house, and few operators plan for [scaling an agent context layer](https://atlan.com/know/ai-agent/how-to-scale-agent-context-layer/) across B2C, B2B, and wholesale lines at once. Even where building is defensible, most telecoms underestimate that multi-year, cross-team operating cost, which is where the buy-side case fits, covered next. Build is a legitimate answer to a specific question. It is a poor default answer to the general one. --- ## How Atlan approaches AI-ready context for telecom Atlan implements the buy-side answer to telecom's build-vs-buy decision: an Enterprise Data Graph that unifies OSS/BSS, network, and customer systems into one governed source every agent queries, instead of leaving each system to hold its own version of "subscriber" or "service." - **Enterprise Data Graph**: unifies OSS/BSS, network, and customer systems into one living graph instead of leaving each to hold its own version of a subscriber or a service. - **Governed business glossary**: one certified definition of "active subscriber," "churn," and "service outage," directly resolving the ambiguous-churn-definition problem from the use-case section above. - **[Context Repos](https://atlan.com/know/ai-agent/context-repository-for-ai-agents/)**: versioned, workflow-specific context bundles, one for the NOC copilot, one for churn prediction, one for customer service, each auditable and independently updated. - **[MCP](https://atlan.com/know/mcp-delivers-business-context/) server, A2A, API, and SQL access**: context reaches whichever platform a telecom team builds agents on, relevant given the genuine multi-vendor reality of Ericsson, Nokia, and Huawei OSS stacks. - **Lineage from raw network event to agent decision**: traces a wrong churn score or NOC recommendation back to the source system that caused it, answering the "chatbot over log files" complaint directly. - **Policy and access context at runtime**: CPNI, GDPR, and data-residency rules checked the moment an agent queries subscriber data, not bolted on after the fact. Virgin Media O2, already named among Atlan's telecom customers, is scaling data and AI self-service across 16,000 employees and 45 million customer connections, according to Atlan's Re:Govern 2025 recap of Mauro Flores's keynote, the kind of unified-context foundation a NOC or churn-prediction agent depends on to work from one governed subscriber record instead of six partial ones. Buying the context layer does not remove the work of unifying OSS, BSS, and network systems. It removes the multi-year cost of building and running that unification alone. --- ## How do you get started with build vs buy for AI-ready context in telecom? Start by mapping where OSS, BSS, and network systems disagree on subscriber and service definitions, before scoping a build-vs-buy decision in the abstract. Teams doing this for the first time often start with a shared framework like the [CIO's guide to context graphs](https://atlan.com/resources/cio-guide-to-context-graphs/) rather than inventing a new decision process from scratch. Challenge Fragmented OSS/BSS, network telemetry, and multi-vendor sprawl Solution Enterprise Data Graph + governed glossary + Context Repos via MCP Outcome Every telecom agent reads the same current, governed subscriber and service state Three agents, one shared context layer NOC copilot Reads governed network topology and inventory Churn-prediction agent Reads one certified definition of churn Customer-service agent Reads reconciled subscriber records Telecom agents fail for the same structural reason across teams. A shared context layer fixes it once instead of three times. **Steps to build toward shared context:** 1. **Audit subscriber, service, and account definitions** across OSS, BSS, and network inventory before deciding anything. 2. **Pick one cross-team use case, not one department.** Start with a churn event both retention and customer-service agents need to interpret the same way. 3. **Attach freshness and reliability signals to network and inventory data** before agents treat it as authoritative by default. 4. **Encode CPNI, GDPR, and residency policy at the context layer once, not per agent.** 5. **Price the multi-year operating cost, not just the initial build cost,** into any build decision, according to TechTarget's CIO decision matrix for build vs. buy AI. **Common pitfalls for telecom:** 1. **Building one agent's context in isolation.** A team builds the NOC copilot's context, then the churn-prediction team rebuilds the same subscriber data differently, the pattern that leads to agent sprawl. 2. **Treating the build path as a quarters-long project when it is actually multi-year.** Vendor narratives underplay this since AI modules are often sold as point solutions that add a silo rather than removing one, a gap [context quality testing for AI agents](https://atlan.com/know/ai-agent/context-quality-testing-for-ai-agents/) is built to catch before it reaches production. 3. **Bolting CPNI or consent checks onto individual agent prompts** instead of enforcing them where context is delivered. 4. **Forcing a strict build-vs-buy binary** when TM Forum's ODA/SID offers a genuine middle path. A pilot that works on a clean extract and breaks once it reaches production systems is not a model failure, it is the same [AI agent scaling in production](https://atlan.com/know/ai-agent/ai-agent-scaling-in-production/) failure mode telecom hits earlier than most industries, because it has more systems to disagree in the first place. --- ## Real stories from real customers: context operating systems in production Virgin Media O2 is the telecom-specific proof point covered above. The same governed-context approach is already running at enterprise scale outside telecom, evidence that the pattern generalizes rather than being a one-industry argument. "We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products." — Joe DosSantos, VP of Enterprise Data & Analytics, Workday Watch Now → "Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models." — Sridher Arumugham, Chief Data & Analytics Officer, DigiKey Watch Now → Join the WTF Is the Context Layer series See how telecom operators and enterprises like Virgin Media O2 put a governed context layer into production, live and unscripted. Register for the Series --- ## Why buying wins for most telecoms, and building wins for a few Telecom hits the AI-context wall faster than most industries because it stacks OSS/BSS fragmentation, real-time telemetry, multi-vendor sprawl, and CPNI-level compliance load on top of the same definitional problem every vertical faces. Buying the context layer wins for most telecoms most of the time, because unifying and continuously operating that stack is a multi-year commitment few operators are actually staffed to run alone. Building wins only under specific, named conditions: genuine ontology differentiation, a hard sovereignty requirement, or an active TM Forum ODA investment, not as a general-purpose default. The same context-fragmentation failure shows up in [AI agent in finance](https://atlan.com/know/ai-agent/ai-agent-in-finance/) and [AI agent in healthcare](https://atlan.com/know/ai-agent/ai-agent-in-healthcare/), where [HIPAA compliance for AI agents](https://atlan.com/know/ai-agent/hipaa-compliance-for-ai-agents/) plays the same role CPNI does here, and again for [data analytics teams](https://atlan.com/know/ai-agent/context-layer-for-data-analytics-teams/), [data governance teams](https://atlan.com/know/ai-agent/context-layer-for-data-governance-teams/), and [software delivery pipelines](https://atlan.com/know/ai-agent/context-layer-for-sdlc/). Whichever team asks for the next agent inherits a governed answer if [context layer 101](https://atlan.com/know/ai-readiness/context-layer-101/) was solved once, instead of rebuilding it a fourth time, the same distinction a [context graph vs a knowledge graph](https://atlan.com/know/context-graph-vs-knowledge-graph/) draws at the architecture level. Book a Demo --- ## FAQs about build vs buy for AI-ready context in telecom ### 1. What is a context layer for AI? A context layer for AI is the shared infrastructure that gives every agent one governed view of business definitions, current data, and policy, instead of each agent querying raw systems separately. It sits between enterprise data systems and AI agents, translating fragmented metadata into context an agent can act on directly. ### 2. How do AI agents gather context from enterprise data? AI agents gather context through connectors, APIs, or protocols like MCP that query a governed layer sitting above the source systems, rather than reading raw tables or documents directly. That layer resolves definitions, checks policy, and adds freshness signals before the agent ever acts. ### 3. Why do telecom AI pilots fail in production even when the model works in testing? Telecom AI pilots are typically demonstrated against a clean extract from one system, then deployed against OSS, BSS, and network systems that disagree on basic definitions like subscriber and service. The mismatch surfaces immediately in production and erodes trust in the agent fast. ### 4. What is CPNI, and how does it apply to AI agents accessing subscriber data? CPNI is customer proprietary network information, protected under FCC rules that require US carriers to certify compliance annually. An AI agent chaining tool calls across billing, provisioning, and network systems to answer a subscriber question needs the same access controls checked at query time, not just certified once a year. ### 5. When does it make sense to build a custom AI data platform instead of buying one, in telecom specifically? Building makes sense when telecom-specific ontology modeling is a genuine competitive differentiator, when sovereignty or data-residency rules require on-prem infrastructure, or when a TM Forum ODA or SID investment is already underway. Outside those three conditions, buying is faster and cheaper to operate. ### 6. What data does a telecom churn-prediction AI agent actually need, and why is churn hard to define consistently? A churn-prediction agent needs one governed definition of churn plus reconciled CRM, billing, and network data, because SIM inactivity, contract termination, port-out, and silent churn all get treated as the same event across different systems today. Without one certified definition, a model trained on one meaning of churn scores against another. --- ## Sources 1. [Telcos' AI inflection point: What leaders do to capture value, McKinsey & Company (2025/2026)](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/telcos-ai-inflection-point-what-leaders-do-to-capture-value) 2. [The telco reinvention: How AI can fuel value creation, McKinsey & Company](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-telco-reinvention-how-ai-can-fuel-value-creation) 3. [The 2026 CPNI Annual Certification Due, The CommLaw Group (2026)](https://commlawgroup.com/2026/the-2026-cpni-annual-certification-due/) 4. [The 2026 Legal Wake-Up Call: AI, Data Privacy, and Communications Risk, Bronston Legal (2026)](https://techlawyers.com/the-2026-legal-wake-up-call-ai-data-privacy-and-communications-risk/) 5. [AI-Ready OSS/BSS: Event-Driven Architecture for Telecom, Wavelo (2026)](https://www.wavelo.com/resources/blog/oss-bss-data-strategies-for-ai-success) 6. [The transformative impact of AI and generative AI on OSS and BSS in Telecommunications, Microsoft (2025)](https://www.microsoft.com/en-us/microsoft-cloud/blog/telecommunications/2025/04/08/the-transformative-impact-of-ai-and-generative-ai-on-oss-and-bss-in-telecommunications/) 7. [Transforming OSS/BSS with multi-agent AI, Ericsson (2025)](https://www.ericsson.com/en/blog/2025/6/how-multi-agent-ai-is-transforming-telco-product-configuration) 8. [Agentic AI for OSS/BSS: Opportunities and Challenges, Omdia via TM Forum](https://omdia.tech.informa.com/om143816/agentic-ai-for-ossbss-opportunities-and-challenges) 9. [The Complete Guide to Build vs. Buy in Network Automation, CodiLime (2026)](https://codilime.com/blog/the-complete-guide-to-build-vs-buy-in-network-automation/) 10. [Build vs. buy AI: A CIO's decision matrix, TechTarget](https://www.techtarget.com/searchcio/feature/Build-vs-buy-AI-A-CIOs-decision-matrix) 11. [MWC 2026: Ericsson says AI is a network tool and network driver, Fierce Network (2026)](https://www.fierce-network.com/wireless/mwc-2026-ericsson-frames-ai-both-network-tool-and-network-driver) 12. [AI investment strategy for CIOs, techresearchonline.com (Vamsi Duvvuri, EY Americas)](https://techresearchonline.com/blog/ai-investment-strategy-for-cios/) 13. [Re:Govern 2025: The Data & AI Context Summit Recap, Atlan](https://atlan.com/regovern-2025-recap/)