Let’s start by calling it out plainly: we’re in peak hype.

This happens every time a major shift hits the industry. Cloud did it. SD-WAN did it. Now AI is doing it, except this time it’s moving faster and louder. The result is predictable: vendors are racing to slap “AI” on every feature and every slide deck, and enterprises are left asking:

• What are we actually buying?
• What does ROI look like?
• How does this get implemented safely?
• And what does “AI” even mean for a network engineer?

This confusion is normal early in the hype cycle, but here’s the catch: if you let the noise overwhelm you, you’ll miss the real shift happening underneath.

One of the biggest mistakes people make is treating AI like a single skill.

Saying “learn AI” is like saying “learn the medical field.”
Are we talking about surgeons, robotics, radiology, nurses, pharmacists, research scientists?

Same deal here.

There are people building models. People building tools. People building infrastructure. People operationalizing those tools inside enterprise guardrails. And in networking, the biggest opportunity is in implementation, not in flashy demos.

Here’s my updated advice, and it has changed even in the last month.

If you’re in networking, pick one or two fundamentals and go deep:

• TCP/IP
• BGP
• DNS
• Linux
• Automation basics (Python helps a lot)

None of that is going away. And those fundamentals will multiply the value of everything you do with AI.

Instead of trying to “learn AI,” ask:

What do I do every week that is repetitive, manual, or fragile?

Then lab it. Test it. Break it. Fix it. Document it.

Because the engineers who win in the AI era are the ones who can take AI tools and apply them to real workflows without losing rigor.

We talked about something on the show that I think every engineer needs to hear:

Yes, LLMs can help you troubleshoot.
But if you use them for everything, you’ll lose your edge.

I’ll be honest: I’ve had moments where I was tempted to dump configs into an LLM and ask it to find the issue. But sometimes, I force myself to troubleshoot the hard way. Not because I don’t want the time back, but because I want to keep the skill sharp.

AI is a tool.
It’s not a substitute for engineering judgment.

Now let’s talk about MCP (Model Context Protocol), because this is the part most engineers are missing.

MCP is an open standard introduced to make it easier for AI assistants to connect with external systems and tools in a consistent way. The simplest way to think about it is:

A common, standardized protocol that helps different systems exchange information and capabilities so they can work together without everyone reinventing the wheel.

Before MCP, every model and every vendor had a different approach to connecting tools. That meant custom glue code everywhere, inconsistent patterns, and a painful “N x M” integration problem as systems expanded.

MCP starts to reduce that sprawl. It creates a cleaner control plane between AI models and the tools they need to access.

When Dakota asked “how do you let AI into production,” I joked internally because yes, your stomach should churn a little.

Because enterprises cannot adopt AI at scale unless it is:

• secure
• auditable
• policy controlled
• compliant
• governed
• and predictable

This is where the Itential MCP Server comes in: it provides a controlled interface between AI systems and the Itential Platform so that AI-driven intent still executes through governed automation.

This is the real enterprise unlock:

AI can reason, but automation must remain deterministic.

MCP helps bridge that gap.

At Itential, we made a deliberate decision not to chase “chatbot for everything” early on. We waited until the market needed a real enterprise-grade implementation pattern.

That became the Itential MCP Server, and yes, it’s open source.

I don’t think we jump straight to fully autonomous infrastructure management in most real enterprise environments.

The near-term pattern is clear:

1. Human in the loop (manual)
2. Human on the loop (AI assists, humans approve)
3. Human out of the loop (autonomous for limited safe domains)

In the next year or two, you’ll see lots of “human-on-the-loop” systems going live, especially for read-only insights, compliance checks, diagnostics, and guided remediation.

Autonomy comes later, and only in places where the risk profile allows it.

Let me close with the most important takeaway.

The engineers who thrive are not going to be the ones shouting “AI!” the loudest.
They’ll be the ones who can calmly answer these questions:

• Where does the data come from?
• What tool is the AI allowed to call?
• What policy controls the action?
• What approvals exist?
• What audit trail is produced?
• And what happens when it fails?

That is how AI becomes enterprise-grade.

And if you can do that, you won’t be replaced.
You’ll be the person everyone needs.

Pick something like:

• compliance checks
• config backups
• inventory reconciliation
• post-change validation

Then map it to the “AI reasoning + deterministic execution” model.

Document your lab results:

• write a blog post
• record a short walkthrough video
• publish a GitHub repo
• share lessons learned

Hiring managers trust evidence more than adjectives.

Everything runs on it. Your tools, your automation stacks, your containers, your labs. You will not regret it.

If you want the full context behind this conversation, check out the episode with Dakota on The Bearded I.T. Dad Podcast here or in the video below. We go deeper into what’s real vs. hype, why implementation matters more than buzzwords, and how engineers can stay ahead as AI becomes operational.

And if you want the technical deep dive on MCP, including what it is (and what it isn’t), I’d recommend watching my AutoCon session, “MCP Beyond the API Wrapper.” It’s a hands-on breakdown of the architectural tradeoffs and what it takes to move from AI curiosity to real-world integration.