f49c0f45dd
Configure Hugo multilingual mode (fr default, en secondary) with Hextra's language-switch menu entry, and translate all existing content pages to English using Hugo's per-file language suffix convention (.en.md alongside .fr.md).
10 KiB
title, date, authors, tags
| title | date | authors | tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AIOps and Network Observability: Preparing the Ground for AI | 2026-07-14 |
|
|
I just finished building a full observability stack on my EVPN/VXLAN lab: topology, telemetry, and near real-time visualization. While building it, I realized I wasn't just doing monitoring — I was preparing a network to one day be "seen" by an AI. This first article sets the frame for a five-part series: why observability is the mandatory prerequisite before plugging an agent into your infrastructure.
What I've actually just built
Over the past few months, I've set up a Containerlab EVPN/VXLAN lab with 28 Arista EOS devices, spread across three sites (campus, core, datacenter). Beyond BGP EVPN itself, I wanted this lab to be observable: to be able to say, at any moment, what the real state of the network is. Not just "does it ping," but what the actual topology is, which interfaces are up, and which counters are drifting.
The result is a stack combining four building blocks:
- a network discovery and assurance tool that serves as the topological source of truth (who is connected to whom, which VLANs, which VRFs);
- telemetry collection via gNMI directly from the EOS devices;
- a time-series database for metric storage;
- a visualization layer automatically regenerated by cross-referencing topology and metrics.
It works today. But it's not the stack itself that made me write this article: it's a realization I had while building it. I wasn't just setting up monitoring — I was laying the foundations of a pipeline that could, one day, allow an AI agent to reason about my network. And that has a name.
AIOps, not MLOps
Let's clear up an ambiguity right away, because the two terms are often conflated.
MLOps (Machine Learning Operations) is the discipline of operationalizing the lifecycle of machine learning models: training, dataset versioning, deployment, drift monitoring. That's not what I'm doing here. I'm not training any model, I'm not deploying any.
What I'm doing falls under AIOps: making an infrastructure observable and usable by automated systems, and eventually by an AI. The center of gravity isn't the model, it's the infrastructure data: its freshness, its consistency, its structure. That's exactly the scope of this series.
I still cite MLOps once, as a sister discipline, because it's the one that normalized an idea AIOps directly inherits: observability isn't an option you bolt on afterward, it's the foundation everything else rests on. The ML community learned this the hard way: a large share of projects that work in a notebook never survive the move to production, for lack of monitoring. The lesson applies to any system we claim to delegate to a machine. Including a network.
The blind agent
Here's the central thesis of this article, and the thread running through the whole series.
An AI agent without observability is a blind agent. It only "sees" what it's exposed to. And a blind person given nothing to see doesn't stop moving for that reason: they keep going, with the same confidence as if they could see clearly.
Take a concrete case. I migrated a server from one VLAN to another last weekend. The topological source of truth hasn't yet gone through its discovery cycle: it still describes the old attachment. I open a conversation with an agent that's supposed to help me: "this server has stopped responding since this morning, where's the problem?"
The agent queries what it's been exposed to, reads the old topology, and answers confidently: "The server is attached to leaf-3 on VLAN 20, the uplink is nominal, check its IP configuration instead." The answer is coherent, well phrased, well argued. It's also entirely wrong: the server has been on leaf-7 since Saturday. The agent didn't lie, it didn't hallucinate in the strict sense: it reasoned correctly over stale data. And at no point did it flag that it might be wrong, because at no point was it aware that it couldn't see.
That's the real danger. An experienced human compensates for lack of observability with intuition, tribal memory, historical context ("that link has always been flaky, don't worry about it"). An agent has none of that. Partial data, stale data, or an inconsistency between the declared topology and the real state doesn't make it cautious: it makes it wrongly confident. The assurance of the answer generated in natural language masks the poverty of what it actually perceived.
I should note that no agent runs on this lab today: that will be precisely the subject of the last article in this series.
Observability, then, is not an end in itself. It's the condition of possibility for an agent to one day see the network before acting on it. Without it, you're not building an assistant: you're building a confidently blind one.
A layered reading grid
What helped me structure all this was thinking in stacked layers, and accepting that you don't skip a step:
- Infrastructure first. Is the base data reliable, complete, up to date? Topology, metrics, logs.
- The model next. What's built on top: a correlation rule, a model, an LLM — does it receive quality inputs, and can its relevance be measured over time?
- Agent behavior last. Can its answers and actions be trusted, and can they be audited?
The order isn't negotiable. An agent built on top of a shaky layer 1 inherits all its weaknesses in cascade, with the added bonus of the illusion of reliability that comes from an assertive answer by construction. You can't make up for a poorly instrumented infrastructure with a better prompt.
Applied to the network, this gives a very concrete order of priorities: before thinking "AI," you need reliable telemetry, an up-to-date topological source of truth, and usable logs. That's layer 1. It's what I've been working on for months, and it's what this series is going to detail.
What "seeing" means for a network
Concretely, giving a network agent sight means bringing together three things:
- An up-to-date topological source of truth. Who is connected to what, which VLANs, which VRFs, which site. Without it, the agent doesn't even know what it's talking about: this is the core of the next article.
- Real-time telemetry. The living state of the network: interfaces up/down, counters, utilization, drift. Topology tells the structure; telemetry tells the behavior.
- Usable logs. The narrative of events: who changed what, when, and which errors were raised.
Of these three pillars, two are in place on my lab. The third, logs, remains a work item I haven't tackled yet. I say this honestly, because it's the kind of gap you're tempted to sweep under the rug: "I have the topology and the metrics, that's already good." Except an agent deprived of logs sees the present state without understanding how it got there. It's a prerequisite, not a bonus.
There's a principle running through this entire layer 1, one I've set for myself as a rule: standardization over adaptability. When naming conventions are respected everywhere: interfaces, hostnames, labels, no code has to compensate for discrepancies. It's a human who fixes the configuration upstream, not a script that guesses. This choice has a cost, ongoing rigor, but a direct benefit: clean, predictable data. And clean data is precisely what allows an agent to avoid building sound reasoning on false facts.
Seeing isn't enough: you have to make it visible
Gathering the data: topology, telemetry, logs, isn't enough: it still needs to be structured and intelligently exposed to the agent, rather than dumped on it wholesale, at the risk of saturating its context window and getting answers just as confident but just as unreliable. This is where two concepts worth remembering come in, context engineering and the Model Context Protocol (MCP), which I'll cover in detail in the fifth and final article of this series.
The series
This series will follow the order in which I built (and am still building) this stack:
- (this article) AIOps and the importance of network observability: the general framework.
- Topology as source of truth: using network discovery and assurance to drive the rest of the stack.
- Real-time telemetry: the mechanics of metrics and time series, from device to dashboard.
- Log management: the piece still missing from my stack, which I need to tackle before going further.
- Making the network "visible" to an AI agent: context engineering, MCP, and the early steps of AIOps applied to my lab.
Conclusion
None of this is revolutionary in isolation: network telemetry has been around for a long time. What changes is the frame. As long as you instrument a network for humans, missing data translates into a question mark, someone notices the gap and goes looking for the info elsewhere. The day you plug in an agent, that same gap no longer produces doubt: it produces a wrong answer, stated with confidence.
That's why observability comes first, and the agent comes last: not because AI is a side matter, but because it's blind by default, and you don't hand a system its eyes before building what it's supposed to see. If you're building something similar, I'd be curious to compare notes on your architecture choices.
Resources
Concepts
- What is AIOps? — definition and origin of the term (Gartner)
- Model Context Protocol — official documentation
- Introducing the Model Context Protocol — the original announcement, which frames well the problem MCP solves
- Effective context engineering for AI agents — the reference article on context engineering, including the phenomenon of context window saturation
- Observability Engineering (O'Reilly, 2nd edition), Charity Majors, Liz Fong-Jones, George Miranda: the field's reference book, with a chapter dedicated to the rise of agents and LLMs