Every NetOps team that has run an automation pilot tells the same story with the details shuffled. The agent works. It reads the topology, drafts the ACL change, catches the prefix overlap that a human reviewer would have caught on the third pass at 11pm. And then it sits in read-only mode for eleven months, because nobody can answer the one question the change advisory board actually asks: what happens when it is wrong?
The gap is not capability. Vendors keep shipping better reasoning, and the pilots keep ending in the same place, because the thing standing between a working agent and a trusted agent is an artifact nobody has bothered to build — a reviewable, reversible, attributable change proposal. That is an engineering problem, and it is solvable this quarter.
The agent is already in the loop — you just haven't instrumented it
Do the arithmetic on your own ticket queue before you argue about autonomy. Sort last quarter's change requests by hand-edit similarity and most teams managing a few thousand network devices find that 60–70% of changes collapse into fewer than a dozen templates: VLAN additions, ACL object-group edits, route-policy additions, port descriptions, BGP neighbor onboarding. A shop pushing 300 changes a month is therefore hand-executing roughly 200 near-identical operations, each with its own review cycle, each with the same three failure modes.
That is not a reasoning problem. It is a packaging problem. The agent can already produce the change; what it cannot do is produce the evidence bundle that makes a human willing to sign it without re-deriving everything from scratch. When reviewers have to reconstruct intent, they will reject the automation regardless of how good it is — because re-deriving is the job they're protecting.
Autonomy is a dial with five stops, not a switch
The maturity conversation usually gets framed as a binary: human-approved or fully autonomous. In practice there are five distinct stops, and they're worth naming because teams skip the one that matters.
- Observe — the agent reads state and reports, touching nothing.
- Recommend — it proposes an action in a chat channel or ticket comment.
- Prepare — it drafts the exact config diff, computes the blast radius, and generates a rollback it has actually tested in a lab or a canary device.
- Execute with approval — a human clicks approve on the prepared bundle.
- Execute with notification — the action happens and the record is written afterward.
Most stuck teams are parked at stop two and trying to jump to stop four. The stop they skipped, prepare, is where trust is manufactured, because a prepared change with a generated rollback is something a reviewer can approve in ninety seconds instead of ninety minutes. Confidence without a rollback plan is just a stranger's opinion.
Blast radius math beats confidence scores
Consider two proposals for the same change. The first says: 97% confident this is safe. The second says: touches 12 of 4,000 devices, three of which are top-of-rack for the payment VLAN; the diff is four lines; a configuration snapshot was taken 40 seconds ago; rollback is a single configure replace that has passed in staging; estimated customer impact if wrong is a 90-second BGP reconvergence on one path.
The first proposal costs a change board forty minutes of independent verification. The second costs them ninety seconds. Multiply that difference across 200 repetitive changes a month and you have found the entire ROI case for automation — not in the execution, in the review.
The change board never asks how confident the model is. It asks what breaks if this is wrong, and how fast we can put it back.
That reframing has a practical consequence: your agent's output schema should have fields for scope, diff, rollback, and precedent, and a free-text confidence field should be the least prominent thing in it.
Four gates, and none of them are model quality
When teams describe why they finally let an agent push to production, the reasons are consistently operational rather than epistemic:
- Reversibility. Every action class has a rollback that has been executed at least once outside production. Documented rollbacks are not rollbacks; they're intentions.
- Attribution. Each action traces to a ticket, a human approver, and a model version. When something goes sideways at 3am, you need to know which of the three changed.
- Precedent. The first twenty actions in a new class get human eyes; the next two hundred don't. Trust is granted per class, not per agent.
- A hard ceiling. A cap on devices, prefixes, or sessions touched by any single action — enforced outside the model, in the execution layer, so that a bad generation cannot argue its way past it.
Notice that three of those four are properties of the surrounding system, not the agent.
The unglamorous prerequisite: making the network legible
Agents fail in NetOps for a reason that has nothing to do with reasoning: the source of truth is stale by hours, not seconds. An agent reading a nightly-synced inventory will confidently propose a change to a device decommissioned last Tuesday, or target a VLAN that was renamed in the fabric but not in the CMDB. The reviewer sees the error, loses confidence in every subsequent proposal, and the pilot quietly dies.
The fix is boring and it is mandatory. Read live state from the device before generating a diff, take a pre-change snapshot every time, and treat inventory as a hint rather than a fact. If your agent cannot distinguish "the CMDB says this port is unused" from "I queried the port and it is down with no MACs," it is not ready for stop three.
Where this is heading: review becomes a generated artifact
The teams getting this right are not reviewing changes anymore. They are reviewing the policy that authorized a class of changes, and then reading a stream of pre-validated envelopes that already contain diff, scope, rollback, and precedent. The human attention moves from the individual change to the boundary conditions — the blast-radius ceiling, the exclusion list, the two device roles that always get a second pair of eyes.
Expect the change advisory board to shrink from a weekly meeting into a queryable log, and expect auditors to stop sampling tickets and start sampling policies. The competitive advantage will not go to the team with the smartest agent. It will go to the team whose agents produce artifacts good enough that approving them is faster than doing the work by hand — because that is the only condition under which anyone ever lets go of the keyboard.