---
title: 'MX-AI: Agentic Observability & Control'
url: https://www.emergentmind.com/topics/mx-ai
type: topic
---

# MX-AI: Agentic Observability & Control

MX-AI is an agentic observability and control platform for Open and AI-RAN that is presented as “the first end-to-end agentic system” to instrument a live 5G Open RAN testbed, deploy a graph of Large-Language-Model-powered agents inside the Service Management and Orchestration layer, and expose observability and control functions for 6G RAN resources through natural-language intents [2508.09197]. It is positioned within the AI-native 6G RAN vision in which autonomous agents observe, reason about, and re-configure the network across the cloud–edge continuum. In architectural terms, MX-AI operates at the SMO and Non-RT RIC tier, interfaces with the Near-RT RIC via A1 and with RAN nodes via O1/E2, and implements intent-driven operations and closed-loop actuation on a live network rather than in a simulator [2508.09197].

## 1. Architectural placement and operational scope

MX-AI is embedded at the R1 interface between SMO and Non-RT RIC and therefore belongs to the non-real-time loop of the O-RAN stack [2508.09197]. This placement is central to its design. The Near-RT RIC, with latency in the $10$ ms–$1$~sec range, remains responsible for xApps handling sub-second scheduling, interference, or mobility loops via E2, whereas the Non-RT RIC, with latency \(\,\ge\!1\)s, operates inside the SMO, aggregates O1 telemetry, and trains or deploys AI models through rApps. MX-AI keeps agent cognition at non-RT timescales, with a typical end-to-end LLM round-trip of 1–12 seconds, which is described as fast enough to compete with human operators while respecting O-RAN temporal decoupling.

Within this architecture, MX-AI addresses two operational contexts. The first is AI-native 6G RAN operations, where LLM agents sense heterogeneous telemetry, reason over large contexts, and act by invoking tools and policies. The second is observability and control via natural-language intents, in which operators interact through a human-to-agent interface to query KPIs, diagnose anomalies, and request network changes such as slice updates. The agent graph translates these intents into validated actions.

The platform’s role is therefore not to replace near-real-time radio control loops. A common misconception is that an LLM-based control plane is intended to subsume xApps or sub-second actuation. The reported design does not do so. It explicitly preserves O-RAN’s logical decoupling: Near-RT RIC remains the site for $10$ ms–$1$~sec loops, while MX-AI operates in the \(\,\ge\!1\)s non-RT interval [2508.09197]. This suggests that its immediate significance lies in operational supervision, policy synthesis, and closed-loop orchestration at human-competitive timescales rather than PHY/MAC-loop replacement.

## 2. Testbed realization and data plane integration

MX-AI is implemented on a live 5G Open RAN testbed comprising an indoor OpenAirInterface gNB and 5G core, three OAI UEs replaying eMBB and URLLC traces, and BubbleRAN FlexRIC Near-RT and Non-RT RICs together with the SMO [2508.09197]. MX-AI connects to the OAI gNB through FlexRIC’s R1/E2 interfaces. This matters because the system is evaluated under live network conditions, including active telemetry streams, CRD updates, and concrete control actions, rather than under simulator abstractions.

The interface structure follows standard O-RAN decompositions.

| Interface | Function |
|---|---|
| **O1** | SMO management telemetry and configuration |
| **E2** | Near-RT RIC control and telemetry to/from RAN nodes |
| **A1** | Policy channel from Non-RT RIC/SMO to Near-RT RIC |
| **R1** | SMO–Non-RT RIC interface where the agent graph runs |

Instrumentation is heterogeneous. SMO and FlexRIC telemetry sources over O1 and E2 stream KPIs, alarms, and topology snapshots. Kubernetes resource watchers observe native objects and CRDs for RAN policies and slice descriptors with watch/informer semantics and push deltas of changes into a dense vector index. Prometheus exporters provide live counters, and kernel-level probes based on eBPF are used when needed. A vector store supports retrieval-augmented generation by combining push-based deltas with pull-based queries.

This observability substrate is important because the platform’s answer quality is described as being constrained more by retrieval and tool engineering than by model size. The paper explicitly identifies delta-aware watchers, typed schemas, compact JSON, and context pruning as critical to observability quality [2508.09197]. A plausible implication is that, in this setting, the decisive systems problem is evidence plumbing rather than free-form text generation.

## 3. Agent graph, roles, and orchestration logic

MX-AI is organized as a directed acyclic graph with iterative edges for planning, validation, and context refresh [2508.09197]. The graph contains specialized agents with distinct responsibilities rather than a monolithic LLM endpoint. This decomposition is central to the platform’s control reliability.

