By: Ranny Haiby

Every few months, our industry gets a new “does networking really need its own X” debate. We’ve had it about cloud native, about GitOps, and now we’re having it about agentic AI. The question on the table: can the agentic AI stacks being built for large enterprises and hyperscalers be applied to networks? Can the planning loops, the tool-calling frameworks, the multi-agent orchestration platforms simply be pointed at a telecom network and put to work? Or does the network domain need its own specialized agentic AI technology and open source projects?

My answer, after watching this space evolve inside LF Networking, is: both. Generic agentic AI architecture gets you most of the way there. But the last mile where an autonomous agent is trusted to touch a live, carrier-grade network, needs domain-specific engineering. Let me walk through why.

It’s worth being honest about how much operating a large-scale network has in common with automating a large enterprise IT estate. Both are exercises in managing enormous, heterogeneous systems where no single human can hold the full state in their head. Both involve:

• Distributed inventory and topology that changes constantly, whether that’s a fleet of Kubernetes clusters and SaaS entitlements or a mesh of routers, RAN sites, and transport links.
• Multi-step, multi-system workflows, where a single request (provision a new customer, resolve an incident) touches many owning systems, not one.
• A need for reasoning over telemetry, correlating logs, metrics, and events to diagnose root cause before acting.
• Policy and compliance guardrails that must constrain what an autonomous system is allowed to do, and to whom it must answer.
• Human-in-the-loop escalation, because full autonomy is a spectrum, not a switch, in both the enterprise IT world and the network world.

Given that overlap, it would be wasteful for the networking industry to reinvent agent orchestration, planning, and reasoning from scratch. A lot of the foundational plumbing of agentic AI is genuinely domain-agnostic, and networking should adopt it as-is wherever it fits.

A good chunk of the current agentic AI toolchain travels well into the network operator’s world with little or no modification:

• Agent communication protocols, most notably the Agent2Agent (A2A) protocol that Google open sourced and that has since moved to community governance under the LF. A2A’s core value proposition is a common language so agents built on different frameworks (LangGraph, CrewAI, Semantic Kernel, or something homegrown) can discover each other’s capabilities and exchange tasks. This is exactly as useful for connecting an inventory agent to a ticketing agent as it is for connecting a billing agent to a fulfillment agent.
• Model Context Protocol (MCP) for giving an LLM-based reasoning engine structured, real-time access to tools and data sources, rather than relying on the model’s static training knowledge.
• General-purpose orchestration and workflow frameworks for defining sequential and hierarchical multi-agent pipelines, retries, and state handoff.
• Vector stores, RAG pipelines, and general observability tooling for grounding agents in an operator’s own documentation, runbooks, and knowledge bases.
• GitOps-style declarative delivery, which frankly the network domain has already been building on its own for years through projects like Nephio and ONAP, and which agentic systems can plug into as a safe way to turn intent into state.

None of this needs to be re-invented under a networking-specific banner. It’s good engineering, and LF Networking projects are increasingly built to consume it rather than compete with it.

That said, three characteristics of production networks push past what generic enterprise agentic AI stacks were designed to handle.

1. Scale and structure of configuration and telemetry. Large operator networks generate telemetry volume and structured configuration models (YANG, TM Forum, vendor specific schemas) far more complex than typical enterprise SaaS estates. Agents require purpose-built context-layer tools to interpret these interdependent structures rather than being overwhelmed by raw counters.

2. Resilience and uptime as a non-negotiable constraint. Unlike enterprise IT, telecom networks are critical infrastructure where agent errors can disrupt emergency services and millions of subscribers. This necessitates domain-specific engineering, including closed-loop safety mechanisms, staged and reversible actions, strict authorization boundaries, and regulatory audit trails.

3. Multi-vendor, cross-domain trust. While hyperscaler stacks function within a single trust boundary, network operators must deploy agents that reason and act across different vendors, operators, and nations, each maintaining unique security postures. This presents significantly harder interoperability and trust challenges.

This is exactly the design philosophy behind two of our newer projects, Essedum and OpenAN, and it’s why I think they’re a good model for the “adopt generically, extend specifically” approach.

Essedum, contributed by Infosys and now an LF Networking project, is deliberately built as an integration and orchestration framework rather than a competing ML platform. It gives network teams an intent and orchestration layer that sits on top of existing projects like Nephio and ONAP for GitOps-based delivery, and a context and interoperability layer that combines CAMARA network APIs with MCP so that agents get real, structured network awareness instead of generic tool access. Essedum isn’t trying to replace the enterprise AI stack; it’s trying to make that stack network-literate.

OpenAN is, in my view, the clearest example of the right pattern. Rather than inventing a brand-new agent communication protocol, OpenAN (contributed by China Mobile and Huawei) took the existing A2A protocol and extended it into A2A-T, purpose-built for telecom. A2A-T keeps A2A’s core interoperability model intact, but adds what the network domain actually needs on top: a structured task schema for network operations, network event subscription and publication so agents can react to live conditions, an inter-agent negotiation mechanism for cases where multiple agents need to arbitrate an action, and stronger authorization controls appropriate for infrastructure that can’t tolerate a rogue or compromised agent. OpenAN pairs that protocol extension with a registry center for agent discovery and lifecycle management and an orchestration center for building and running multi-agent workflows aligned to TM Forum’s Autonomous Networks framework. It is built to slot into the generic agent ecosystem rather than sit apart from it.

That’s the pattern I’d encourage the broader industry to follow: don’t fork the base protocol, extend it. Don’t rebuild the orchestration layer, integrate with it. Spend your specialized engineering effort on the parts that are genuinely different such as the telemetry scale, the safety guarantees, the multi-vendor trust model, and inherit everything else.

So, does agentic AI networking need specialized technology and open source projects? Yes. But not because generic agentic AI is wrong for networks. It’s because generic agentic AI is necessary but not sufficient. The frameworks, protocols, and architectural patterns coming out of the broader AI industry are a genuinely strong foundation, and open source networking projects should keep building on them aggressively rather than duplicating them out of turf-protection instinct. What LF Networking’s projects are adding is the last mile: the domain awareness, the safety envelope, and the cross-vendor interoperability that a network operator actually needs before it will let an autonomous agent anywhere near a live, critical network.If you’re building in this space, I’d rather see your team’s energy go into that last mile than into rewriting A2A or MCP from scratch. Come help us build it in Essedum,OpenAN and the rest of the LF Networking projects.