Agentic AI in network operations

Why this matters

Network teams are starting to work alongside AI systems that do more than answer questions. An AI agent can be given a goal, such as "find out why the branch in Leeds is slow", and then log in to devices, run show commands, read the results and decide what to look at next. In a network operations centre, the person on shift may be a help-desk analyst moving into networking or a junior network engineer, and part of their job is now to read what an agent found, judge whether it is right, and decide whether its proposed fix should go ahead.

That judgement is the skill. An agent that is wrong can be wrong quickly and confidently, and an agent with too much access can turn a wrong idea into an outage. Without a clear sense of what agents are good at, what access they should have and where a human must stay in charge, a team either ignores a useful tool or hands it the keys to production. Cisco's description of the v2.0 exam says you may be asked to judge what AI agents and digital assistants report and recommend. This lesson gives you the model to do that.

The lesson

What agentic AI does for a network team

A generative AI model produces text, code or other content in reply to a prompt. On its own, it answers one prompt at a time and then stops. Lesson 25 covers how to write those prompts well.

Agentic AI wraps a model in a system that lets it act. It is given a goal, not just a question. It breaks the goal into steps, calls tools it has been granted, reads what the tools return and chooses its next step from what it learned. The tools are ordinary things a network engineer uses: an SSH session that runs show commands, a management platform's API, a ticketing system, a syslog search, an Ansible playbook (lesson 28).

In network operations, that means an agent can do the gathering and correlating work that takes a person the first half hour of most incidents. It does not need to run on the devices it manages, and it is not limited to what is in a vendor manual: it depends on live data from the network to decide what to do next. Several vendors, Cisco among them, now build AI assistants of this kind into their management platforms. The exam is about the concept, not a product, so this lesson stays with the concept.

Chat assistant versus agent

The difference shows up when you follow one task through both.

A scheduled script is different again. It runs the same commands in the same order every time, whatever they return. An agent chooses its next command from the result of the last one. That ability to change course is what makes it useful, and also what makes it harder to predict.

The agent loop: observe, reason, act

Agents work in a repeating loop.

1. Observe. Collect data: run a command, read an alarm, query an API.
2. Reason. Interpret the data against the goal. What does it suggest? What is still unknown?
3. Act. Choose and take the next step: another command, a summary, or a proposed change.

Then it observes the result of that action, and the loop goes round again.

Here is the loop in a short incident. An agent is asked why an application server in VLAN 20 is slow. It runs show interfaces on the access switch, sees rising input errors on the server's port, then decides by itself to check the duplex and speed on that port, then checks the upstream trunk for drops. No person told it to run the second and third commands. It chose them from what the first one showed. That is the observe, reason, act loop, and it is the behaviour that separates an agent from a one-shot answer or a fixed script.

Tools and access: what an agent can touch

An agent can only do what its tools and credentials allow. That makes access the most important safety decision a team makes, and the rule is the one you already apply to people: least privilege.

• Start read-only. When a team pilots an agent, give it a login that can run show commands and nothing else. It can gather evidence, and it cannot break anything while the team learns how it behaves. Privilege level 15 "so it can fix what it finds" hands an unproven system full control of production.
• Give it its own account. Never share the team's admin login with an agent. A dedicated account means every action in the logs can be traced to the agent, not to a person.
• Scope the account. With AAA and TACACS+ command authorization (lesson 17), the server can permit the exact commands the agent's role needs and deny the rest. An agent allowed to change access ports can be denied reload, routing changes or anything on the core.
• Limit where it can reach. Console access to every router at once is more reach than any troubleshooting task needs.

A narrow read-only account on IOS XE looks like this. The agent's account lands at privilege level 1, where it can run basic show commands but cannot enter configuration mode. (The password here is an example; a real one lives in a password vault, never in a prompt or a log.)

R1(config)#username ai-agent privilege 1 algorithm-type scrypt secret Ex4mple-Only-Pw
R1(config)#line vty 0 4
R1(config-line)#login local
R1(config-line)#transport input ssh

In larger networks the same idea is applied on the TACACS+ server instead, so one policy covers every device.

Keeping a human in the loop

An agent that can propose a change should not be the one that approves it. A human in the loop reviews the proposal, checks it against the evidence and approves it before it runs. This is ordinary change control, applied to a new kind of operator.

