Autonomy breaks without coordination

Why autonomous networks need a conflict management layer

As telecom networks move toward higher levels of autonomy, operators are deploying multiple agents, rApps, orchestrators and service functions to provision, assure and optimize shared infrastructure. These agents may operate across different vendors, domains and service layers, each making decisions to improve a specific outcome.

That creates a new operational challenge: what happens when autonomous actions collide? An energy-saving action on one cell, for example, may push traffic onto a neighboring cell supporting a critical service. A new B2B slice request may not be possible at full specification without affecting an existing priority commitment. A third-party rApp may propose a change to a shared resource without knowing what other agents are doing.

Conflict management in intent-based networks – Phase II, which was showcased at DTW Ignite in Copenhagen in June 2026, addresses this missing prerequisite for safe autonomy. The project was named winner of the Best Moonshot Catalyst – Attendees’ Choice Award and was also a finalist in the Best Moonshot Catalyst – Autonomous Networks challenge.

Phase II builds on the earlier intent management work by moving from expressing and interpreting intents to governing what happens when those intents interact. The focus in this phase is conflict management: identifying where autonomous decisions could work against each other and resolving those issues before they compromise service outcomes or network performance.

Without a way to detect and resolve conflicts before they affect the live network, operators face a difficult choice: hold back automation and miss the value of autonomy, or deploy it at scale and risk SLA breaches, customer dissatisfaction and loss of trust.

Agentic business layer conversational gateway

The Catalyst implements a layered AI architecture spanning both the service and network management domains. At the customer-facing layer, an agentic interface built on Amazon Connect and Amazon Bedrock captures B2B service requests expressed in natural language — for example, "I need a robot-control slice at Lidingövägen, Stockholm for 20 AI robots with sub-50ms latency and real-time control." The agent translates unstructured business intent into standards-compliant API calls, invoking TMF645 Service Qualification and TMF641 Service Ordering against Ericsson's ESOA (Expert Service Orchestration and Automation) platform, which exposes its capabilities as an MCP (Model Context Protocol) Server that the agent consumes natively as a tool interface.

Fig 1. The agentic business layer

When the full specification cannot be met, the conflict resolution logic operates within the network and service management layers — the rApp framework and Knowledge Plane evaluate the request against live commitments and generate feasible alternatives. The agentic layer then interprets these API responses and presents the viable options back to the customer in natural language, closing the loop from intent to provisioned service without requiring the customer to understand the underlying TMF data model.

This separation of concerns is deliberate: the AI reasoning at the network layer handles conflict detection, governance and alternative generation; the cloud-native agentic layer at the service entry point handles natural-language understanding, API translation and human-readable presentation. The use of MCP as the integration pattern between the agentic interface and the network automation platform demonstrates how standardized tool interfaces can bridge cloud-native AI services with telecom-domain platforms — without bespoke bilateral integrations.

Making every autonomous action intent-aware

The Catalyst demonstrates a standards-based, capability-driven framework that evaluates autonomous actions against live service commitments before they reach the network. It turns multiple independent actors into a coordinated, intent-aware system that can operate safely across provisioning, assurance, optimization and cross-domain coordination.

Fig 2. Service and optimization conflict management

This mirrors the autonomous domain model described by Ericsson, where intent management, conflict management, SLO monitoring, closed control loops, domain intelligence, AI/ML agents,and operations data management work together. In that model, the human role shifts from manually configuring network tasks to steering automation through high-level business and service intents, with the system responsible for selecting the best strategies within defined guardrails.

In practical terms, this shifts intent management from a descriptive model into an operational control mechanism. It is not enough for each actor to understand its own intent; the system must also understand how multiple intents relate, where they compete for the same resources, and which commitments should take precedence when trade-offs are required.

Fig 3. Approval of conflicting actions

Technically, the conflict management layer acts as a decision-control function between autonomous agents and the execution environment. It maintains an active view of intents, policies, commitments, resource constraints and actor permissions, then compares each proposed action against that context before authorization. Conflicts can be detected at several levels: objective conflicts, where two intents optimize for incompatible outcomes; resource conflicts, where actions compete for the same capacity, spectrum, compute or energy budget; policy conflicts, where a proposed action violates operator rules; and temporal conflicts, where individually valid actions become unsafe because of their timing or sequence.

This requires a shared information model. Each intent needs to expose its target, constraints, priority, validity period and acceptable trade-off range. Each actor needs a declared operational scope, including the domain it can control, the parameters it can modify, and the blast radius of its actions. The conflict manager can then perform impact analysis by mapping a proposed change to affected services, slices, cells, customers, and SLAs before deciding whether to approve, reject, defer or request a modified proposal.

The framework starts by defining governance boundaries. Every autonomous actor registers what it is allowed to do, where it can act, and which network or service concerns it can affect, making overlapping scopes visible before they cause harm.

