using WordPress and 
Every time I talk about AI with other network engineers, the same question comes up sooner or later, usually with a little edge to it. We work on physical things. Copper, glass, optics and the occasional cable somebody swears they didn’t unplug. So how exactly is a chatbot supposed to take over that job?
It’s a fair question, and it deserves a straight answer instead of hype or denial. Here’s mine: AI agents aren’t going to rack a switch for you, but they can already do a real slice of the work that happens after the switch is racked. I know because I watched two of them do it in my home lab.
The elephant in the wiring closet
Network engineering has always had two halves. There’s the physical half: the gear, cabling, power, cooling and the labels that make 2 AM troubleshooting survivable. Then there’s the logical half: the configuration, routing, policy and troubleshooting that make the hardware do something useful.
A digital bot can’t touch the first half. It has no hands. It can’t reseat an SFP, trace a mislabeled patch cable or notice that a fan sounds wrong. Those jobs still need a person standing in front of the rack.
The second half is a different story. Configuration is text. Show command output is text. Logs, routing tables and interface counters are text. And text is exactly what large language models are built to read and write. That’s the elephant. Not that AI replaces the network engineer, but that a meaningful share of what we do all day is already the kind of work agents are good at.
Even AI needs network engineers
Here’s the irony I think gets lost. AI itself is one of the most network hungry workloads ever built. Training and serving large models means GPU clusters that have to move enormous amounts of data between each other with very little tolerance for delay or loss. Somebody has to design those fabrics, cable the racks and troubleshoot them when a job crawls because of one bad link. I went deeper on this in Why AI Is Secretly a Networking Problem, and the short version is that the smarter the models get, the more they depend on the network underneath them.
So no, AI doesn’t make infrastructure go away. AI is infrastructure. In the world of AI, the network is still the network, and it still needs people who know how to build it.
What agents can tackle today
If you strip away the marketing, the work agents can realistically take on right now is the foundational stuff: tasks that are repetitive, well documented and easy to verify.
- Config provisioning. Turning a plain language intent into device configuration.
- Configuration review. Reading a config and flagging what’s missing, inconsistent or risky.
- Troubleshooting. Running show commands, reading the output, correlating it with logs and narrowing down where a problem lives.
- Documentation. Port maps, interface descriptions, as-built notes and change summaries. The stuff we rarely keep current.
None of that is glamorous. All of it eats hours.
A blank router, two agents and one conversation
I started with a blank Cisco Catalyst 8500L edge router, model C8500L-8S4X, with absolutely no configuration on it. By hand, I gave it only the bare basics: a management address, a hostname, a crypto key and SSH enabled. That’s it. Just enough to reach it and log in. Then I connected it to my home lab network.
My home lab runs a local AI stack built around Qwen 2.5 32B, an open-weight model, with agent workflows on top. If you’re curious what it takes to run a model like that yourself, I covered the hardware side in Run Your Own AI at Home for the Price of a Gaming PC.
Then, in a single conversation, three things happened:
- I told my configuration agent exactly how I wanted the router configured. Not a list of commands. Intent: what the router should do, how it should be set up and what I planned to plug into it.
- After the configuration agent finished, my QA agent verified the configuration against what I’d asked for and checked it for errors.
- Once both agents agreed the router was built the way I wanted, they built a port map showing me where to plug in each of the devices I’d asked for, and delivered it to me.
At the end of that conversation, the router was completely functional as requested. I went from a blank box to a working router and a map of where every cable goes, and I never typed the configuration myself.
I won’t oversell this. It was a home lab, one router, a design I understood and me watching the whole time. But not long ago, this would have sounded like science fiction to most engineers I know.
Why the second agent is the most important part
The part of that workflow I’d point every engineer to isn’t the configuration agent. It’s the QA agent.
A single model working alone will sometimes produce output that looks right and isn’t. It can drop a line or mix up syntax between software versions. That’s not a reason to throw the tool away. It’s a reason to design the workflow the same way we design good change processes for people: whoever builds the change shouldn’t be the only one who checks it.
Splitting the work between a builder and a reviewer, with a human defining the intent up front and accepting the result at the end, turns “trust the AI” into “verify the AI.” It’s peer review, just faster.
The reality check: enterprise isn’t turning agents loose yet
Now for the cold water, because I live in both worlds. In my day job, I lead the network engineering team responsible for roughly 2,000 devices across 220 IT and OT sites running 24/7. There’s a very large gap between a home lab router and a production network, and an even larger one when that network sits next to physical processes.
Enterprise networks, and OT networks especially, are still a ways off from letting agents make changes on their own, and for good reasons:
- Safety. In OT, a bad change isn’t just an outage ticket. It can affect equipment and the physical process it controls.
- Change control. Production changes go through review, approval and scheduled windows for a reason. An agent that pushes config whenever someone asks nicely is a governance problem.
- Determinism. Language models are probabilistic. Network changes need to be repeatable and auditable.
- Blast radius. A mistake on one lab router is a learning moment. The same mistake templated across hundreds of sites is a very bad week.
- Segmentation. Any tool that can reach into a control network becomes part of your attack surface. If an agent platform can talk to OT, it has to live inside the same zones and conduits thinking as everything else. I walked through that model in IT/OT Network Segmentation: The Purdue Model Is the Map, IEC 62443 Zones and Conduits Are the Rules.
AI still can’t be blindly trusted. The responsible path into production looks something like this: read-only first, so agents can collect, summarize and help troubleshoot without changing anything. Then proposed changes that a human reviews and approves. Then tightly scoped, preapproved changes inside a maintenance window, with guardrails, logging and a rollback plan. Trust gets earned in that order, same as with a new engineer.
But the elephant is still in the room
Here’s the thing, though. Everything in that reality check is about how fast and how carefully this happens. None of it is about whether it happens.
Some network engineering tasks are inevitably going to be handed to agent workflows, just like my lab example. Provisioning a branch router from a standard design. Building port maps. A first pass of troubleshooting in the middle of the night. Checking a proposed change against standards before it reaches the change board. These are well defined, high volume, verifiable tasks, which makes them exactly the ones that get automated first.
The train bearing down the tracks
I think of network automation with agent workflows as a train bearing down the tracks. You can already hear it. And right now, network engineers have a window to make a choice.
You can hop on and ride it: learn how these tools work, figure out where they’re useful and where they’re dangerous, and become the person who designs and governs the workflows. Or you can pretend it isn’t there, keep doing every change by hand because that’s how it’s always been done, and get run over when the train arrives anyway.
The engineers who ride it won’t be the fastest typists. They’ll be the ones who describe intent clearly, review agent work critically and know where the guardrails go.
This isn’t doom and gloom
I want to be clear about what I’m not saying. I’m not saying network engineering is going away. It isn’t. Even AI needs engineering, design and infrastructure. Somebody has to decide how the network should be built, why, and what failure looks like. Somebody has to be accountable when it breaks.
What I am saying is that the job is going to be drastically reshaped by AI and agent workflows. Less time typing configuration line by line. More time on standards, source of truth, workflow design, review and the hard problems that don’t fit a template. The keyboard work shrinks. The judgment work grows.
We’ve seen this movie before, just slower
If you were around for the telephony transition, this should feel familiar. Voice moved from analog lines and TDM circuits to digital, and then to VoIP and SIP. SIP itself was standardized in RFC 3261 in June 2002, and the move away from legacy voice played out over many years after that. The voice engineers who learned IP and SIP early built the next chapter of their careers on it. (SIP still keeps all of us humble, as I wrote in SIP One-Way Audio: The Doorbell Rang, So Where Did the Conversation Go?)
Agents are the same kind of shift with one big difference: the window won’t be nearly as long. Digital telephony was a fixed target. Once SIP worked, it mostly stayed what it was. AI is recursive. The tools help build better tools, each generation of models gets more capable, and the workflows we build around them improve right along with them. The further down the road we get, the faster the road moves.
That’s why I think now is the time to ramp up, not after it becomes mandatory.
How to ramp up, starting this week
- Learn Python and APIs. You don’t need to be a developer, just comfortable with scripts, JSON and REST calls.
- Get hands-on with NETCONF and RESTCONF. Model-driven interfaces like NETCONF (RFC 6241) and RESTCONF (RFC 8040), paired with YANG data models, give scripts and agents a structured way to read and change configuration instead of screen scraping the CLI.
- Build a source of truth. An agent is only as good as what it knows. Inventory, IP plans, standards and intended state, kept where a tool can read them, are the foundation.
- Lab it with local models. Spin up a local model, give it a lab device or a virtual router and practice. Watching an agent get something wrong teaches more than a month of reading.
- Practice reviewing agent output. Treat every agent-generated config like a change from a new hire. Read it line by line and know why each line is there.
- Start read-only at work. Where your policies allow it, the safest first step is agents that collect and summarize, not agents that change things.
The train is coming either way. I’d rather be on it, with a hand near the brake, than standing on the tracks arguing that it isn’t real. If you’ve been experimenting with agents in your own lab, I’d love to hear what’s working and what’s made you nervous. Drop a comment below.
No responses yet