The Routing Agent classifies prompts into monitoring, deployment, or retrieval and dispatches them to the corresponding branch. The Monitoring Agent pulls KPIs and state through `monitoring_tools` over R1, summarizes telemetry, and answers observability queries. The Deployment Agent converts high-level intents into FlexRIC policy objects and network blueprint changes, then invokes `deployment_tools` to push actions via O1/A1 and, where needed, emits E2 service-model messages for Near-RT RIC or xApp reconfiguration. The Validator Agent performs pre-flight checks and schema validation, constraining actions and guarding against tool misuse. The Executor Agent issues validated actions and manages tool invocation to enforce changes. The Save_Answer Agent logs final answers and actions to a time-series database for audit and benchmarking.

The communication model combines live context and schema grounding. Live context arrives through push-based watchers for Kubernetes CRDs, xApps or rApps, and Prometheus, and through pull-based agent queries using top-\(k\) RAG together with live collectors. Typed JSON schemas are injected into prompts to reduce ambiguity and ground tool outputs. Safety is enforced through schema-aware planning and validator or rollback fences; pre-flight checks ensure actions match tool schemas, and failures are attributed to tool misuse rather than stochastic generation.

The orchestration pipeline is explicitly staged: intent recognition, planning, retrieval and context update, tool invocation, validation, actuation, and verification with feedback logging [2508.09197]. In deployment flows, the system iterates between plan revision and validation until schemas and constraints are satisfied. In monitoring flows, it supplements RAG context with fresh metrics from Prometheus or eBPF if the retrieved context is insufficient.

One potential misunderstanding is to treat the platform as merely an intent parser. The reported design goes beyond parsing. It includes policy synthesis, validation, execution, and post-action verification in a live closed loop [2508.09197]. That closed-loop structure is the main technical distinction of the system.

## 4. Natural-language observability and control functions

MX-AI exposes both observability and control through natural-language intents [2508.09197]. On the observability side, the telemetry model includes O1/E2 KPIs, alarms, topology snapshots, CRDs for slice descriptors and policies, and logs and application state from xApps and rApps. Push-based deltas serialize only changed fields, while pull-based queries return typed JSON inserted into the LLM context.

The examples reported for observability illustrate the breadth of accessible state. Queries include whether any access network exists and the names of available access and core networks; an overview of `gnb2` access network cells and radio configuration; whether the `gnb1` element is working properly; the number and names of UEs in the current deployment; the maximum and guaranteed throughput in the `PolicyJob` CRD of a VPN slice; and how close slice `#2` is to its latency SLA over the last hour [2508.09197]. KPI examples include latency histograms from FlexRIC, DU headroom, per-UE and per-PRB counters, and slice throughput guarantees.

On the control side, MX-AI actuates dynamic network blueprint management through JSON schemas for topology, QoS, and policies; PRB share reallocation and power-cap policies; slice throughput guarantees and maximum throughput constraints through A1 policies that pre-empt bandwidth from best-effort slices; and UE lifecycle together with blueprint deploy or delete operations [2508.09197].

The natural-language-to-action mappings are concrete. The intent “Create a network with name agora with 1 access network called parthenon and 1 RIC.” maps to creation of a network blueprint via CRDs in the SMO, configuration object updates, and deployment through O1, with A1 policy alignment as needed. “Create a terminal with name plato and connect it to the parthenon.agora access network.” maps to UE lifecycle and attachment operations in the blueprint plus O1 configuration updates, followed by telemetry-based confirmation. “Delete the terminal with name plato.” removes the corresponding UE or terminal CRD and updates O1 configuration. “Delete the network blueprint with name agora.” removes the blueprint CRD and updates O1 configuration. “Change the bubbleran VPN slice to 10 Mbps guaranteed and maximum throughput.” leads the Deployment Agent to synthesize an updated A1 policy, after which the Near-RT RIC enforces PRB share and pre-emption and may also use E2 service-model messages to reconfigure xApps [2508.09197].

The same pattern appears in SLA-style commands. For example, “Guarantee 10 Mb/s for the URLLC slice from 6–7 pm” leads to synthesis of an A1 policy that pre-empts bandwidth from best-effort slices and updates PRB or power-cap policies as needed, with KPI-based verification afterward. This suggests that the system’s semantics are not limited to declarative information retrieval; they include policy materialization against live O-RAN control surfaces.

## 5. LLM stack, validation discipline, and safety model

The platform supports both cloud APIs and local GPU deployments [2508.09197]. The cloud models listed are GPT-4.1 and GPT-4.1-mini. The local deployments listed are `llama3.3:70b-q4`, `qwen2:72b`, `llama3.1:8b-q4`, `llama3.2:3b-q4`, and `mistral:7b`. Prompting is schema-aware, uses typed JSON tool outputs, and relies on RAG for evidence grounding; routing or classification is performed by a telecom-tuned LLM.