It then translates customer and operator intent into feasible service outcomes. Instead of rejecting a B2B request when the full specification cannot be met, the framework can identify viablealternatives that preserve existing priority commitments. Live service commitments are shared across service and network management domains, so optimization agents understand what they must protect before proposing changes.

A useful example is the trade-off between energy efficiency and service experience. An operator intent may set a target to reduce energy consumption, while another intent protects minimum coverage, mobility robustness or an enterprise SLA. Conflict management allows the system to determine whether an energy-saving action is acceptable, whether it should be limited to a smaller cell set, delayed to a lower-traffic window, or rejected because it would breach a higher-priority service commitment.

Its core capability is pre-execution evaluation. Every proposed optimization is checked against active intents and commitments before it is applied, so harmful actions are blocked before they reach the network rather than rolled back after an incident.

The pre-execution check therefore behaves like an admission-control step for automation. A proposed action is evaluated against live commitments, dependency graphs and policy rules before it is passed to the relevant controller, orchestrator or rApp execution path. If the action is safe, it can be authorized with conditions such as time limits, guardrail thresholds, or rollback criteria. If it is unsafe, the system can return a machine-readable reason code, identify the violated intent or constraint, and provide boundaries for an alternative action.

The Catalyst also demonstrates how governed GenAI can help close the autonomy loop. When an action is rejected, the agent receives structured feedback and can refine, rescope, and resubmit its proposal automatically, without human intervention. Multi-vendor agents are coordinated through a single neutral interface, reducing the need for bespoke bilateral integrations between operators and rApp vendors.

This structured feedback loop is important for closed-loop automation. Rather than simply blocking an rApp or AI agent, the conflict manager provides enough context for the actor to generate a compliant alternative, such as reducing the optimization scope, changing the execution window, selecting a different cell set, lowering an energy-saving target or proposing a degraded-but-acceptable service option. Every decision can also be logged with the active intents, policies and evidence used, creating an audit trail for explainability, compliance, and post-event analysis.

As Graeme White, Portfolio Lead - Product Owner Principal - RAN Autonomy at Telstra, explains: “This Catalyst solution is valuable because it provides the missing prerequisite for autonomous networks. The industry has invested heavily in automation and AI, but without a way to manage conflicts between autonomous actors, operators cannot safely turn these capabilities on. TMF C930 establishes a standards-based conflict management layer, built on TM Forum Open APIs and O-RAN, that evaluates every autonomous action against live commitments before it is applied. It is what makes autonomy deliverable, and autonomy is what delivers the OPEX savings, CAPEX efficiency and new revenue streams the industry is counting on.”

Using TM Forum assets to bridge service and network domains

The project uses TM Forum assets to connect service qualification, service ordering, and intent management with the network automation layer.

These include TMF645 Service Qualification API, TMF641 Service Ordering API, and TMF921 Intent Management API. The Catalyst also draws on Autonomous Networks assets including TR290x Autonomous Networks Technical Report, TR291x Autonomous Networks: Intent Ontology and Modelling, TR292x Autonomous Networks: Knowledge Management, and IG1358 Intent-driven Autonomous Networks Implementation Guide.

The technical architecture aligns with O-RAN’s Non-RT RIC, rApp framework and intent model, creating a bridge between TM Forum’s service and network management domains and the O-RAN automation environment. This combination supports a multi-vendor ecosystem in which third-party agents can integrate through a standard interface and be governed by the same intent-aware logic.

Unlocking safe autonomy, new revenue and protected service quality

The project team argues that conflict management does not deliver savings on its own; it enables operators to switch on the autonomous processes that do. By allowing autonomous optimization to replace manual per-cell tuning, assurance cycles and service qualification, the framework could help operators unlock more than 30% OPEX savings.

It also supports CAPEX efficiency by improving spectral efficiency across cells and sectors and helps protect revenue by preventing autonomous actions from degrading existing commitments. For operators, this means they can sell what the network can deliver, reduce penalty exposure, and lower churn risk.

These examples also illustrate why intent-driven optimization is central to both efficiency and assurance. The same autonomous capabilities that reduce manual workload and improve resource utilization can also create competing objectives around cost, performance, energy, and resilience. Conflict management provides the control layer that lets operators pursue those goals simultaneously, rather than optimizing one dimension at the expense of another.

Commercially, the framework enables new revenue streams such as Network-as-a-Platform and dynamic B2B service provisioning. Because requests can be qualified against live commitments and alternative options generated automatically, operators can respond with viable offers rather than default rejections.

For the wider industry, the Catalyst provides a reusable blueprint for intent-aware autonomous networks built on TM Forum Open APIs and O-RAN. It supports a genuine multi-vendor rAppecosystem by reducing lock-in and lowering integration complexity.

For society, the value lies in more reliable connectivity as critical services increasingly depend on shared, autonomous infrastructure. By ensuring autonomous actions are scoped, evaluated and evidenced before execution, the framework supports trustworthy automation, more resilient connectivity, and responsible use of AI in live networks.