AI harnesses for telco autonomous networks

Across the global landscape, telecommunications operators have already deployed machine learning for predictive maintenance, customer care chatbots, and anomaly detection. However, as the industry transitions toward Autonomous Networks Level 4 (AN L4), where networks can make intent-driven, predictive decisions and perform closed-loop management with minimal human intervention, a fundamental architectural challenge has emerged:

How do you build a secure, reliable, and interoperable AI harness that bridges probabilistic AI reasoning with deterministic, carrier-grade network execution?

Connecting large language models (LLMs) or autonomous agents directly to critical network functions poses severe operational risks. An AI-generated decision may be incorrect, out of policy, based on a stale state, or unsafe under unobserved conditions. An erroneous or poorly scoped change in a production core or radio access network (RAN) could violate service-level objectives, destabilize a control loop, or propagate across dependent network functions if existing protection and isolation mechanisms fail.

To move AI from isolated proofs-of-concept into resilient production, telcos will likely require an end-to-end operational AI harness: a platform architecture that combines open cloud substrates, interoperable agent protocols, trusted operational context, declarative GitOps workflows, confidential inference, intent-driven orchestration, policy enforcement, and closed-loop assurance.

A key architectural principle is to separate the agentic read path (for observation and cognition) from the network’s write path (for governance and execution). AI can interpret context, diagnose problems, and propose actions, while deterministic policy, validation, orchestration, and assurance mechanisms govern what changes are actually allowed to reach the network. This principle is increasingly reflected in the industry’s work on L4 autonomy.

Why autonomous networks need an AI harness

Modern AI production environments demand dense accelerator nodes, high-throughput east-west fabrics, low tail-latency networking, and specialized memory management for key-value (KV) caching. Dropping these memory-dense, probabilistic workloads onto legacy telco architectures engineered for rigid change windows creates friction across different levels:

• Fragmented execution & data islands: Telemetry, alarm streams, and topology maps often live in vendor-siloed systems with different schemas and levels of data quality.
• Missing operational fabric for agents: Autonomous AI agents require unified identity management, fine-grained role-based access control (RBAC) audited tool access, and policy enforcement to prevent unauthorized or conflicting network changes.
• Infrastructure bottlenecks: AI inference introduces very different resource and scheduling characteristics from conventional containerized network functions (CNFs). High-throughput accelerator access, NUMA placement, PCIe topology, SR-IOV/RDMA networking, CPU/GPU scheduling, memory bandwidth and KV-cache management need to coexist with the deterministic latency, isolation, and availability requirements of telco workloads.

To resolve these bottlenecks, standards bodies and open-source initiatives, including ETSI, TM Forum, O-RAN Alliance, and the Linux Foundation, are developing complementary pieces of the architecture required for autonomous networks. Translating these evolving, domain-specific frameworks into an operational reality requires an open, end-to-end platform harness that bridges low-level cloud substrates with high-level agentic reasoning. Such architecture is better understood as four interacting planes:

• Context plane: telemetry, topology, inventory, alarms, service state, knowledge graphs, and other operational data.
• Reasoning plane: AI/ML models and agents that diagnose, predict, plan, and interpret intent.
• Control plane: identity, policy, validation, arbitration, orchestration, and closed-loop decision mechanisms.
• Execution plane: the CNFs, RAN, core, transport, cloud infrastructure, and other network resources that ultimately implement approved changes.

The AI harness sits across these planes, connecting the agentic read path to the network’s write path. This links probabilistic reasoning to deterministic control without allowing the model itself to become the network’s final authority. In other words, AI can interpret context and propose actions, while deterministic policy, validation, orchestration, and assurance mechanisms govern what changes are actually allowed to reach the network.

The cloud-native foundation layer

At the foundation of any AI-native network sits the cloud substrate. Telcos have strong incentives to avoid maintaining completely parallel, siloed infrastructure stacks (e.g., one for CNFs and another for AI inference pipelines). Some network and AI workloads may benefit from shared infrastructure, while others may require dedicated accelerators, separate security domains, or physically isolated resources. The cloud foundation should therefore provide a common operational model without imposing a single hardware topology.

Canonical delivers the open-source infrastructure portfolio needed to build a unified runtime environment where AI models and network functions can coexist on shared physical infrastructure, while still allowing operators to dedicate or isolate resources where required:

