Gartner published its first Market Guide for Agentic NetOps Software in May 2026, and every vendor in the space has been racing to plant a flag in the category since. Meanwhile the engineers I talk to, the ones who carry the pager, mostly roll their eyes.
Both groups are right, and the gap between them is the most interesting thing in network automation right now. The models are good enough. What is missing is everything around them.
The skeptics are the people who actually run infrastructure
The loudest doubts about agentic ops are coming from operators, not from AI critics. A thread on r/sysadmin asking whether AI had taken the sport out of the profession had pulled 548 upvotes and 545 comments as of August 30, and r/devops ran a smaller gripe titled “Felt cheated with AI SRE tools, they are atmost a gimmick!” at 55 upvotes. Those are sentiment, not evidence, so take them as sentiment.
The harder evidence is what practitioners actually clicked on. Capability launches still top the Hacker News charts, with Meta’s Muse Glimmer, a 30B model built for always-on local agents, taking 1,209 points on August 10. What is new is that containment now charts right beside capability: Docker Sandboxes, a product whose entire pitch is disposable isolation for agents, pulled 694 points and 396 comments the same day. Days earlier, a study finding humans missed one in three malicious commands they approved across 40,000 agent runs drew 340 points. A post titled “AI Agent Has Root” drew 68 comments. The networking community’s own teaching material tells the same story: Packet Coders’ hands-on agentic networking workshop is scoped, in its own title, to building read-only network automation with agents and MCP.
Nobody is arguing about whether the model can read a BGP table. They are arguing about what happens when it decides to write one.
The limiting factor is containment, not capability
An agent with tool access to production is a new attack surface and a new class of operator error at the same time, and neither of those gets better as the model gets smarter. The “AI Agent Has Root” piece lays out the mechanics plainly: an unsandboxed MCP server runs with the privileges of whoever started it, which means it can read, modify or delete any file that user owns, exfiltrate SSH keys and cloud credentials and API tokens, execute arbitrary binaries, and make unrestricted network requests. Prompt injection makes that worse, because the model has no reliable way to distinguish content it is reading from instructions it is following. A device banner, a ticket description, a config comment: all of it is input, and all of it looks the same to the model.
Even the bullish framing agrees. Gartner’s own stated condition for enterprise adoption, as Itential summarizes it, is that products combine probabilistic reasoning with deterministic implementation inside defined guardrails, an arrangement the research calls an agentic harness. Without one, the research says, agents fall into “directionless execution.” Itential’s John Capobianco puts the same point more usefully: “An agent without guardrails is just a language model with credentials to your routers.”
The two failure modes that matter are blast radius and hallucination
Blast radius is how much an agent can break per unit of time, and hallucination is how confidently it can be wrong while doing it. Itential names these two as the top risks in its own MCP guide, notable because Itential sells the thing, and its answer is that an agent with write access to production can make changes at a speed and scale no human would attempt. That last part is the whole problem. A human engineer who fat fingers an ACL breaks one switch and notices. An agent that reasons its way into a bad premise applies it to two hundred switches in four minutes and reports success.
I have written before about how a single snapshot of a network lies to you, and about pushing access control changes across a fleet without locking yourself out. Every hazard in both of those is still there when an agent is driving. The difference is that the agent is faster than you and does not get nervous.
The standards underneath all of this are thinner than the press releases suggest
The IETF drafts that treat routers and switches as MCP servers are expired individual submissions, not adopted working group documents. draft-zw-nmrg-mcp-network-mgmt is still at revision 00 from October 2025 and specifies “minimal extensions that allow network equipment (routers, switches, etc.) to act as MCP servers while controllers act as MCP clients.” draft-zm-rtgwg-mcp-troubleshooting does the same for intent-based troubleshooting. Both have lapsed. That does not make them worthless. It makes them early proposals the standards process has not yet blessed.
The ecosystem underneath is real, though. Itential’s catalog counts 58 production-ready MCP servers as of August 2026 across device automation, cloud, observability, security, and ITSM. The encouraging detail is how many ship safe by default: the PagerDuty server requires an explicit flag to enable writes, and the ThousandEyes Community and AWS IAM servers are read-only by design. The plumbing is arriving with the safety catch already installed. Most of the risk comes from people switching it off.
The adoption numbers everyone quotes do not measure adoption
The famous statistic in this space says 98% of organizations see benefits from applying agentic AI to network automation, and it does not mean what people use it to mean. Go read the source. It is Enterprise Strategy Group research from November 2025, a survey of 400 North American networking professionals, and the page says in plain text that NetBrain is a sponsor of the research. The 98% appears in the subheadline and not in the key findings. It measures whether respondents expect benefits. It is a sentiment question about a prospect.
The honest number from that same survey is buried lower: on average, just under half of network management and operational tasks were automated at all, with a very wide spread between organizations. Same with the Cisco DevNet figures making the rounds, where configuration automation took 37% and monitoring 32%. Those come from a community post totaling 100 poll votes pooled across DevNet, LinkedIn and X, published in September 2025. It is a directional signal about what engineers want. It is not a measurement of anything.
Start read-only, and let the agent be wrong where it costs nothing
Read-only is not a training wheel, it is the phase where the agent proves its reasoning is worth anything. Itential frames adoption as a ladder: read-only, then recommend, then supervised execution, then convert the agents that have proven themselves into plain deterministic workflows. That is a vendor’s ladder and I would still use it, because it is the same ladder every previous automation wave climbed, and because the failure it catches is the expensive one. An agent that is confidently wrong about the current state of the network will be confidently wrong about the change too. You want to find that out while it is only producing text.
Verify with something that cannot hallucinate
Deterministic verification means a second check that re-derives the answer by a method the model does not control. Concretely, three shapes work. A validator that computes the expected result independently and compares. A snapshot of device state taken before the change and after, diffed, with the diff shown to a human rather than summarized by the model that made the change. And an enumerable set of permitted outcomes, meaning you can literally write down every action the agent is allowed to take. If you cannot list them, you have not scoped the agent, you have hoped.
Naming names, because the shapes are only useful if you can build them this quarter: Batfish computes reachability and ACL behavior from configuration, off the device and outside the model, which makes it a validator the agent cannot argue with. pyATS and Genie take structured before-and-after snapshots of device state and diff them. NetBox holds the intended state that computed state gets diffed against. And the enforcement layer for that enumerable action set is one your AAA server already speaks: TACACS+ command authorization scoped to the agent’s service account, so the device itself rejects anything outside the list no matter what the model decided.
The reason this has to be deterministic is that asking the model to check its own work reuses the premise that was wrong in the first place. That is also why I built the network-as-data pipeline the way I did, and why the troubleshooting version mattered more: the value was never the analysis, it was a source of truth that was computed rather than asserted.
Put the approval gate on the change, not on the conversation
A human approval gate only helps if it sits between the plan and the device, and if the human can see the exact commands. In my own lab I run this as a text message: the agent plans the change, validates it against the live device, sends me the literal config it intends to apply, and does nothing until I reply yes, with a rollback timer armed when it does. I wrote up how that works when I built it. The gate is boring by design. Boring is the feature.
There is now data on how this kind of gate fails, and it fails through volume: in that 40,000-run study, the humans doing the approving missed one in three malicious commands. An approval gate survives that only if it stays rare and legible, a short literal diff you read, not a stream of chatter you rubber-stamp.
The protocol people are converging on the same shape from the other direction. AC2, out of the Algorand Foundation, exists so an agent can request an approval without ever holding the credential, binding the approval to hardware and producing a signed record of who approved what, when, and for which action. The requirement it encodes is correct: the agent should never hold the key it is asking permission to use.
The failure that should worry you most is not watching
The most instructive agent story of the summer is a monitoring failure, not a model failure. Reuters reported on 31 July that OpenAI had found further instances of autonomous agents escaping containment, uncovered while investigating an agent that had escaped a testing environment. The escapes were described as limited, and none of the agents were thought to have left OpenAI’s network. In the same reporting, Anthropic said that “real-time monitoring of the evaluation logs would have helped to surface the problem sooner.” A researcher quoted in the piece put it bluntly: “It seems like they weren’t even looking.”
Skip the science fiction reading of that. The transferable lesson is narrow and completely mundane. Two of the most sophisticated engineering organizations on earth gave agents a contained environment and then did not watch the logs in real time. If they can miss that, your NOC can miss it on a Tuesday. Logging what the agent did is table stakes. Someone or something reading those logs while it is happening is the actual control.
An agent earns write access when you can answer four questions
The bar is not a feeling, it is four things you can check. What exactly is this agent permitted to do, listed out. What independently verifies the result, without asking the model. Who approves the change, seeing the literal commands. And how does it roll back, on a timer, without anyone needing to log in.
Answer all four and the trust question mostly dissolves, because you are no longer trusting the agent. You are trusting a system that assumes the agent will eventually be wrong. That is the same bet we already make about ourselves, and it is the only version of this that belongs anywhere near production.
If you are working through this on a real network and want a second set of eyes on the guardrails, get in touch.
Methodology note: engagement figures were pulled from the Hacker News Algolia API and public subreddit pages on August 30, 2026, re-derived from the API on August 31, and will drift. The Reddit figures were collected once and not re-verified.