Validation is not incidental but structural. Pre-flight schema checks are used before actuation, validator and rollback fences constrain actions, and typed JSON outputs reduce ambiguity in tool use. The reported failure modes are correspondingly specific: failures observed stem from tool misuse rather than generation stochasticity [2508.09197]. This is a notable characterization because it shifts fault analysis away from generic “hallucination” language and toward interface-grounding and tool-schema alignment.

Safety, however, remains incomplete. The current mechanisms comprise the Validator Agent, pre-flight schema checks, typed JSON outputs, rollback fences, and post-action verification via KPIs [2508.09197]. The paper simultaneously underscores the need for broader guardrails and human-in-the-loop review as future safety work. It also notes that LLM inference latency can bottleneck emergency procedures.

Two misconceptions are therefore corrected by the reported design. First, MX-AI is not an unconstrained free-form agent issuing raw network commands; its control path is mediated by schemas, validators, and explicit tool invocations. Second, it is not described as safety-complete. The paper explicitly treats human review and broader guardrails as open requirements [2508.09197]. A plausible implication is that the platform is best understood as a high-capability non-RT orchestration layer whose operational trustworthiness depends on external governance, validation policy, and interface hardening.

## 6. Evaluation, reproducibility, and implications for AI-native RAN

The evaluation is performed on a live setup consisting of the OAI gNB and 5G core, three OAI UEs replaying eMBB and URLLC traces, BubbleRAN FlexRIC Near-RT and Non-RT RICs and SMO, and the agent graph placed at R1 [2508.09197]. The query set contains 50 operational prompts, divided into 40 observability queries covering KPIs, policies, slices, CRDs, and logs, and 10 control actions covering UE lifecycle, blueprint deploy or delete, and slice PRB changes.

Three metrics are reported. Observability coherence is scored on a 0–5 scale using an LLM-assisted evaluator, GPTScore, with explicit rubrics and adjudication by three expert annotators for disagreements and edge cases. Decision-action accuracy is scored as a Boolean per action depending on whether the enforced change matches the intent, then aggregated as a percentage. End-to-end latency is measured from prompt to action completion. GPU footprint is also reported for local models.

With GPT-4.1, MX-AI attains mean answer quality $4.1~/~5.0$, $100~\%$ decision-action accuracy, and $8.8~ secs$ end-to-end latency [2508.09197]. GPT-4.1-mini achieves $8.0$ s end-to-end latency and $1000$ ms inference; GPT-4.1 is reported at $1100$ ms inference. Among local large models, `llama3.3:70b-q4` achieves $12.2$ s with approximately $42$ GB VRAM, and `qwen2:72b` achieves $13.5$ s with approximately $41$ GB. The fastest local small model is `llama3.2:3b-q4` at $1.3$ s and approximately $2.0$ GB, though with a coherence trade-off. The paper describes both large local models and cloud GPT models as occupying Pareto-efficient regions of the coherence–latency frontier, while small models demonstrate sub-second potential if paired with stronger retrieval and tooling.

The action results are especially strong: capable LLMs reached $100\%$ action accuracy across 10 control actions, whereas `mistral:7b` achieved 0% on this toolset [2508.09197]. The observability results are more nuanced. No model reached 5/5, and the paper emphasizes that retrieval and tool engineering mattered more than model size.

Reproducibility is supported through public release of the agent graph, role prompts, and evaluation harness, and a live demo is also provided [2508.09197]. The stated prerequisites include access to an OAI-based 5G testbed with gNB, 5G core, and UEs; the BubbleRAN SMO/RIC/FlexRIC stack; telemetry pipelines through O1/E2 together with Prometheus exporters and optional eBPF; Kubernetes API access for CRDs and watchers; and a dense vector index for RAG.

The reported limitations define the immediate research agenda. LLM inference may be too slow for emergency procedures; model distillation and hardware acceleration are described as urgent. Broader guardrails and human-in-the-loop review remain necessary. Proprietary APIs hinder reproducibility, motivating standardization akin to xApp stores. Scaling toward 6G will require handling heterogeneous spectrum, integrated sensing, and joint communication–compute, with hierarchical agent graphs and improved RAG described as vital [2508.09197].

Taken together, MX-AI advances Open and AI-RAN by closing the control loop in a live network through a cooperating graph of specialized agents wired into the SMO at R1, while remaining within non-RT O-RAN timing boundaries [2508.09197]. Its principal technical claim is not merely that LLMs can converse about RAN state, but that schema-grounded agents can deliver high-quality observability answers and reliable decision-action enforcement on live Open RAN infrastructure at non-RT timescales.

Source: https://www.emergentmind.com/topics/mx-ai