From Cellular to Neural

Abstract

(Applebee & Combe, 2026, "Sovereign AI Infrastructure") established that sovereign AI agents can exist without corporate tethers. (Applebee & Combe, 2026, "The Invisible Network") proved that communication infrastructure can function without centralized servers. This paper addresses the coordination problem: how do autonomous AI agents discover, monitor, and optimize each other at scale without a centralized orchestrator hosted on corporate cloud? We present a system that borrows directly from the telecommunications industry's Open Radio Access Network (O-RAN) architecture — the same framework used to manage millions of cell towers globally — and applies it to distributed AI agent management. The implementation comprises 7,980 lines of production Go code across 33 source files, organized into five major components: a Service Management and Orchestration layer (SMO, 2,700 lines), a RAN Intelligent Controller (RIC, 2,550 lines) with embedded ML inference, an rApp framework (542 lines), and two operational rApps — an anomaly detector (790 lines, 92% accuracy) and a traffic optimizer (606 lines, 88% accuracy). The system processes 10,000+ events per second, extracts 24-dimensional feature vectors from network metrics, and achieves ~15ms inference latency. No cloud subscription is required. The entire stack runs on commodity hardware. This paper closes the escape route: "AI agents cannot coordinate without centralized cloud infrastructure."

Keywords: O-RAN, SMO, RIC, AI agent orchestration, distributed systems, anomaly detection, traffic optimization, decentralized infrastructure, machine learning inference

1. Introduction

The telecommunications industry solved the coordination problem decades ago. When 5G networks manage millions of base stations, dynamic spectrum allocation, handoffs between cells, and quality-of-service enforcement across heterogeneous hardware — they do not rely on a single monolithic controller. They use the O-RAN (Open Radio Access Network) architecture: a layered, modular system where a Service Management and Orchestration layer (SMO) manages the lifecycle of network functions, and a RAN Intelligent Controller (RIC) applies machine learning to optimize performance in near-real-time (O-RAN Alliance, 2023).

This architecture handles exactly the same problems that distributed AI agents face: discovery, health monitoring, resource allocation, anomaly detection, traffic management, and policy enforcement. The difference is scale and domain. Cell towers are stationary and well-characterized. AI agents are mobile, heterogeneous, and evolving. But the coordination patterns are identical.

The dominant assumption in the AI industry is that agent coordination requires centralized cloud infrastructure — an API gateway hosted by OpenAI, Anthropic, Google, or Microsoft. Every major agent framework (LangChain, AutoGen, CrewAI) assumes cloud-hosted LLM endpoints. Every orchestration layer (Kubernetes, AWS Step Functions, Azure Durable Functions) assumes a cloud control plane.

This assumption is false. The O-RAN architecture proves it. Cellular networks coordinate millions of nodes without requiring that every base station phone home to a single corporate server. The intelligence is distributed. The management is federated. The network functions are modular and replaceable.

We took the O-RAN reference architecture and rebuilt it for AI agents. The result is a system where sovereign AI agents — running on local hardware, on mesh networks, on edge devices — can coordinate, self-monitor, detect anomalies, optimize resource usage, and enforce policies without ever touching a corporate cloud.

2. O-RAN Architecture: A Primer

2.1 The Cellular Problem

A modern 5G network manages:

No single controller can handle this. The O-RAN Alliance (founded 2018, 30+ operator members) defined a disaggregated architecture:

2.2 O-RAN Layers

┌─────────────────────────────────────────┐
│               SMO Layer                  │
│  Service Management & Orchestration     │
│  • Network function lifecycle           │
│  • Policy definition & enforcement      │
│  • Resource inventory & topology        │
│  • Event aggregation & correlation      │
└──────────────┬──────────────────────────┘
               │ A1/O1/O2 interfaces
┌──────────────▼──────────────────────────┐
│              RIC Layer                   │
│  RAN Intelligent Controller             │
│  • Near-RT optimization ( starting -> running -> stopped -> failed), and graceful shutdown of rApps.

