AgenticOps without illusions: what a network needs before agents work in it

There are two ways to talk about AI in network operations. One describes a future in which networks heal themselves. The other asks what an agent does with a specific ticket on a Tuesday afternoon, which data it needs, and who is liable when it shuts down a port. This piece takes the second.

What was actually announced in 2026

Cisco Live 2026 was explicitly centred on AI-native networking — not as an added feature but as an operating model. Three building blocks matter in practice.

Cisco Cloud Control is the announced shared environment in which human operators and agents are meant to manage, monitor and defend infrastructure. Cisco presented it at Cisco Live US on 2 June 2026 and states that it entered controlled availability in the United States the same day, with global availability to follow. AI Canvas is the shared workspace on top of it: people and agents work from the same live telemetry, and dashboards are created during an investigation rather than before it. Underneath sit purpose-built models — including a Deep Network Model that Cisco describes as trained specifically for networking tasks and more precise than general-purpose models.

In parallel the AI Network Assistant is available directly inside Catalyst Center, and the platform runs two branches in 2026 (3.1.x and 3.2.x) with several releases each. Anyone evaluating features should therefore check their own version against the current release notes: the branches differ noticeably.

The real break: deterministic versus probabilistic

Classic network automation is deterministic. A playbook, a template, a script do the same thing for the same input every time. That is precisely why automation can be approved at all: you review the procedure thoroughly once and trust it afterwards.

An agent works differently. It receives a goal, chooses steps, interprets results and decides when it is done. From the same starting point it may take two different and equally defensible paths. That is the strength — it copes with situations nobody wrote a playbook for — and at the same time the reason the approval question has to be asked anew.

The useful split is therefore not either-or. It divides by reversibility:

The four prerequisites

Every announced capability assumes the same things, and none of them is new. Organisations that have these four benefit immediately. Organisations that do not are buying an interface.

1. 01

   Source of truth

   One place that authoritatively states what exists and how it should look. As long as site lists live in three spreadsheets, an agent has three truths and no basis for a recommendation.

2. 02

   Telemetry that says something

   Not more data but connected data: state, event and change have to be relatable in time. Otherwise every model correlates coincidences.

3. 03

   A single change path

   If changes happen by console, by controller or by script at will, there is no point at which an agent can be reviewed, bounded and logged. The route through repository and pipeline is the prerequisite, not the finishing touch.

4. 04

   Permissions and audit trail

   An agent needs its own account with a narrow scope, not the shared automation credential. And every action needs a trail that stays readable later without the agent's help.

Those four are exactly what we build under network automation and around Catalyst Center, independently of whether a human or an agent eventually triggers the change. That is not a coincidence: it is why the groundwork holds even when a product promise later looks different from the announcement.

Why the interface matters more than the model

The most consequential technical development is quieter than the model announcements: the standardisation of how a language model reaches tools and data at all. The Model Context Protocol was handed to the Agentic AI Foundation under the Linux Foundation in December 2025, co-founded by Anthropic, Block and OpenAI among others.

For network operations that is the more relevant news. A model is replaceable; the question of which tools an agent may call and which data it sees while doing so is architecture. Build a clean abstraction today — inventory, state query, validation and change proposal as separate, individually authorised tools — and the model behind it can be swapped without renegotiating the security boundary.

The market is visibly moving the same way — network automation vendors are announcing agentic capabilities across the board. We deliberately quote no market figures here: the forecasts in circulation could not be traced back to a primary source. What follows anyway is not a product choice but a preparation.

Where agents already carry weight

Three applications work dependably today, because they change nothing and their output can be checked immediately:

• Pre-qualifying incidents. The agent gathers state, recent changes and adjacency and delivers a reasoned hypothesis — which a human confirms or discards in seconds.
• Drift reports. Actual configuration against intended, in readable language instead of a 4,000-line diff.
• Change preparation. Affected systems, dependencies, fallback plan and verification steps as a draft an engineer reviews and signs.

What does not belong there today without approval: anything that alters the data path. Not because agents are inherently unreliable, but because the ratio of benefit to risk is poor. One minute saved against an unplanned outage is not a trade an operator makes.

The question to answer before the pilot

Before selecting a tool, an uncomfortable self-check pays off. How long does it take today to say reliably which devices run which software version? How many ways are there to change a configuration? When was it last verified that the documented intended state matches the network?

If those three questions are uncomfortable, the first investment is not an agentic platform but the groundwork that determines the value of every later tool. If they are easy to answer, a pilot makes sense — and will contribute quickly.