I’ve spent enough years in networking to see new “revolutions” arrive like clockwork. Every few years, there’s a silver bullet that’s going to change everything – SDN, intent-based networking, cloud, and now AI.

The cycle always starts with big promises, loud marketing, and very little clarity about what problem we’re actually trying to solve. AI feels the same right now.

Every vendor deck says “We’ve added AI.” But when you ask what it actually does, the answer is usually a shrug. Everyone wants AI; few can describe what problem it’s solving. That’s how we end up treating it like a buzzword, not a capability.

I talked about this recently on the Network Automagic podcast, where we dug into how AI is colliding with network automation – and why I think we’re at an inflection point. For the first time, there’s a realistic bridge between reasoning systems like LLMs and the deterministic world of infrastructure. That bridge is the Model Context Protocol (MCP).

MCP isn’t another API spec. It’s a way for AI to talk to systems safely, with context and constraints. Think of it as the “how” between an intelligent assistant and your trusted automation stack.

But here’s where a lot of teams are slipping: they’re treating MCP like a fancy wrapper for REST. They autogenerate MCP servers from OpenAPI specs and then hand the keys to a model. That’s not innovation – that’s how you rebuild script sprawl with better branding.

MCP’s power isn’t in connectivity; it’s in control. It defines what an AI can do and what it can’t.

Each of those verbs wraps deterministic automation – the same workflows, playbooks, and guardrails you already trust. The AI doesn’t see the plumbing; it just sees safe, well-defined tools. That’s how you let AI participate without letting it run wild.

MCP’s real strength is giving us a shared, safe vocabulary for automation. An AI doesn’t need to know every command on a router; it just needs to know what verbs it’s allowed to use.

If you want to implement MCP the right way, start by asking: What outcome am I trying to enable?

Then build around that action – not the data model. Define small verbs. Add pre- and post-checks, rollback paths, and observability. Instrument everything so you can trace who did what and why.

When the AI asks to act, let it reason – but make execution deterministic and observable. That’s the balance: machine assistance without losing operational trust.

MCP isn’t about opening every door; it’s about deciding which doors exist in the first place.

Automation has always struggled with definition. Engineers know what toil they want to remove, but not always the outcome they’re building toward. We write a script, fix one ticket, and move on – leaving someone else to rebuild it next quarter.

Now replace the script with an LLM prompt, and you’ve got the same problem at higher speed. The technology changes; the pattern doesn’t. The absence of intent is what turns helpful tools into chaos engines.

That’s why skepticism around AI in networking is healthy. Determinism and trust are our currency. But with MCP, we finally have a model that lets us balance both.

The most valuable AI use cases today live in operations, not configuration.

Drift detection, compliance checks, incident correlation, even reasoning over routing data – these are practical, low-risk areas that make teams faster and smarter. Feeding an OSPF or BGP topology into a model to find anomalies isn’t magic; it’s just better math.

Where AI isn’t ready is change control. The cost of being wrong in networking is still too high. So let AI help you decide what to change – not make the change.

If there’s one constant lesson in automation, it’s this: success doesn’t come from cleverness, it comes from control.

These aren’t glamorous questions, but they’re what keep innovation from becoming an outage report.

AI isn’t going to run the network – not this year, not next. But it can already help us run networks better: faster to understand, quicker to fix, easier to trust.

If we treat AI as a partner, not a replacement and bring the same engineering discipline that’s carried us through every wave before it – it will earn its place in the toolkit.

That’s not hype. That’s progress – the kind that happens one well-defined use case at a time.

If you want to dig deeper into this conversation, check out the full Network Automatic podcast episode or watch it below – we covered everything from AI hype to MCP reality.

I’d love to hear how your team’s thinking about AI in automation. Connect with me on LinkedIn, share what you’re building, or challenge the ideas here.

And if you’re at AutoCon 4 in Austin this week, come say hi and check out my on-stage session Wednesday about this very topic. I’ll be the one talking about guardrails, not magic.