• Metal-as-a-Service (MAAS): Automates bare-metal server discovery, firmware management, and provisioning for GPU-enabled servers and edge platforms.
• Ubuntu & real-time kernels: Deliver a secure operating system foundation with native kernel support for hardware acceleration, low-latency networking (SR-IOV, DPDK), and confidential computing trusted execution environments.
• Canonical Kubernetes & MicroCloud: Provide low-touch Kubernetes orchestration and edge cloud infrastructure tailored for distributed edge deployments.
• Juju & charmed operators: Encapsulate complex day-2 operational logic, automated upgrades, and integration across infrastructure, data services, and AI/ML tooling.

The same foundation can host the inference layer, allowing operators to deploy and manage model-serving workloads alongside cloud-native network functions. Canonical’s inference snaps provide a way to package and deploy inference runtimes such as vLLM and llama.cpp as repeatable, versioned workloads for serving LLMs. Juju and charmed operators can then provide model-driven deployment, configuration, integration, scaling, and lifecycle management for the applications and infrastructure supporting those workloads.

Standardizing agentic AI with the model context protocol (MCP)

To advance from rule-based automation to agentic AI, reasoning models need a standardized way to discover and query network context and tools. Bespoke API integration isn’t the answer, as it can recreate the vendor lock-in and fragmentation that cloud-native architectures were designed to avoid.

The industry is increasingly addressing this through the model context protocol (MCP), governed within the Linux Foundation’s Agentic AI Foundation (AAIF). However, MCP is an interoperability layer, not a telco policy engine or network controller. The underlying network APIs and protocols remain responsible for actual network operations, while MCP can serve as an agent-facing protocol layer for the network context read path, providing:

• Interoperability and context retrieval: MCP standardizes how AI agents discover and invoke tools, allowing an agent to query telemetry, inspect cluster health, and gather topology or diagnostic information across heterogeneous systems while leaving the underlying data and observability systems in place. This can significantly reduce bespoke integration at the agent layer.
• Composability: Operators can expose new network capabilities, metrics, or diagnostic models through MCP server wrappers, enabling rapid, modular expansion of the operational toolkit available for the agentic layer
• Security integration and tool exposure: MCP standardizes tool invocation and provides an authorization framework for protected endpoints, including mechanisms that support human control over tool invocation. But, because MCP handles protocol-level interactions rather than enterprise policy, operators need to maintain control by pairing MCP servers with existing identity, RBAC, and audit workflows. This allows operators to expose narrowly scoped diagnostic tools rather than raw network APIs.

Exposing read-oriented cluster lifecycle observability tools enables AI agents to safely query cluster health, inspect deployment resource states, and evaluate workloads without risking unapproved configuration changes.

Safe execution: policy, orchestration, and declarative control as the guardrails

While MCP provides an agent-facing interface for context discovery and tool invocation, state-changing network operations should follow a separate, strictly controlled write path. In a carrier-grade network, an AI agent should not have unrestricted, direct, state-changing access to live network elements.

Instead, operators can establish operational guardrails by routing agent decisions through policy enforcement, validation, orchestration, and assurance mechanisms. Declarative GitOps workflows is one useful mechanism for selected classes of declarative infrastructure change. A representative workflow could include:

1. Context & planning (read path): The AI agent gathers context through MCP, analyzes telemetry (e.g. via Prometheus/OpenTelemetry) and formulates a remediation plan (e.g. scaling a UPF instance or reallocating an O-RAN slice).
2. Policy and risk evaluation: Before any state-changing action is accepted, a policy engine evaluates whether the proposed operation is permitted. Policies can consider agent identity, network domain, service criticality, time, maintenance state, data freshness, expected blast radius, concurrent changes, and service-level constraints.
3. Declarative commit (write path): For changes suited to declarative infrastructure management, the agent can express its proposal as a configuration change committed to a version-controlled Git repository or, where appropriate, represented through a Juju model or bundle.
4. Validation & digital twins: A CI/CD pipeline intercepts the commit and validates the proposed change against a network digital twin or pre-production test environment, where available, to simulate impact and identify violations of policy and service constraints..
5. Human-in-the-loop oversight: If the action’s blast radius exceeds pre-defined risk thresholds, the commit automatically triggers a review request for a human operator.
6. Reconciliation & rollback: Once approved, declarative controllers (such as FluxCD or charmed operators) reconcile the desired state into the live network. Other network domains may instead use domain-specific orchestrators, controllers, RIC components, or existing network-management interfaces.
7. Closed-loop assurance: Post-deployment monitoring evaluates whether the resulting network state remains within the intended service and policy boundaries. Where safe reversal is supported, assurance mechanisms can trigger automated remediation or rollback.

