Fifteen Years of Network Automation, and We’re Still Asking Permission
Ask a room of network architects whether automation works and you’ll get a confident yes. Ask how much of their production network is actually automated and the room goes quiet.
The 2025 State of Network Automation Survey from the Network Automation Forum, 681 respondents across 58 countries and 34 industries, found that only 1.52 percent of organizations have deployed fully autonomous remediation, with another 4.56 percent running semi-autonomous workflows. Roughly 94 percent of network teams have not crossed the line into autonomous execution.
And remember who answers a network automation survey. These are the most automation-forward shops in the industry.
Now the part that should reframe every roadmap conversation you are having. When asked what is holding them back, only 10 percent cited technical challenges. Forty-four percent pointed at people: skills gaps at 27 percent, organizational resistance at 20 percent, cultural friction at 14 percent.
Chris Grundemann’s summary line is the one worth taping to the wall. “Culture eats Automation for Breakfast.”
So the honest answer to why network automation has not achieved widespread adoption after fifteen years is this. We solved the engineering problem and never solved the operating-model problem. The tooling is mature. The trust, the org design, the measurement discipline, and the abstraction layer are not.
The bottleneck moved and most roadmaps did not notice
Fifteen years ago the blockers were real. No APIs, no structured data, CLI-only devices, vendors treating programmability as a differentiator rather than a baseline. That era is over. NETCONF, gNMI and REST are table stakes. Streaming telemetry is standard. The open-source ecosystem is deep.
Yet Gartner projects that by the end of 2028, over 80 percent of comprehensive network automation initiatives will have been shelved due to persistent skills scarcity and inadequate funding. Not shelved because the routers would not cooperate. Shelved because nobody could staff, prove, or defend the program.
If your automation strategy is a tool selection exercise, you are optimizing the 10 percent.
Trust is an architectural requirement, not a maturity outcome
Operators do not withhold trust irrationally. They withhold it because most automation systems ask them to accept a black box that can take down revenue-bearing infrastructure at machine speed.
Trust has to be engineered in as a first-class feature set. Preview and dry run, rendering the exact intended change per device before anything touches the wire. Diff against actual state, not against the last known template. Blast-radius limits, canary then wave, with automatic halt thresholds. Approval gates that map to real accountability, with the ability to delegate them away as confidence grows. An immutable audit trail covering who, what, when, why, from which intent version, with which result. And rollback that operators can read, because a rollback plan nobody understands is not a rollback plan.
Any automation system that can write to production and lacks all six should be considered incomplete. I would start reviewing vendor platforms against exactly that list.
Can agentic AI solve the adoption speed problem?
This is the question I now get in every briefing, and the honest answer is yes and no, in specific and predictable places.
Where the answer is yes.
The NAF survey’s biggest gap between what is automated and what should be automated was troubleshooting, at plus 223 responses, followed by capacity planning and traffic engineering. Those are analysis problems, not execution problems. Agentic systems are genuinely strong there, and because the work is read-only, it is the lowest-risk ground on which to build organizational trust.
Second, the skills gap is real and specific. In the same survey, 74 percent rate themselves highly skilled in networking and only 44 percent highly skilled in automation. Ninety-two percent said automation is built by network engineers with automation skills rather than by software developers. Agents compress that particular gap, not by replacing the engineer, but by removing the software-fluency tax on domain experts. Scaffolding an executor, writing the tests, translating a service definition into schema, drafting validation criteria before the automation exists. That is real acceleration for the exact population doing the work.
Third, the best snowball use case, inventory and discovery reconciliation, is agent-shaped almost perfectly. Multi-step, tool-calling, reconciling messy and contradictory sources, and entirely read-only.
Fourth, intent extraction. The most commonly missing NAF block is Intent as a structured, API-addressable model. Today it exists as tribal knowledge, spreadsheets and template variables. Converting that into structured data is fundamentally a language problem, which is what these systems are best at.
Where the answer is no.
Forty-four percent of the blocker is people. An agent cannot name a platform owner, fund headcount, resolve a turf dispute between network and platform teams, or create measurement discipline where none exists. Half of organizations are not measuring automation success at all. An agent does not fix that. It produces more unmeasured activity, faster.
More sharply: agentic AI arrives carrying a trust deficit of its own, and stacks it on top of the one you already have. Ninety-four percent have not crossed into autonomous execution. Broadcom’s 2026 State of Network Operations study found 71 percent do not fully trust AI for network decisions, with 95 percent saying they lack visibility into key network segments. Gartner’s related findings are harder: only 19 percent report high or complete trust in vendor hallucination protection, 74 percent see AI agents as a new attack vector, and only 13 percent strongly agree they have adequate governance in place.
You are not adding a trusted accelerant to an untrusted process. You are adding a second untrusted layer to the first one.
And then the data problem, which is the one that actually bites. An agent reasoning over a stale, incomplete source of truth is worse than a script, not better. Deterministic automation fails visibly. An agent fails plausibly, at machine speed, across multiple steps, with a confident explanation attached. Gartner’s prediction that 40 percent of enterprises will demote or decommission autonomous agents by 2027 after governance failures is the empirical form of this argument.
So the summary is uncomfortable but clean. Agentic AI meaningfully accelerates analysis, authoring and reconciliation. It does nothing for trust, org design, funding or measurement. Which means it compresses the engineering work that was already only 10 percent of the problem.
And yet you cannot reach autonomy without it
Here is the part that gets lost in the backlash, and I think it matters more than the caution.
Deterministic automation cannot reach the top of the maturity curve. Not “has not yet.” Structurally cannot.
TM Forum’s Autonomous Network Levels model runs L0 through L5. L0 is manual. L1 is assisted, automating repeated actions based on rules. L2 is partial autonomy with closed-loop control at the network element. L3 is conditional autonomy, closing the loop across awareness, analysis, decision and execution. L4 adds external environment awareness, cross-domain closed loop and self-learning. L5 is full autonomy.
Rules, templates and state machines are a closed world. They handle the cases you enumerated in advance, which is exactly why they are trustworthy and exactly why they top out. Somewhere around L2 and L3, the curve bends. Getting past it requires acting correctly in situations nobody modeled: novel failure combinations, cross-domain interactions, ambiguous or conflicting intent, conditions that appear once a year in one region.
The combinatorics of failure modes across a large estate are not enumerable in advance. That is not a tooling shortfall. It is a property of the problem.
Reasoning over unenumerated state, planning multi-step remediation, and invoking tools to close the loop is precisely the capability agentic systems add. Which makes the position clear on both sides. Agentic AI is not the shortcut past the foundation, and it is not optional at the summit.
It is also unusable until the foundation exists. An agent with executor access, no dry run, no blast-radius cap, no readable rollback and no trustworthy source of truth is the fastest outage generator our industry has ever built.
So the six trust controls do not become less important when agents arrive. They become the precondition. And I would add two more for agentic systems specifically. Every agent action must be attributable to an intent version and an explicit policy scope. And agent authority must be granted per use case against measured accuracy on a real sample, never per platform and never by vendor assertion.
Which brings it back to the thing half of organizations are skipping. Measurement is not overhead. It is the only mechanism that converts an agent from a liability into a promotion candidate.
The sequence that actually works
Read before write. Detect before remediate. Recommend before act. Then delegate, against evidence.
Start with automated inventory and discovery reconciliation, because it carries zero write risk and immediately exposes how wrong your CMDB is, which is the argument for everything that follows. Then continuous configuration compliance validation, read-only, detecting drift without remediating it. Then standardize one high-volume change type, the boring one everyone does weekly. Then automated triage on your top three repetitive incidents, with AI advising and humans executing.
Every stage produces a number. Every number funds the next stage. Trust is granted against evidence rather than requested on faith.
Put agents in the analysis layer first. Not because they are incapable of more, but because that is where they earn the audit record that justifies more.
What we see in the numbers at ACG
This sequencing argument is not theoretical for us. When we build the business case for an automation program, four measures carry almost all of the economic weight, and they are the same four I would put on a Q1 scoreboard.
Provisioning cycle time. Across our engagements we typically see [ACG FIGURE: median reduction, for example provisioning intervals falling from X days to Y hours] once a single service abstraction is defined and instrumented.
Change failure rate. This is the number that funds everything else, because it converts automation from a productivity story into a risk story that a CFO understands. We commonly measure [ACG FIGURE: typical before and after on standardized change types].
MTTR on the top incident classes. The triage stage is where this moves, and it moves before any autonomous remediation exists. We see [ACG FIGURE: typical percentage reduction from pre-diagnosed tickets alone].
Engineer hours reclaimed, and specifically what they were redeployed to. Hours saved that go unaccounted for do not survive the next budget cycle. [ACG FIGURE: typical hours reclaimed per engineer per month, and where they went.]
The pattern we see most consistently is this. [ACG OBSERVATION: your one-sentence cross-engagement finding, for example that organizations publishing a baseline before starting were far more likely to still have a funded program eighteen months later.]
That last point is where agentic AI and measurement discipline meet. The teams getting real value from agents today are almost always the teams that already had these baselines, because a baseline is what lets you tell the difference between an agent that is working and an agent that is merely busy. Without it, you cannot promote an agent from advisory to approval on evidence, which means you will either never promote it or promote it on faith. Both of those are failure modes, and Gartner’s 40 percent demotion prediction is what the second one looks like at scale.
The question I would actually like answered
We spent fifteen years believing this was an engineering problem, and the data now says roughly 90 percent of it is not. Agentic AI is about to make the engineering part faster still, which means the gap between teams that solved the operating-model problem and teams that did not is going to widen, not close.
So: if people, culture and measurement are the real constraints, what would your automation roadmap look like if you rebuilt it as an organizational change program with a technology component, instead of a technology program with a change-management appendix?
That is the conversation. I would genuinely like to hear where you land.
Sources: 2025 State of Network Automation Survey, Network Automation Forum, presented at NANOG 95. NAF Framework reference documentation. DevOps.com, “NetDevOps Isn’t Stalled, It’s Stuck on the Wrong Problem.” Broadcom, The State of Network Operations 2026. Gluware analysis of Gartner and NAF data. INE skills-crisis analysis. TM Forum Autonomous Network Levels model. Analysis is ACG Research
.
Originally published on Ray Mota's Substack. Subscribe to get new analysis by email.
