Before AI agents, the foundations

For the past few months, every conversation about networking has ended up in the same place: agents. Troubleshooting agents, configuration agents, operations copilots. The demos are impressive, the roadmaps are filling up, the budgets are following.

And yet, walking out of AutoCon 5, what struck me most was not an agent demo. It was a session by Víctor Fernández asking a far less glamorous question: is your data even in a state to support any of this?

I left convinced of something I keep seeing confirmed in the field: the first step of AI adoption in Network Operations is not AI. It is a certain level of network automation maturity: a source of truth that works and is actually adopted, proven automation workflows, observability that produces data you can trust.

The model is not the problem

When a network agent project fails, we almost always look for the cause on the wrong side. We switch models, rework the prompts, add tools, extend the context window.

But in the vast majority of cases, the model is not the weak link. The weak link is what we let it see.

An agent does not “know” your network. It only knows what your systems agree to tell it: an inventory, a topology, metrics, alarms, a change history. If that inventory is half wrong, if the topology dates back to the last migration, if the alarms are correlated to nothing, the agent will not notice. It will answer anyway. Quickly, confidently, and wide of the mark.

That is the real risk of AI applied to network operations, and it is more insidious than an outage: you do not end up without answers, you end up with wrong answers produced faster. Delivered in a tone that does not invite you to double-check them.

> why is the Lyon site slow?
Telemetry shows the main Lyon WAN link saturated at 92%.
I recommend failing traffic over to the backup link via core-lyon-02.
Would you like me to prepare the change?
answered in 1.8 s · confident tone
✗ core-lyon-02: decommissioned 8 months ago
✗ inventory: last updated 14 months ago

What “network context” actually means

We use the word “context” loosely. The AutoCon session gave it a definition I find useful because it is operational, and I complete it with a fourth dimension. Network context is the combination of four things:

• the relationships between services, devices, resources and customers: what depends on what, and who is impacted if it goes down;
• the operational state and real-time events: what is happening now, not what was true at the last export;
• the change history: what moved, when, and by whom;
• intent: the expected state of the network, the one described by the source of truth, as opposed to the observed state.

Intent is the dimension that answers the question every diagnosis eventually asks: is what I am observing normal? And together, the four form the bare minimum for reasoning: an incident analysis agent deprived of these four dimensions cannot reason correctly, any more than a network engineer who knows nothing about the infrastructure they are working on.

Look at that list and ask yourself honestly: in your environment, are these four dimensions accessible, reliable, and connected to each other?

For most of us, the answer is “partly”. The relationships and the intent live in a source of truth, when one exists. The real-time state lives in a monitoring tool that does not talk to the source of truth. The change history lives in a ticketing tool. These silos are exactly what prevents an agent from being useful, and none of them is solved with AI: they are data problems, not model problems.

It also has to be the right data, not just accurate data. As Daren Fulwell pointed out in the discussions that followed my first notes on the topic, telemetry correlated with configuration tells you what is happening on each device. But what the business cares about is how those devices work together to support applications. Telemetry says what is happening; it is the source of truth’s job to say what depends on what, who owns what, and where to fetch the relevant observability data. Access to configuration, in turn, closes the Act → Observe → Reason loop: without it, the agent observes but never acts.

That leaves correlation. Even when all of this information is available, it is built nowhere. The temptation is then to let the LLM reconstruct or guess the relationships by digging through the data: that is the wrong approach. It saturates the context window, and the result is neither deterministic, nor reproducible, nor testable, nor auditable. That is precisely one of automation’s roles: assembling that context upstream, in a deterministic, reproducible and auditable way, and handing it to the LLM as the foundation of its reasoning.

AI is the conductor, not the orchestra

I was already using this image a year ago to talk about automation. It is even more true today, and it applies to all of the foundations.

An LLM is a remarkably intuitive way to trigger and orchestrate work. But at the end of the chain, the work is always executed by automation, and it is always decided from data. AI conducts, it does not play: it only executes through tools, local or exposed via MCP, whose implementation is grounded in automation. Here again, in a networking context, automation is the bedrock of Agentic AI.

In other words:

• observability is the ability to perceive: without it, the agent acts blind;
• the source of truth is the ability to know: the intended state and the relationships, the reference against which you compare what you perceive and frame what you execute;
• automation is the ability to act: without it, the agent can recommend, but nothing happens. Your existing workflows are what executes: data collection, controlled changes, self-remediation.

If the orchestra cannot play, a better conductor will not produce better music. It will produce the same cacophony.

That is why it seems important to me that we stop treating automation and observability as second-tier technical topics, “enablers” to be funded later. In a world where AI lands on top of them, they have become strategic pillars. Their maturity mechanically caps the value of everything we build above.

The value chain, in order

If I had to sum up my conviction in one line, it would be this one:

Data quality → Observability → Context → Agentic AI → Value

It is a chain, not a menu. You cannot skip a link, and each link caps the ones after it. Concretely, this means:

1. Make the data trustworthy. The source of truth must be under control.
2. Build observability. Telemetry, topology, inventory, alarms, change history: collected, timestamped, queryable.
3. Correlate to produce context. The most often forgotten step. Data sitting side by side does not make context; you need the relationships between them.
4. Expose that context through APIs and workflows. That is what makes context consumable by something other than a human in front of a dashboard. It is also, very concretely, how the context window your LLM will reason over gets built.
5. Only then, plug in agents.

Víctor summed up the target shape of that context nicely in a reply to one of my posts: a real-time network graph (services, devices, resources, customers and their relationships), so the agent can actually navigate dependencies instead of juxtaposing exports.

The good news is that the first four steps deliver immediate value, with or without AI.

What I take away

AI is not a shortcut that lets you skip the years of automation and observability work you have not done. It is the opposite: it makes that work more profitable, and its absence more costly.

The teams that will get value out of agents in the next two years will not be the ones that picked the best model. They will be the ones with an accurate Source of Truth/Intent, an up-to-date topology, usable telemetry and a change history accessible through APIs.

So before asking yourself which agent to deploy, ask this question instead: if I had to explain my network to someone who has never seen it, using only my systems, could I?

If the answer is no, you know where to start. And it is not with AI.

Thanks to Víctor Fernández for the AutoCon 5 session that triggered this reflection.