Different control-loop timescales should also be accounted for. A large language model should not necessarily sit inside a millisecond-scale RAN control loop. Fast, deterministic control loops can remain within network-native controllers, with AI agents operating at slower timescales for diagnosis, prediction, planning, policy interpretation, and higher-level optimization.

This separation reflects an emerging pattern in Level 4 autonomous network architectures: agentic AI can interpret context and propose actions, while digital twins, intent-based controls, orchestration, and assurance mechanisms constrain and validate execution.

Security & confidential AI: protecting data, models, and prompts in use

As AI agents handle real-time subscriber traffic, service tickets, and proprietary network topologies, data privacy and supply-chain security become paramount. Traditional encryption at rest and in transit is insufficient when data must be decrypted in memory during model inference.

Confidential AI applies hardware-backed trusted execution environments (such as AMD SEV-SNP, Intel TDX, and NVIDIA Confidential GPUs) to protect data and, where supported, model weights while in use. A remote-attestation service can verify cryptographic measurements spanning the host firmware, guest OS, and inference runtime against an operator-defined trust policy before a key broker releases sensitive keys or model assets. Confidential computing therefore establishes a verifiable hardware-backed trust boundary around protected workloads.

Canonical supports confidential AI across private and public cloud environments:

• Ubuntu 26.04 LTS: Provides integrated host and guest OS support for AMD SEV-SNP and Intel TDX, giving operators full control over confidential VM deployments on their bare-metal infrastructure.
• Ubuntu Core: Offers an immutable, transactional guest OS image packaged with snaps, which reduces configuration drift. Where confidential VMs are used, remote attestation provides an independent mechanism for verifying the measured boot and runtime environment, supporting appliance-like inference endpoints at the edge.

Accelerating developer workflows with Canonical Workshop

Building production-grade AI harnesses requires rapid developer iteration. Yet, granting experimental agentic tooling unconstrained access to host machines creates severe security risks. As telco teams build next-generation network intelligence like agentic troubleshooting assistants or local inference engines, they face an operational paradox: developers require fast access to modern AI runtimes (such as Ollama, OpenCode, vLLM, llama.cpp) and hardware SDKs (e.g., NVIDIA CUDA, AMD ROCm), while platform and security teams must enforce strict isolation to prevent driver conflicts or unvetted, destructive agent commands.

Canonical’s Workshop addresses this friction by enabling engineers to launch composable, sandboxed development environments on Ubuntu via a single command (snap install workshop –classic).

Defined through simple, version-controlled YAML specification files, Workshops run inside unprivileged system containers powered by LXD. This creates an additional isolation boundary around experimental or hallucination-prone tools or AI agents, reducing their access to the host by default without sacrificing developer speed.

To solve the brittleness of bespoke container mappings, Workshop uses a uniform resource interface inspired by snapd. Modular SDKs request controlled access to host capabilities, such as discrete GPUs, host mounts, or SSH agents, providing controlled access to host resources while keeping resource access explicit, version-controlled, and administratively controlled. Because the environment is defined declaratively, the same Workshop specification can be reused across developer machines, CI/CD pipelines, and digital twin testbeds, improving reproducibility, reducing configuration drift, and accelerating the path from lab prototype to production harness.

Conclusion

Achieving Autonomous Networks Level 4 is not a matter of dropping a large language model onto an existing network stack. It requires a coordinated, open-source platform architecture that aligns silicon capabilities, cloud-native orchestration, confidential execution, standardized agent interfaces, operational knowledge, intent-driven control, and deterministic network safeguards.

By combining Canonical’s end-to-end software stack, from bare-metal MAAS provisioning and Ubuntu Confidential VMs to Charmed MLOps, Workshop developer sandboxes, and inference snaps, operators can build a trusted, repeatable AI harness.

This open foundation gives telcos greater control over their data, infrastructure choices, and deployment architecture, while providing a more repeatable path to operationalizing AI and, ultimately, toward the requirements of the 6G era.

Next steps

Learn how Canonical solutions provide a stable, validated, and open foundation for telco workloads.

• Learn about Canonical’s solutions for telco
• Discover Canonical’s guide to open source AI infrastructure
• Try Canonical Workshop
• Get in touch with Canonical’s telco team