The Messy Middle: Why the AI Hype Cycle Is Rhyming with Cloud & What Infrastructure Teams Should Do About It

I’ve been doing a lot of podcast conversations lately. And somewhere in the middle of recording this one with Cory O’Daniel on the Platform Engineering Podcast, I realized we weren’t really talking about AI anymore. We were talking about the same thing infrastructure people have always talked about: what happens when the infrastructure underneath a good idea has to stay up. That tension doesn’t go away just because the tooling changes.

The AI Hype Cycle Is Rhyming with Cloud

I’ve lived through a few of these moments. The one I keep coming back to is the early cloud era. I remember sitting in a meeting – one of those all-hands where leadership showed up with a slide – and hearing that we were going to migrate everything off our data centers and mainframes and into the cloud. All of it. A thousand apps. Eighteen months. I remember thinking: that’s not how any of this works.

And yet, here we are watching the same thing play out with AI. The timelines are ambitious. The promises are grand. The practitioners in the room are exchanging the same glances they exchanged the last time someone promised a clean transformation. That’s not cynicism. It’s pattern recognition.

And the lesson from cloud isn’t that the technology wasn’t real – it was.

The lesson is that adoption takes longer than the keynote suggests, the edge cases are where you live, and the teams who navigated it best were the ones who stayed grounded while everyone else was flying the plane.

The same is going to be true here.

Two Camps, Neither Quite Right

What I’m watching in the market right now is a split. On one side, you have the people who believe AI is going to write a production-grade company by Friday and publish a YouTube video about it by the weekend. On the other, you have the camp where everything AI touches is slop, always has been, always will be. Neither of those is a useful place to work from.

The real, durable value – the kind that actually changes how AI infrastructure operations teams work – is in the messy middle. It’s not flying cars. It’s the unglamorous stuff. Managing Git workflows. Wrangling inconsistent inputs into a structured format before they hit a deterministic workflow. Documenting your network in a fraction of the time it used to take. Reorganizing your docs so that customers can actually find things.

Importantly, these aren’t the demos anyone puts on a stage. But they’re the things that give time back to engineers who haven’t had enough of it in years.

The MCP Server Architecture Problem Nobody’s Talking About

Here’s where I’ll get specific, because I think this matters and it gets glossed over. When MCP (Model Context Protocol) started gaining momentum, a lot of vendors did what you’d expect: they took their existing API specs, ran them through a machine, and generated a tool for every endpoint. If you have thousands of API endpoints, you now have thousands of tools.

That’s a software engineering mistake. And it’s a particularly painful one once you understand how context windows actually work. Every token in a context window attends to every other token. That’s the attention mechanism. When you double your input size, you quadruple the computational cost. More importantly, you start getting diminishing returns — and eventually negative returns — on model performance. You can give a model too much context. It will slow down, get confused, and produce worse output than it would have with a smaller, more curated set of inputs.

This is why the architecture of the MCP server matters as much as the model you’re connecting it to.

At Itential, we built a stable MCP server core, separated the tools so they could be built and introduced independently, and made them filterable, so you can give the model exactly what it needs for a given task and nothing it doesn’t.

Where Deterministic Execution Still Wins

APIs connect machines. MCPs connect the intelligence to those machines. Those are different levels of abstraction, and conflating them creates real problems.

AI is good at reasoning. It’s good at interpreting context, identifying the right path, adapting to ambiguous inputs. What it is not good at, and should not be trusted to do alone, is executing change on production infrastructure without a deterministic layer underneath it.

The pattern I believe in is this: let the agent reason, let the platform execute. The agent figures out what needs to happen. The platform – with its guardrails, RBAC, audit trails, and governance controls – makes sure what actually happens is predictable and safe.

This connects directly to something I’ve been writing about separately: spec-driven development. The idea is that before any automation is built, and certainly before any agent touches it, you define a validated specification of intent. What systems get touched, in what order, with what parameters, and what has to pass validation before you proceed. That spec becomes the contract between the AI and the execution layer. The agent works from something you approved, not from a prompt it’s improvising against.

In infrastructure, that distinction matters enormously.

This is the boundary that matters in agentic infrastructure operations. Not which model you’re using. Not how big your context window is. Where does the AI’s job end and the deterministic execution begin?

Get that boundary right, and anchor it to a spec, and you have something production teams can actually trust.

On Fundamentals

One more thing, because Cory asked me something near the end of the episode that stuck with me. He asked how I think about younger engineers coming up in this environment — where AI can generate code, documentation, and configuration faster than most people can read it.

My answer hasn’t changed: learn Linux. Learn TCP/IP. Understand how BGP works. Pick a language and get good at it. I still use Linux more now, in the AI era, than I ever did before.

The fundamentals don’t become less relevant because there’s a smarter tool on top of them. They become more relevant – because when things break, and they will break, the people who understand what’s underneath are the ones who can fix it.

AI is a force multiplier. It amplifies what you bring to it. If what you bring is solid, the output is excellent. If what you bring is a vague prompt and no mental model of the system underneath, you get confident-sounding output that falls apart the moment it touches production. That won’t age well.

The Part That Doesn’t Make the Keynote

What I appreciated about this conversation with Cory was that we spent most of it in the part that doesn’t make the keynote. The part where someone’s still version-controlling JSON config files for their MCP clients because nothing exists yet to manage it cleanly. The part where a docs reorganization that AI helped you do in an afternoon gets more customer love than the feature release you spent a quarter on.

That’s where the actual work is. That’s where the practitioners live. The organizations that figure out the messy middle — that find the places where AI creates real leverage without introducing chaos into systems that have to stay up — those are the ones who are going to look back on this moment and realize they got it right while everyone else was still arguing about whether it was flying cars or slop.

Listen to the full episode on the Platform Engineering Podcast, or watch it on-demand below. And if you want to go deeper on how Itential approaches agentic infrastructure operations, start here.