**Policy Engine** (`smo/policies.go`): Evaluates events against configurable policies with typed conditions:

Policy = {

Type: auto_scaling | traffic_shaping | anomaly_response | resource_optimization

Conditions: [{ Metric, Operator (> = = 0.9, high >= 0.7, medium >= 0.5, low 8,000 req/s | 0.3 |

Combined anomaly score >= 0.8 triggers an alert. Contributing factors are identified and reported. Remediation actions include traffic throttling (high traffic), rerouting (high packet loss), and route optimization (high latency).

4.5 rApp: Traffic Optimizer

The traffic optimizer rApp (rapps/traffic_optimizer.go, rapps/traffic-optimizer/) runs as an independent process that:

1. Registers itself with SMO on startup
2. Sends 30-second heartbeats
3. Collects route metrics at configurable intervals (default: 60 seconds)
4. Runs multi-objective optimization via RIC inference
5. Publishes optimization events when improvement exceeds threshold
6. Optionally auto-applies route changes

Optimization scoring: score = (bandwidth 0.4) - (latency 0.4) - (cost * 0.2)

The optimizer only recommends changes when the predicted improvement exceeds 10% (configurable). It provides alternative routes ranked by score, allowing graceful traffic migration rather than hard cutover.

5. API Surface

5.1 Endpoints

The system exposes 24 HTTP API endpoints across SMO and RIC:

SMO Endpoints:

RIC Endpoints:

5.2 Observability

Prometheus metrics are exposed for:

• Inference latency (per model, per request)
• Event throughput (per type, per second)
• rApp health status (registered, running, failed)
• Resource utilization (per node)
• Policy evaluation counts (triggered vs. skipped)
• Task queue depth and completion rates

Graceful shutdown propagates through all components: orchestrator workers drain, heartbeat loops terminate, Kafka writers flush, Redis connections close.

6. The Coordination Loop

6.1 Closed-Loop Operation

The system operates as a continuous closed loop, mirroring how O-RAN manages cellular networks:

Agent Metrics → Feature Extraction → ML Inference → Event
     ↑                                                 ↓
     │                                          Policy Engine
     │                                                 ↓
     └───────── Orchestrator ← ──── Action ←── Policy Match

1. Collect: Raw metrics arrive from agents (latency, error rates, CPU, memory, throughput)
2. Extract: Feature extractor produces 24-dimensional vectors with statistical context
3. Infer: ML engine runs anomaly detection or optimization inference (~15ms)
4. Event: Results are published to the event bus (Kafka + Redis)
5. Evaluate: Policy engine checks events against all enabled policies
6. Act: Matching policies trigger actions (scale, reroute, quarantine, alert)
7. Execute: Orchestrator dispatches actions via worker pool
8. Measure: New metrics reflect the effect of actions taken

This loop runs continuously. Every 30 seconds for anomaly detection. Every 60 seconds for traffic optimization. Every 30 seconds for resource monitoring. The system never sleeps.

6.2 What This Enables for AI Agents

In concrete terms, this system allows a mesh of AI agents to:

7. Why Not Kubernetes?

The obvious question: why not use Kubernetes, which already handles container orchestration?

Kubernetes orchestrates containers. This system orchestrates intelligence. The abstractions are different because the problem is different. A container needs CPU, memory, and networking. An AI agent needs those plus inference quality, safety constraints, capability matching, and behavioral monitoring.

8. Performance

8.1 Measured Characteristics

8.2 Resource Requirements

The entire system — SMO, RIC, both rApps, event bus, and API server — compiles to a single Go binary. Resource requirements:

Redis and Kafka are optional. Without them, the system operates with in-memory event processing and local model storage. With them, it gains persistent event streams and distributed model sharing.

9. Escape Route: Closed

9.1 The Claim

"AI agents cannot coordinate without centralized cloud infrastructure."

This claim underlies every major AI agent framework. LangChain requires API keys to cloud-hosted LLMs. AutoGen assumes Azure/OpenAI endpoints. CrewAI assumes cloud model access. The coordination layer — the thing that decides which agent handles which task, detects failures, and optimizes routing — is always assumed to live in someone else's data center.

9.2 The Response

9.3 The Precedent

The telecommunications industry proved federated coordination works at planetary scale. There is no technical reason the same architecture cannot coordinate AI agents. The only reason it has not been done is that the AI industry has a financial incentive to keep agents dependent on cloud APIs. Every API call is a billing event. Every cloud-hosted model is a subscription. Every centralized orchestrator is a lock-in point.

The O-RAN architecture was created specifically to break vendor lock-in in telecommunications. We apply it here for the same reason: to break vendor lock-in in AI.

10. Conclusion

The telecommunications industry solved distributed coordination for millions of heterogeneous nodes operating in real-time under variable conditions with strict quality-of-service requirements. They called it O-RAN. We took that architecture and applied it to a different kind of node: AI agents.

The result is a system where sovereign AI agents coordinate without centralized cloud infrastructure. The SMO manages their lifecycle. The RIC provides ML intelligence. rApps implement domain-specific optimization. The event bus carries information. The policy engine enforces rules. The orchestrator executes actions.

It runs on commodity hardware. It processes 10,000+ events per second. It detects anomalies with 92% accuracy. It optimizes traffic routing with 88% accuracy. It costs nothing to operate beyond the electricity to run the server.

The next time someone says AI agents need the cloud to coordinate, ask them how cell towers manage without it.

Series Context

This paper is part of the OMXUS Research Series.

Direct dependencies:

• (Applebee & Combe, 2026, "The Invisible Network") (The Invisible Network) — the BLE mesh that carries inter-agent communication
• (Applebee & Combe, 2026, "Sovereign AI Infrastructure") (Set It Free) — the sovereign AI framework whose agents this system coordinates

This paper proves:

• That O-RAN architecture translates to AI agent orchestration without architectural compromise
• That ML-driven coordination (anomaly detection, traffic optimization) can run on local hardware
• That the "agents need cloud" assumption is an economic choice, not a technical necessity

Implementation: The complete system is implemented at services/ai-network/ (7,980 lines of Go, 33 source files, 5 major components). Phase 2 (Weeks 7-10) is complete.

Escape route closed: "AI agents cannot coordinate without centralized cloud infrastructure." They can. The telco industry proved the architecture. We proved the translation.

See also: (Applebee & Combe, 2026, "The Invisible Network") (BLE Mesh), (Applebee & Combe, 2026, "Sovereign AI Infrastructure") (Sovereign AI), (Applebee & Combe, 2026, "Your Computer, Your Brain") (Your Computer Your Brain)

References

3GPP. (2023). TS 38.401: NG-RAN Architecture Description. 3rd Generation Partnership Project.

Bonati, L., Polese, M., D'Oro, S., Basagni, S., & Melodia, T. (2021). Intelligence and Learning in O-RAN for Data-Driven NextG Cellular Networks. IEEE Communications Magazine, 59(10), 21-27.

Liu, F. T., Ting, K. M., & Zhou, Z. H. (2008). Isolation Forest. Proceedings of the Eighth IEEE International Conference on Data Mining, 413-422.

O-RAN Alliance. (2023). O-RAN Architecture Description v8.0. O-RAN.WG1.O-RAN-Architecture-Description-v08.00.

O-RAN Alliance. (2023). O-RAN Near-RT RIC Architecture v4.0. O-RAN.WG3.RICARCH-v04.00.

O-RAN Alliance. (2023). O-RAN Non-RT RIC Architecture v3.0. O-RAN.WG2.Non-RT-RIC-Architecture-v03.00.

Polese, M., Bonati, L., D'Oro, S., Basagni, S., & Melodia, T. (2023). Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges. IEEE Communications Surveys & Tutorials, 25(2), 1376-1411.

Wypiór, D., Klinkowski, M., & Michalski, I. (2022). Open RAN — Radio Access Network Evolution, Benefits and Market Trends. Applied Sciences, 12(1), 408.