Not Every Network Problem Needs an LLM
This is my second blog post coming out of Networking Field Day 40. The first focused on networking for AI, specifically the presentations from Arista, Cisco, and Nokia. This one turns the lens around: instead of looking at the networks needed to support AI, I want to talk about how AI is being applied to network operations.
The NFD40 delegates
At NFD40, Selector and NetAI both presented on Friday, April 10, 2026. Selector AI was represented by Reza Koohrangpour and Varija Sriram, while NetAI was represented by Deepak Kakadia, Mike Hoffman, and Irfan Lateef. These two sessions were especially interesting to me because they helped move the discussion beyond the current industry habit of treating “AI” and “LLM” as if they are interchangeable terms. They are not.
Large language models are powerful, useful, and currently getting the majority of the attention. But AI is not one thing. AI is a diverse field encompassing multiple subfields and specialized techniques, including deep learning, neural networks (like graph neural networks), reinforcement learning, and machine learning, alongside models dedicated to tasks such as natural language processing, audio and visual processing, anomaly detection, clustering, classification, and predictive analytics. In many systems, AI techniques are also combined with non-AI computational methods such as graph theory, statistical regression, rules engines, topology analysis, and domain-specific heuristics.
That distinction matters a lot in NetOps. Network operations problems are not all the same. Some problems are language problems. Some are graph problems. Some are time-series problems. Some are correlation problems. Some are workflow problems. Some are data quality problems pretending to be AI problems. If we treat every problem as a prompt waiting for an LLM, we risk using an expensive general-purpose tool where a more precise, cheaper, and more explainable tool would be better.
That was one of my biggest takeaways from Selector and NetAI at NFD40: the most interesting work is not “AI everywhere.” It’s decomposition. First break the operational problem into smaller elemental problems, then use the right tool for each one.
Correlation, context, and customer-driven operational intelligence
Selector’s NFD40 presentation was grounded in a very practical operational reality. They explained that enterprises are not suffering from a lack of data. Instead, they’re suffering from fragmented data, too many dashboards, too many alerts, and too much manual correlation. Selector described customers with many observability tools, each providing only a partial view of the environment. The result is dashboard overload, alert storms, and engineers manually stitching together clues during incidents.
Selector’s approach was described around three layers including collection, correlation, and collaboration. First they collect heterogeneous data from more than 300 telemetry sources, including alerts, configuration, logs, metrics, and events. The correlation layer uses machine learning to establish baselines, detect anomalies, and correlate signals across teams, domains, and sources. And finally the collaboration layer pushes insights to the right people in the tools where they already work, such as ServiceNow, Slack, or Teams.
That’s an important architecture pattern. The LLM or Copilot interface may be the most visible part of the product experience, but the value isn’t just in the chat interface. The value is in data normalization, signal selection, correlation, baselining, anomaly detection, and the packaging of operational context in a way that an operator can trust.
Notice in the slide on the right from Selector’s presentation that they differentiate themselves by being a unified, programmable data pipeline for explainable AI.
This is extremely important. Before we apply any AI models, before we identify correlations, before we chat with our network with a network chatbot, we need carefully designed data pipelines built on much of the traditional MLOps and data engineering practices we’ve used for years.
From data ingest, transformation and normalization, adding context, and ultimately actionable AI insight, this means Selector isn’t simply a neat AI overlay. Instead, it’s deeply embedded in the network data that we care about in NetOps making AI relevant, useful, and trustworthy.
That theme also showed up in the Network Automation Nerds podcast recorded at Selector’s AI for Network Leaders event. Eric Chou and I were joined by Surya Nimmagadda, Selector’s Chief Data Scientist, and Joby Rudolph, Selector’s Senior Distinguished Engineer. The episode focused on the importance of the data behind AI in networks, including transparency, customer-specific priorities, and how Selector’s core AI model combines with a data hypervisor layer to acquire what the show notes called a network-specific personality.
I also appreciated how Selector’s representatives tied their technology back to customer problems. Reza Koohrangpour and Varija Sriram didn’t present AI as magic dust sprinkled over a dashboard. They described operational friction: too many tools, too much telemetry, too much noise, and too much manual effort. That framing matters because successful AI in NetOps is not about showing that a model can answer a question. It’s about reducing toil, improving confidence, shortening mean time to repair, and helping operators act faster with better context.
The Selector AI for Network Leaders event reinforced this same theme. Another Selector session with Joby Rudolph and James Schnebly focused specifically on how AI agents are designed, implemented, and applied in real-world network environments, including how customers are applying agents in production and where agentic AI is headed for NetOps.
One of the comments I especially appreciated from Joby Rudolph was around how transformative agentic AI has been for Selector’s own internal software development. That’s worth paying attention to. The conversation about AI in networking is not limited to troubleshooting production networks but also includes how vendors build, test, ship, and iterate on the software operators will use.
Networks are graphs, not paragraphs
NetAI’s presentation took a different path, and I appreciated how direct they were about it. Mike Hoffman opened by saying NetAI is not an LLM-based machine; instead, it’s a graph neural network-based (GNN) machine. He framed their focus as deterministic, operator-verifiable root cause analysis as a prerequisite for safe autonomous networks. You can read Phil Gervasi’s piece explaining GNNs and NetAI’s approach here.
NetAI’s argument - actually, their statement of reality - is that networks are graphs. They’re made of nodes, edges, relationships, paths, dependencies, protocols, layers, and topology.
LLMs are excellent at language, but NetAI’s position is that graph neural networks are a better fit for modeling network behavior and diagnosing root cause because they can represent the relationships between network elements more directly.
NetAI’s argument - actually, their statement of reality - is that networks are graphs. In the screenshot below from their platform, you can see that clearly they’re made of nodes, edges, relationships, paths, dependencies, protocols, layers, and topology. LLMs are excellent at language, but NetAI’s position is that graph neural networks are a better fit for modeling network behavior and diagnosing root cause because they can represent the relationships between network elements more directly.
Deepak Kakadia expanded on that point by saying that many current AIOps approaches rely on probabilistic or best-guess methods, while NetAI is focused on deterministic root cause based on network structure and causal relationships. He also contrasted GNNs with knowledge graphs, arguing that GNNs can learn over time and capture patterns that are not obvious, while static knowledge graphs require manual updates as the network changes.
Another important point from NetAI was scope. When asked how deep into the stack they go, Deepak was very clear that NetAI is focused on networking. They can help rule in or rule out network causes from Layer 4 down to Layer 1, including optical transport, but they aren’t trying to be the application performance tool, the database tool, and every other tool at once.
That kind of boundary-setting is healthy. NetOps has seen many “single pane of glass” promises over the years, but many have become a “single glass of pain” because it tried to do too much or blurred problem domains beyond usefulness. NetAI’s focus on network root cause, graph relationships, and deterministic analysis is a good example of using a purpose-built technique for a decomposed problem.
NetAI also made an interesting point about ROI. Mike Hoffman described a non-AI NetAI Core product, with the graph neural network-based AI functionality as an upgrade path. That’s notable because it implicitly acknowledges something I expect we will discuss more often, namely that not every useful operational capability requires expensive AI inference. As token costs, GPU costs, and operational costs become more visible, teams will look harder at where traditional software, statistical analysis, graph algorithms, and deterministic logic can produce better ROI than throwing every problem at a large model.
The governance question: from Vibe Coding to Spec Driven Development
The more powerful these tools become, the more governance matters. This goes beyond what we discussed at NFD40, but it’s important to think about how we are using these new power tools of AI.
I’m not against vibe coding. It’s incredible for prototyping, ideation, exploration, and empowerment. It can also help people move from idea to working example incredibly quickly. But without the right guardrails, vibe coding can also miss important requirements and create messy, unmaintainable code.
That’s why I’m increasingly interested in Spec Driven Development, or SDD. SDD represents a maturation beyond vibe coding. Instead of starting with “build me something that feels like this,” SDD starts with system intent, requirements, constraints, interfaces, assumptions, and expected behavior. The architect or product owner drives the specification, and agents or models help instantiate the system envisioned by that specification.
That model maps well to NetOps. Networks are systems of systems and operational platforms are systems of systems. AI-assisted automation needs to be governed by clear intent, explicit requirements, testable outcomes, and well-defined boundaries. The more we decompose problems into subsystems, the more important it becomes to define what each subsystem is responsible for, what inputs it consumes, what outputs it produces, and how we validate its behavior.
Think in systems, not slogans
What excited me most about Selector and NetAI at NFD40 was not simply that both companies are using AI. Plenty of companies are using AI, or at least using the term AI. What excited me was that both companies showed signs of thinking carefully about which techniques fit which problems.
Selector is using AI and machine learning as part of a broader platform for collection, correlation, collaboration, and operational context. NetAI is using graph neural networks and graph-based reasoning to attack deterministic root cause analysis in network environments. Both are examples of moving beyond “just ask an LLM” toward more thoughtful system design.
In fact, that’s where I think NetOps is headed.
We’re on the verge of new ways to attack operational problems across networking and IT including optical networking, wireless networking, IP networking, security, application performance, and more. The opportunity is to decompose problems, understand the systems and subsystems involved, and apply the right technique to the right job.
Sometimes that will be an LLM. Sometimes it will be a smaller or specifically-trained model. Sometimes it will be machine learning. Sometimes it will be a graph neural network. And sometimes it will be statistics, graph theory, deterministic logic, or a boring script that works every time.
That’s not a step back from AI. That’s what mature AI adoption should look like.
