Chris Wade is the Co-Founder & CTO at Itential.

Fifteen years in this industry, and I still see the same failure mode. A team invests seriously in automation. Tools get built. Workflows get shipped. And then, somewhere between year two and three, the automation starts failing on cases the original engineer never anticipated. The team layers exceptions on top of exceptions. The workflow becomes unmaintainable. Nobody wants to touch it.

The best thing about deterministic automation is that it’s deterministic. The worst thing about deterministic automation is also that it’s deterministic. That is not a tooling problem. That is a determinism problem, and it is the reason AI finally has a real job to do in this space.

The Trap We Built For Ourselves

Earlier this year, I sat in on a working session with the architecture team of a large European telecom operator. They have a mature automation practice, real engineering investment and a strong baseline across three controller domains. And they still hit a ceiling.

Their senior architect put it plainly: Every new service request now starts with a debate about whether to extend the existing workflow or fork it, because the workflow has become too dense to safely modify. “Our automation works,” he told me. “Until it doesn’t. And the cases where it doesn’t are growing faster than the cases where it does.”

That is not a mature-team problem. It is a design problem. Deterministic systems do exactly the same thing every time. That is the feature. It is also what prevents them from absorbing variance that was not encoded at build time. The variance is infinite, and no amount of if-statement engineering has ever closed the gap.

The tools were not the problem. Deterministic was the only kind of automation we had. The problem was the assumption that we could code every variance into the pipeline. We cannot.

Where AI Earns Its Keep

When most people hear “AI for infrastructure,” they picture configuration script generators or anomaly detection dashboards. Those are real, and they are the least interesting uses of the technology. The use that matters is reasoning at the points where determinism breaks down.

In every environment I have seen, roughly 80% of any operational workflow follows a known, repeatable path. That work should stay deterministic. The other 20% is where the variance lives. The unexpected device state. The judgment call about whether to proceed or escalate. That variance is what reasoning is for.

One of the more interesting engagements this year was with a regulated network operator that demanded the inverse of what most vendors pitched. They were not asking for autonomy. They wanted 75% of their execution to stay strictly deterministic, with reasoning used only at narrow decision points inside pre-certified workflows. That ratio worked. For the first time, the workflow could pause, weigh an unexpected situation and either choose the right deterministic branch or hand the decision back to a human.

This is not a bolt-on. It’s the layer that has been missing since the beginning. We as an industry spent 15 years trying to encode reasoning into deterministic logic. The effort was heroic. The approach was wrong.

Why You Should Onboard The Agent The Way You Onboard The Engineer

The clearest analogy is onboarding a new engineer. What does a new hire need to be useful? Foundational knowledge. Training on the tools your organization uses. Credentials and access to the systems they will operate. And instructions for the work itself. Design documents, methods of procedure, runbooks.

An AI agent needs the same four things. The foundational knowledge comes from the large language model. The tool training comes from skills files. The system access comes from connectors. And the instructions come from the documentation you already produce, assuming it is good enough to be followed without human improvisation.

I watched a customer engineering team find out how much “assuming” was hiding when they handed an agent one of their own internal runbooks. The agent made it three steps in before stopping on a line that began with “validate the device state before proceeding.” A senior engineer would have known what to do. The agent did not, because the runbook never actually said. That team has since told me the work to harden their documentation was the most valuable side effect of the engagement, regardless of the AI outcomes.

A senior engineer can fill in gaps. An agent cannot. AI changes the cost of deferring that work.

When The Job Stops Being About Syntax

The part nobody wants to say out loud is that this changes the job. For 15 years, the network engineer’s craft has been translating human intent into machine instructions. That craft does not disappear, but it stops being the center of the job. The engineer of the next decade will manage a fleet of agents the way a manager runs a team. They set the intent, define the constraints, review the decisions the agents make and escalate the ones that need a human. Their leverage will come from systems thinking, operational design and judgment. Teams that adapt early will have a real advantage. The ones that wait could spend the next few years catching up.

Why The Question Has Changed

For a long time, the honest answer to why automation has not delivered what we expected was that the tooling was not mature enough. That answer expired a few years ago.

The new honest answer is what that telecom architect put plainly. The automation works, until it doesn’t, and the cases where it doesn’t are growing. Deterministic systems on their own were never going to handle that variance. AI does not replace deterministic automation. It completes it. Eighty percent stays deterministic. The 20% that always broke us finally becomes solvable.

The question infrastructure leaders should be asking this year is not whether to adopt AI in operations. It is which parts of the work belong to deterministic execution, which parts belong to reasoning and how the engineering team needs to evolve so they are running the agents instead of competing with them.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

Share.
Leave A Reply

Exit mobile version