The Intelligence Layer We’ve Been Missing in Network Automation

I gave the closing keynote at AutoCon 5 in Munich a few weeks ago. If you’ve been to an AutoCon, you know what that room is: several hundred people who run networks for a living, who have watched every wave of tooling come through, and who had already spent the week making it clear how they feel about AI hype. Earlier sessions drew actual jeers when the promises got ahead of the evidence.

So I set one rule for myself: make the case for agentic technology with no hype. This community has earned that. The full talk is now available on-demand, and I’d encourage you to watch it, because the audience questions at the end are some of the best I’ve gotten. But I want to walk through the argument here, because it’s a conversation I keep having, and I don’t think it’s the one most vendors are having with you.

Why a Decade of Automation Hit a Ceiling

We should start by being honest about where we are. This industry has put ten years into intent-based frameworks, sources of truth, and infrastructure as code, and we made real progress. We got our hands out of the network. We learned software practices. But most of us still can’t automate more than a fraction of our infrastructure, and I think there’s a specific reason why.

We used to have design documents and methods of procedure. When we moved to infrastructure as code, we took those documents and encoded them into our pipelines. That bought us idempotency and scale, but it welded two things together that shouldn’t be welded: our designs, which are portable, and our implementation details, which are not. Take your best pipeline to a new job and watch how little of it survives the move.

It also buried us in exception logic. Every pipeline starts as a clean straight line: pre-check, get data, generate config, push, post-check, notify. Then production happens. Devices are offline. Data is wrong. An API answers in a way you didn’t plan for. You code every one of those conditions by hand, and the straight line becomes a thicket.

The best thing about determinism is that it’s deterministic.

The worst thing about determinism is that it’s deterministic.

That technical debt is the ceiling, and it’s why the answer to “how many pipelines can your team support” is always a smaller number than anyone wants.

Where the LLMs Are Actually Good

In the talk I borrowed the smiling curve from the PC industry to describe where LLMs perform. They’re strong at the two ends. Ask one about general concepts, what a software upgrade involves, what a port turnup looks like, protocol theory, and you’ll get a good answer. Ask about the very specific, RFCs and detailed design documents, and you’ll get a good answer there too.

The middle is where the pain lives: vendor syntax, OS-version-specific behavior, multi-vendor interactions. The models are weak there for a boring reason. That knowledge sits behind paywalls. The LLMs never read your vendor’s TAC tickets and never scanned their code base. So when you have a poor experience with AI, you’re probably asking it to do something it was poorly trained to do. That’s not a reason to walk away. It’s a placement problem, and placement problems have solutions: keep the LLM at the ends of the curve where it’s strong, and keep determinism in the middle where it isn’t.

What’s Actually Inside an Agent

The word “agent” carries a lot of baggage, so in the talk I stripped it back. Start with an LLM and a prompt. That’s the chat experience we’ve all had, useful but unaware of your environment. Add tools, through MCP or APIs, and now it can act: reason about a goal, take an action, look at the result, and go again until it reaches an outcome. That loop is a ReAct agent. Then add the two layers that make it yours: skills, which teach it how work should be done, and a knowledge base, which sets the boundaries it operates inside – your network use policy, your AI policy, your maintenance windows. Context is everything here. The quality of the outcome tracks the effort you put into the context far more than the model you picked.

[Insert Image – slide 19]

The way I think about it is hiring. When I bring a new engineer into a NOC, they arrive with an education – that’s the LLM. Then I give them our processes, I train them on how we do things, and I hand them access to the tools they need. That’s the prompt, the skills, and the tool scope. And critically, I don’t trust the new hire with production on day one, and nobody thinks that’s an insult. Governance isn’t a new requirement AI invented, either. We already cared about guardrails, secrets, and access when the automation was Python and Ansible; agents just raise the stakes on a conversation we were already having. If you have an AI governance team, they’re not there to tell you no. They have a dual mandate: move the organization forward with agents and keep it safe doing it. Engage them like a partner and you’ll get further, faster.

[Insert Image – slide 24]

Two Kinds of Agents, Two Different Decisions

The heart of the talk is a distinction I think this industry needs to internalize: build agents and operate agents are separate concepts, and conflating them is stalling a lot of adoption conversations.

Build agents are the coding agents software teams already use, Claude Code, Codex, Cursor, loaded with skills so they take on different roles: collecting requirements, designing the solution, generating the code. The discipline is spec-driven development. You write down what you want, the way we used to write design documents, and the agent produces the plan and the implementation while you review each step. Here’s the part that matters: everything a build agent produces can be exclusively deterministic. If your organization isn’t ready for an agent making changes in your network, you can still adopt this side fully. The output is code and workflows that run exactly like the automation you run today. No agent ever touches production.

Operate agents are the other decision. These do work in your environment: troubleshooting connectivity, checking device health, working a ticket queue. They deserve the governance conversation, and in the talk I walk through what makes them trustworthy: the tools you scope, the skills you load, and the knowledge base that carries your actual policies. My shorthand is the 2 a.m. outage call. When I get paged, I spend the first twenty minutes building context: what changed, what’s it connected to, what have you tried. An agent built the right way joins that bridge with more context than I have at 2 a.m. That’s not a threat. That’s the intelligence layer we’ve been missing.

[Insert Image – slide 41]

The Oldest Idea in Engineering is Back Within Reach

The part of this I find most encouraging has nothing to do with AI at all. Early in my career, the NOC I worked in ran on a method and procedure book. An alarm fired, you flipped to the page, and you followed a procedure that someone had thought hard about. Somewhere along the way to infrastructure as code, those documents disappeared into our pipelines, and the design thinking went with them. If build agents make implementation cheap, then the durable asset becomes the design again: the spec, the MOP, the architecture decisions. That’s what we get back. Our best people spend their time on how the infrastructure should behave, and the code that expresses it gets generated, reviewed, and regenerated as things change. That’s not a new idea. It’s the oldest idea in engineering, finally back within reach.

The Same Trust Curve, Ten Years Later

I asked the room how many people are using AI or agentic concepts today, and roughly half the hands went up. Then the Q&A wasn’t “should we do this.” It was how we built trust in spec-driven development inside our own engineering team, whether a context window can hold twenty years of tribal knowledge, and how to budget tokens when agents run at network scale. Those are practitioner questions. That’s a community past the experimentation phase.

I had déjà vu standing up there, because we had this exact conversation about automation a decade ago. Human in the loop, diff sets, approvals on every push, and trust extended one bounded use case at a time. We know how that cycle ends. The difference this time is that we’ve run it once before, so we can move through it deliberately instead of accidentally.

Watch the Full Talk

There’s more in the video than I can do justice to here: the anatomy of a ReAct agent, a real port turn up spec and the plan an agent generates from it, how agents fit the NAF framework, and the full audience Q&A. If your team is anywhere between curious and stuck on agents, it’s 40 minutes that will give you language for the conversation.

Watch it on-demand below. And agree, disagree, or have questions, let me know on LinkedIn.