• If policy says every production change needs approval, the agent's change needs approval too. Running it "in the next quiet hour" or "now, with a report later" still skips the step policy requires.
• An agent must never approve its own changes into production.
• An agent should not retry changes over and over until something recovers. Repeated changes on a live network make a fault harder to understand.
• Setting security policy is a business decision. An agent can draft or check policy; people own it.

Two more controls make agent changes recoverable.

• Pre-change backups. Save the running configuration before each change (lesson 18 covers copying files off a device). Logs do not replace backups.
• Logging with reasons. Record every action the agent takes and the reason it gave for it, and keep device logging switched on. A log like the one below, from the incident worked through in the next section, lets engineers audit the agent's work, explain an outage and roll back a bad change. Logging adds accountability; it is never a reason to remove the approval step. Credentials must never be written into those logs.

2026-10-18 09:41:02 agent=ai-agent device=SW2 action="show interfaces status" reason="VLAN 30 users report no gateway"
2026-10-18 09:41:07 agent=ai-agent device=SW2 action="show interfaces trunk" reason="check VLAN 30 on uplink Gi1/0/48"
2026-10-18 09:41:20 agent=ai-agent device=SW2 proposal="interface Gi1/0/48 / switchport trunk allowed vlan add 30" status=awaiting-approval ticket=CHG-4471

Checking an agent's work

An agent's conclusion is a hypothesis. Before you accept it, look at the evidence yourself. The output in front of you outranks the agent's summary of it.

Here is a worked example. Users in VLAN 30 behind access switch SW2 cannot reach their gateway. The agent reports: "Root cause: VLAN 30 is not allowed on trunk Gi1/0/48. Fix: switchport trunk allowed vlan add 30 on Gi1/0/48." You check the trunk:

SW2#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/48    on           802.1q         trunking      1

Port        Vlans allowed on trunk
Gi1/0/48    10,20,30

Port        Vlans allowed and active in management domain
Gi1/0/48    10,20

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/48    10,20

Read it step by step.

1. The allowed line already includes 30. The agent's fix would change nothing.
2. The allowed and active line does not include 30. A VLAN is missing from that line when the switch does not have the VLAN in its database.
3. show vlan brief on SW2 confirms it: VLANs 1, 10 and 20 exist, and 30 does not.

So the real fix is to create VLAN 30 on SW2. Reject the agent's recommendation, and say why in the ticket, so the team learns where the agent goes wrong. The same habit applies to any claim: if an agent blames a duplex mismatch on one interface, check that interface's duplex and its collision counters before agreeing, because the evidence may point to a different port.

Commands that do not exist. AI systems can produce commands that look plausible but are not real on that platform or release. If you cannot find a command in the IOS XE command reference for the platform, treat it as unverified. Test it in a lab first. Do not ask the agent to confirm it: the same system that produced the command will often confirm it. And never treat the agent's stated confidence as evidence.

Where agents fit today

The tasks that suit an agent now are those where it saves time and an engineer can check the result before anything changes.

• Correlating alarms, logs and show output across many devices to propose a likely cause.
• Gathering evidence at the start of an incident, so the engineer begins with facts instead of an empty screen.
• Summarising long outputs, change histories or syslog bursts (lesson 29 covers reading syslog).
• Drafting a configuration or a change plan for a person to review and test.
• Checking documentation against what devices report, such as comparing a diagram with CDP and LLDP neighbours (lesson 10).

Tasks that do not suit an agent, with today's tools, are those that remove the human check: running unreviewed changes on core links, approving its own work, or deciding company policy. These limits are not about the agent being unintelligent. They exist because a person must remain accountable for what changes on the network.

What the exam is really asking

• Agent vs chat assistant. An agent pursues a goal by planning steps and calling tools; a chat assistant answers one prompt. If a scenario has the system choosing its next command from the last result, it is agentic.
• Agent vs script. A script runs a fixed order; an agent's loop of observing, reasoning and acting changes course.
• First access for a pilot. Read-only, show commands only, its own account. Not privilege 15, not a shared admin login.
• Changes need a person. A human reviews and approves before a production change runs. Time of day does not change that.
• Evidence beats the summary. When output contradicts the agent, the output wins. Find the interface or VLAN the evidence actually points to.
• Unknown commands are unverified. Check the command reference or test in a lab. Asking the agent again is not verification.
• Why log the reasons. For audit and rollback, not to skip approval and never to store passwords.
• Controls that reduce risk. An approval gate and a scoped account with command limits. Disabling logging, sharing passwords and skipping backups all increase it.