The Limits of Deterministic Network Automation & Where AI Reasoning Takes Over

The Ceiling Is Not Where You Think It Is

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.

Where AI Actually 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.

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.”

The Question Has Changed

AI does not replace deterministic automation. It completes it. The 80% that already works stays exactly as it is, governed and repeatable. The 20% that always broke us finally becomes solvable.

Which makes the question for this year a different one. Not whether to put AI into operations, but which parts of the work belong to deterministic execution, which parts belong to reasoning, and how your team evolves so they are running the agents rather than competing with them.

That is a design decision, and it is worth making deliberately.

The Same Argument, From the AutoCon Stage

I closed AutoCon 5 in Munich with a version of this argument, aimed at the question of what NetOps teams do next. Where the deterministic and reasoning layers meet, what it takes to run agents on production infrastructure safely, and why the teams treating this as an organizational shift rather than a tooling purchase are the ones getting somewhere. Watch it below.

Where This Lands in Practice

The 80/20 split isn’t a philosophy for us. It’s the architecture.

FlowAI is the agent harness of the Itential Platform. A FlowAgent runs a reasoning loop: observe infrastructure state, reason through the goal, select a tool, act, observe the result, reason again. What it never does is touch infrastructure. Every action routes through the same deterministic execution engine that already runs every workflow on the platform, with the same RBAC, the same approval gates, the same audit trail. The agent reasons. The workflow executes. That is the 20% and the 80%, wired together.

Four things make that work.

• Tools
  Every workflow, automation, API, and gateway service is registered as a callable tool with structured inputs and defined outputs. An agent’s tool set at build time, and nothing outside that set is discoverable or callable at runtime. An agent built to read cannot be prompted into deleting.
• Skills
  Repeatable task expertise encoded as structured instructions: how your engineers actually handle a vulnerability response, an OS upgrade, a config drift. This is the answer to the runbook problem. Rather than hoping an agent infers what “validate the device state” means, you encode it once and the agent follows your expertise instead of improvising.
• Context
  Agents reason over live infrastructure state and scoped data, not documentation. Real device inventory, real config state, real ticket history. The reasoning is grounded in what is actually true right now.
• Governance
  Three layers, all configured at build time and enforced at runtime: who can build agents, what tools each agent can call, and who can execute them. Agents cannot self-escalate. They never hold credentials either. Those stay on the integration instance or gateway service and get injected only at execution time.

Which model sits behind the agent is your choice, and it matters less than people think. What makes an agent useful on production infrastructure is the tools it can call, the expertise encoded in its skills, and the live context it reasons over. The reasoning layer is the easy part now. The governed execution layer underneath is the missing piece.

See how the Itential FlowAI Agent Harness works →

This article originally appeared in Chris Wade’s column for the Forbes Technology Council: Why Deterministic Automation Was Never Going To Be Enough.