AI Agents: It’s Not Data, It’s Context. Why a Shared Context Layer Must Come Before Autonomy in CSPs

Every Communications Service Provider (CSP) is asking how quickly it can deploy AI agents. Far fewer are asking whether those agents understand the business they are about to act on. In a telecom environment, where one customer, one service and one fault can look different in every system, the answer determines whether autonomy delivers outcomes or simply automates mistakes.

This article explains why AI agents need context, not just data; what a shared context layer looks like; and what it means for CSP leadership.

Pause animation

(opens the full-size diagram in a new tab)

The Complex Telco Environment: Many Systems, Many Truths

A CSP is not one business with one data set. It is many technologies delivering many services: mobile and fixed, broadband and enterprise, IoT, 4G and 5G, fibre, IP/MPLS, cloud, edge and satellite. Each is supported by specialist systems built at different times by different teams: CRM, BSS and OSS, billing and charging, inventory, service management, orchestration, assurance, network management, IT systems and partner platforms.

These systems are siloed, and they disagree. A customer in CRM is not necessarily the same thing as a customer in inventory. A service in inventory is not the same thing as a service in the network. The network view and the business view describe the same reality using different definitions.

The result is an environment that is disconnected, fragmented and hard to automate. For a human operator, this is an inconvenience managed through experience. For an autonomous agent, it is a source of confident error.

Why More Data Access Is Not the Answer

The instinctive response is to give agents access to more data and more tools. That helps with retrieval, but not with understanding. Six differences sit beneath the surface of every CSP:

• Different data models: The same entity is structured differently in each system, so records cannot simply be joined.
• Different terminology: Teams use the same words for different things, and different words for the same thing.
• Different rules and policies: Commercial, technical and regulatory rules are defined, and enforced, in different places.
• Different versions of reality: Planned, inventoried and live network states routinely diverge.
• Legacy and cloud-native complexity: Decades of technology sit alongside modern platforms, each with its own interfaces and assumptions.
• Siloed teams and processes: Knowledge of how things really work is held by people and processes, not by systems.

This is why three common assumptions do not hold:

• 50 APIs ≠ understanding: Connectivity gives an agent reach, not meaning.
• Data lake access ≠ context: Having the data available does not tell an agent what it represents or how it relates to everything else.
• More agents ≠ transformation: Multiplying agents that each hold a partial view multiplies inconsistency.

The Missing Piece: A Shared Context Layer

A shared context layer is the foundation for context-aware AI. It gives every agent one shared understanding of the business, the network and the customer, in a machine-readable form. It is built from five complementary layers:

• Common data model and ontology: Agreed definitions of the entities that matter, such as customer, service, resource and network element, and the relationships between them.
• Business and operational context: What the organisation is trying to achieve, how processes work and what good looks like.
• Rules, policies and relationships: The constraints that govern what may happen, expressed so that machines can apply them.
• Real-time and historical context: The current state of the network and customers, together with the history needed to interpret it.
• Guardrails and permissions: What each agent may see, change and decide, and when it must hand over to a person.

Industry information models, such as those published by TM Forum, give CSPs a head start on the first layer. The harder work is connecting them to live systems, policies and operational reality.

What Context-Aware Agents Do Differently

With a shared context layer in place, an agent can move from insight to action with confidence. It can:

• Understand relationships across systems, for example which services and customers depend on a failing network element.
• Know the rules, policies and constraints that apply before it acts.
• Choose the right tools and data for the task, instead of searching everything.
• Verify the outcome of its action and learn from it.

Safe, Intelligent Action: Acting Within Context

Context also defines what an agent may do. Within clear boundaries, context-aware agents can resolve incidents, reroute traffic, modify configuration, raise orders, change services, optimise resources and improve the customer experience.

The boundaries matter as much as the capabilities. Five guardrail questions should be answerable, in machine-readable form, before any agent is allowed to act:

• What can the agent change?
• What rules apply?
• What is the impact?
• How do we verify success?
• When must it escalate to a human?

Why Context Determines Whether an Agent Is Correct

For C-level leaders, the practical question is why context is the deciding factor in building the right agents. Eight reasons stand out:

1. Correctness depends on meaning, not access. An agent that cannot tell which “customer” or “service” a record refers to will act confidently on the wrong entity.
2. Cross-domain reasoning needs relationships. Impact analysis, root-cause analysis and service restoration all depend on how customers, services, resources and network elements relate to one another.
3. Policies must be machine-readable. Service levels, regulatory obligations and change windows that live in documents and tribal knowledge cannot constrain an agent.
4. Boundaries make autonomy safe. Permissions and guardrails held as context tell the agent what it may change, what the impact would be and when to hand over to a person.
5. Better tool and data selection. Context tells an agent which system is authoritative for which question, reducing tool misuse and conflicting answers.
6. Verification and learning. Without a view of expected and actual state, an agent cannot confirm that its action worked or learn from the result.
7. Consistency and reuse across agents. If every agent builds its own partial picture, agents disagree and errors compound. One shared layer keeps them aligned, avoids re-integrating the same systems for every use case, and makes the ensembles and assemblies described in our earlier article far more reliable.
8. Trust, audit and accountability. Decisions that can be explained against a shared, governed context are easier to audit and to defend to boards, customers and regulators.

What This Means for CSP Leadership

Treat context as enterprise infrastructure, not as a feature of an individual AI project. That has practical implications:

• Ownership: Give the shared context layer clear ownership across network, IT, customer and commercial domains.
• Investment model: Fund context as a shared asset consumed by every agent and business function, with value measured across use cases rather than project by project.
• Sequencing: Start with the entities and relationships behind one high-value domain, such as incident management, then extend.
• Governance: Make guardrails, permissions and policies part of the context layer, so they apply to every agent consistently.
• An explicit gate: Make “does this agent have enough context to act?” an approval step before any agent moves from advising to acting.
• Measurement: Track decision accuracy, escalation rates and rework, not just the number of agents deployed.

The Real Question

Does the agent actually have enough context to understand our business and network before we allow it to act?

The biggest AI transformation for telcos is not building more agents. It is creating a shared, machine-readable context layer and a genuine understanding of the telco itself. That is the correct foundation on which context-aware autonomous telecom is built.

A question for every CSP leadership team:

Are we investing enough in this underlying context layer, or are we building the next agent to optimise and save costs?