Sign In Get Started

Deterministic Automation Hits a Ceiling, Itential CTO Argues

Stocks● Neutral

Deterministic Automation Hits a Ceiling, Itential CTO Argues

2026-08-10 11:15 UTCBy AlphaScala Research DeskSource reporting: forbes.comEditorial standards3 views

Deterministic Automation Hits a Ceiling, Itential CTO Argues

Chris Wade of Itential argues that deterministic automation fails on unanticipated variance. AI reasoning completes the 80% deterministic path, solving the 20% that always broke workflows.

Continue with

ToneTag triples revenue as soundbox shifts to banking interface

How to start trading stocks as a beginner?

Every new service request at a large European telecom operator now starts with a debate. The architecture team has to decide whether to extend an existing workflow or fork it. The reason, the operator's senior architect told Itential co-founder and CTO Chris Wade, is that the workflow has become too dense to safely modify.

"Our automation works," the architect said. "Until it doesn't. And the cases where it doesn't are growing faster than the cases where it does."

Wade sat in on that working session earlier this year. The operator had a mature automation practice, real engineering investment and a strong baseline across three controller domains. They still hit a ceiling. Wade argues that ceiling is not a tooling problem. It is a design problem rooted in determinism itself.

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, Wade said, and no amount of if-statement engineering has ever closed the gap.

"The tools were not the problem," Wade said. "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."

In every environment Wade has 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: unexpected device states, judgment calls about whether to proceed or escalate. That variance is what reasoning is for.

One of the more interesting engagements this year, Wade said, 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.

Wade calls this the layer that has been missing since the beginning. The industry spent 15 years trying to encode reasoning into deterministic logic. The effort was heroic, he said. The approach was wrong.

His clearest analogy is onboarding a new engineer. A new hire needs foundational knowledge, training on the tools, credentials and system access, 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. The instructions come from the documentation you already produce, assuming it is good enough to be followed without human improvisation.

Wade 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 Wade 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," Wade said. "An agent cannot. AI changes the cost of deferring that work."

The part nobody wants to say out loud, Wade added, 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. 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.

For a long time, the honest answer to why automation has not delivered what the industry expected was that the tooling was not mature enough. That answer expired a few years ago, Wade said. 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 the industry finally becomes solvable.

Wade said 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.