I have worked in network automation for the last 12+ years of my career. For more than a decade, I have watched the industry move from scripts, to APIs, to infrastructure as code, to platforms built around sources of truth and automated workflows. We have made a lot of progress.
But we are about to enter a very different phase. AI agents are moving from systems that answer questions to systems that can reason, plan, and take action. It is not hard to imagine what comes next for networking: find the problem, determine the fix, make the change, validate the result, and do it all without waiting for a human (anywhere along the way). We’ve heard about self-driving, self-healing, self-defending networks for decades. They are finally in sight.
There is a lot of discussion right now about how quickly AI capabilities are advancing and whether parts of the industry need to slow down, including Dario Amodei’s article, We Must Pace the Frontier. In network operations, I think we have almost the opposite problem. We need to speed up – not by rushing agents into production, but by accelerating the work required to make AI safe and useful in the network.
I believe that the future is in fact coming. I also believe there is a very dangerous way to build it.
AI agents cannot be allowed to talk directly to the network.
An agent should never be one prompt away from a router. Giving an LLM SSH access to a production network is not agentic network automation. Giving it unrestricted API access to controllers and devices is not much better. It bypasses the architecture we have spent years learning how to build.
LLMs are probabilistic systems. Networks should not be operated probabilistically, especially when those networks service systems where mistakes can have immediate and harmful consequences. These are the networks carrying credit card transactions, supporting financial trading platforms, connecting hospitals, running factories, and keeping critical business systems available. A bad answer from a chatbot is annoying. A bad action on a production network can take down critical healthcare systems, expose security vulnerabilities, stop revenue, damage customer trust, and disrupt thousands of users.
That does not mean AI cannot operate networks. It means we need the right layers between AI and the infrastructure, and now is the time to build them.
The Architecture
There are three layers I believe every organization needs before it can safely move toward agentic network operations: trusted data, deterministic automation, and governed operations. These are not new ideas. What is new is how important they become when software starts making decisions on our behalf.
1. Get the Data Right
Every useful AI system needs context. For network operations, that context has to describe the network accurately enough that software can reason about it.
What devices exist? How are they connected? Which interfaces, IP addresses, circuits, VLANs, VRFs, and routing relationships belong together? What is the intended state? What software versions should devices be running? What policies apply? Who owns the infrastructure? What changed?
Without that context, an agent is guessing. And most enterprises still have pieces of this information scattered across spreadsheets, controllers, ticketing systems, configuration files, diagrams, scripts, and many many people’s heads.
AI does not fix bad data. It makes bad data easier to act on, and that should make us uncomfortable. Know the age old saying, “garbage in is garbage out?”
Before we talk seriously about autonomous network operations, we need trusted network data that software can actually use. A real source of truth is no longer just an automation best practice. It is part of the safety architecture.
2. Build Deterministic Automation
This is the layer I think will get overlooked as AI gets better. There will be enormous temptation to let an agent generate commands and push them directly to the network.
Why build an upgrade workflow if the AI can figure out the upgrade? Why build configuration deployment automation if the AI can just log into the device? Because reasoning and execution are different problems.
We should use AI for the things AI is good at: understanding intent, analyzing context, troubleshooting, choosing between options, creating plans, and deciding which capability should be used. But when it is time to change the network, we should execute tested automation.
Upgrade this device. Deploy this intended configuration. Run this compliance check. Validate these BGP sessions. Create this VLAN. Roll back this change. These should be defined operations with known inputs, known outputs, validation, error handling, and predictable behavior.
Agents should use automation. They should not replace it.
If an agent decides that a configuration should change, it can call the approved configuration deployment workflow. The workflow should make the change, not the agent.
AI can decide what needs to happen. Deterministic automation should make it happen.
3. Govern the Agent
The reality is that even trusted data and good automation are not enough. Just because an agent can perform an operation does not mean it should be allowed to.
This is where governance comes in. Which tools or automations can this agent use? Which devices can it operate? Can it make production changes? Does this operation require approval? Is the change inside an approved maintenance window? Can the agent execute immediately, or only generate a plan? What happens if validation fails? Who can see what happened afterward?
Agentic operations need identity, permissions, scopes, policies, approvals, dry runs, audit trails, and controls around execution. Some actions may eventually be fully autonomous. Others may always require human approval.
The goal is not to remove humans from the network. The goal is to let humans define the boundaries within which software can safely operate.
AI Sits on Top
This leads to a simple architecture: data gives AI context, automation gives AI tools, and governance gives AI boundaries. The agents sit on top. The network sits underneath, and the agent never gets to bypass the “machine” in the middle.
Imagine a network engineer asking, “Upgrade our New York access switches to the approved software version this weekend.”
An agent should be able to understand the request, identify the devices, check the approved software version, review lifecycle information, look at dependencies, build the execution plan, determine which automation workflows are required, check policy, and request approval if necessary. Then it can invoke the approved automation, validate the network afterward, summarize the result, and record what happened. That is incredibly powerful.
But, notice what the agent did not do: it did not SSH into 200 switches and start typing commands.
That separation is the difference between an AI demo and an operational architecture.
Bottom Line: We Should Speed Up
There is a lot of discussion right now about whether AI needs to slow down. Network teams have a different problem: we need to speed up the work required to use it safely.
Get the data right. Build deterministic automation. Put governance around execution.
For years, network automation was mostly about efficiency: moving faster, reducing manual work, and improving consistency. Those benefits still matter, but the stakes are higher now. Network automation is the foundation for safe AI operations.
Now is the time to speed up. Let’s go!
-Jason
Tags :
