CCNA Agentic AI and Prompting: AI Agents, Guardrails and Prompt Components for Network Operations

Generative AI produces content, such as text, configuration or a summary, in response to a prompt and then stops; agentic AI is given a goal and works towards it by planning steps, calling tools to collect data or make changes, and deciding what to do next from the results. Both are usually built on a large language model (LLM). The difference is what surrounds the model: an agent has tools, a goal and permission to take more than one step without a person typing each prompt.

Some capabilities belong to the model itself, not to the agent: writing natural-language explanations of show output, and knowledge gained from training on networking text. A plain chat assistant has those too. What an agent adds is goal decomposition (breaking a goal into steps and choosing the next one from earlier results) and tool use. A digital network assistant is an AI assistant built into a network management or monitoring platform: it answers questions about the network it manages and recommends configuration changes or fixes, and some can also act through the platform. Whatever it is called, its output is evaluated the same way as any other AI output, against the evidence, before anything is applied. Neither kind of system is guaranteed to give the identical answer to the same input every time; LLM output varies from run to run.

An agent is also different from classic scripted automation. An Embedded Event Manager (EEM) applet or a syslog forwarding rule reacts to an event by running fixed, pre-written actions. It runs fixed, pre-written logic: it cannot weigh what it found against data from other devices, change its plan from the results or write a summary in plain language. An agent can, which is why it suits jobs such as "when this WAN link flaps at night, collect data from both ends, correlate it with syslog and page the on-call engineer with a summary".

The agent loop is the cycle an agent repeats until its goal is met: observe (read the current state or the result of the last action), reason/plan (decide what that result means and what to do next), act (call a tool, such as running a show command through an API), then observe the result of that action and go round again. Each pass narrows the problem, the way an engineer works through a troubleshooting method one command at a time.

The loop is easy to confuse with other AI terms:

• Prompt chaining: a person (or fixed code) sends a series of prompts, each written in advance or typed by hand. The model does not choose the next step.
• Fine-tuning: further training that changes the model's weights. It happens offline, before deployment, not between an agent's actions.
• Retrieval (retrieval-augmented generation, RAG): looking up documents, such as runbooks or design guides, and adding them to the model's context. An agent may use retrieval as one of its tools, but retrieval alone is not a loop.
• Temperature: a sampling setting that makes output more or less varied. It does not add control over what an agent is allowed to do.

To judge whether an agent is on the right track, read its action log like your own troubleshooting notes. A good next step follows the most specific clue the last result produced, towards the device and feature the evidence now points at. Steps that ignore the evidence fall into three patterns: treating one healthy check as proof the whole goal is met, repeating a check whose result cannot have changed, and taking a disruptive action on a device the evidence has not implicated. For example, if an agent chasing why hosts in one VLAN cannot reach their gateway finds the access port correctly assigned and up, the next useful check is whether that VLAN crosses the uplink trunk, not another look at the same access port or a reload of the access switch.

Agents act on the network only through the tools they are given: functions or APIs such as "get interface status", "run show command" or "push configuration". A common way to offer tools is a Model Context Protocol (MCP) server, an open standard through which an AI application discovers and calls tools and reads data sources. Whatever the tool layer, the rule is the same: what an agent can do is decided by the tools and credentials it holds, not by the instructions in its prompt.

A system-prompt rule such as "never enter configuration mode" is guidance the model usually follows, but a model can misread a request, be confused by unusual input or be manipulated by text hidden in data it reads (prompt injection). Real controls are enforced outside the model:

This is the least-privilege principle applied to software: give each agent the narrowest tools, device accounts and data it needs for its job, and widen them only deliberately. Credentials should be dedicated to the agent, so its activity is logged and attributable, rather than a shared admin account.

Agent-driven changes need the same safeguards as any production change, plus a decision about which actions may run without a person: human-in-the-loop approval for changes, free running only for read-only actions, and staging, backup and rollback to limit damage when an approved change still goes wrong.

• Human-in-the-loop (HITL) approval: the agent proposes a change and a qualified engineer approves or rejects it before it is pushed. This is the control when "a person must decide whether each change is applied". It places the decision before the change; anything that only shapes how the agent writes, or that reacts after a change has already been made, leaves the decision with the agent.
• Read-only versus state-changing actions: actions that only collect data (show interfaces, show logging, pinging, reading a configuration) are the natural candidates to run immediately. Anything that changes state waits for approval, including shutting or bouncing interfaces, filtering traffic and changing routing. Resets count as changes too: clearing statistics or restarting a process wipes state that an engineer may need as evidence.
• Staged (pilot) rollout: push a change to one site or device first, verify it, then continue. This limits the blast radius of a bad change to one site rather than all of them.
• Backup and tested rollback: save the configuration and have a known rollback before every push, so a misbehaving change can be reversed quickly.
• Logging and explanation: record every action and ask the agent to state its reasoning. This helps review and audit, but it does not prevent or contain a bad change.

Each control answers its own question. Approval rules decide who signs off and change windows decide when; only staging decides how many devices a single push reaches, and only a backup with a rollback plan decides how fast you can undo it.

Treat AI-generated configuration like a change written by a new colleague: check it against how IOS actually behaves before you apply it. LLMs produce plausible configuration that is often almost right, and the mistakes cluster in a few places that CCNA already teaches.

Standard ACL facts to have ready when reading AI output: a standard ACL matches the source address only, written as host plus an address, an address with a wildcard mask, or any; it is applied to an interface with ip access-group in either the in or the out direction; and every ACL ends with an implicit deny. Judge an AI-written ACL by what it permits after that implicit deny.

Check an AI diagnosis by asking whether every piece of evidence fits it, including the facts you already know and the AI may not, and whether another explanation fits better. A conclusion that ignores a clue, or that a simple counter-example disproves, should be rejected even if it sounds confident.

• Duplex mismatch, not a bad cable: if a NIC is hard-coded to 100 Mb/s full duplex while the switch port is left at auto, the NIC no longer autonegotiates. The switch still detects the speed but falls back to half duplex. The switch side then shows half-duplex, collisions and late collisions, while CRC and input errors may stay at zero. Damaged pairs normally show up as CRC and input errors, and a recent passed cable test points away from the cable. "Line protocol is up" says only that the link is working at Layer 2, not that it is healthy.
• A server is up if other clients use it: clients in one VLAN getting 169.254.x.x (APIPA) addresses while another VLAN gets leases from the same DHCP server proves the server and its service are running. The fault is on the path from the failing VLAN, commonly a missing ip helper-address on that VLAN's SVI. Relay is configured on each Layer 3 interface that faces clients, and the server picks the scope from the relay address of the interface the request arrived on. A 169.254.x.x address is one the client assigns itself when no offer arrives; it is never handed out by a server.
• Read the output the AI read: a trunk's allowed list, the interfaces listed in OSPF, the counters on a port. If the AI's claim contradicts what the output shows, the output wins.

The habit the exam rewards is the same one good troubleshooting needs: evidence first, then the hypothesis that explains all of it, then a fix that is both correct and safe.

Data classification in a prompt means sending a given AI service only the data its approval level allows, and removing or masking anything more sensitive first. Organisations label data in levels (for example Public, Internal, Confidential and Restricted) and approve each AI service for a maximum level: a public chatbot might be approved for Public data only, while an internal or enterprise assistant under contract is approved for Confidential data.

Two decisions follow:

1. Which service? Match the data's class to a service approved for it. If the task needs the real configuration and logs, send them to the service approved for that class. Approval belongs to the service and is settled before anything is sent; it cannot be granted by a request inside the prompt. Masking what the task does not need is how you keep the useful evidence while staying within policy.
2. What to redact? Even to an approved service, remove credentials and restricted data that the task does not need.

Masking means replacing the value, not deleting the line, so the AI still sees that the feature is configured: snmp-server community <REDACTED> RO.

The output format component tells the model exactly what shape the answer must take, so it can be used without reworking: commands only, a table, a numbered list or a structured format such as JSON. Without it, the model chooses a format, and that choice can change from one reply to the next.

• For a change ticket or a paste into a device: "Return only the IOS XE commands, in one code block, with no commentary."
• For a script that parses the reply: name a machine-readable structure and its fields, and forbid anything else, for example "Return a JSON array of objects with the fields interface, status and vlan, and nothing else." Free-form prose, however good, changes shape from reply to reply, and a parser needs the same structure every time.
• For people: a table of probable causes with the evidence for each, or a short summary first and detail afterwards.

Output format is separate from length. A word or sentence limit controls size, but it does not make the reply parseable or change who it is written for.

The persona sets the role the model takes and the audience it writes for; the instructions state the task itself, with the context and limits it needs. The CCNA exam topics list prompt components such as data classification, output format, persona and instructions.

Persona is the lever when the answer is accurate but pitched at the wrong reader: telling the model to write for a newcomer changes vocabulary and depth. It is not a substitute for the facts: an "expert" persona does not tell the model which platform you run or which interface to touch.

Good instructions are specific in four ways:

• The task: state the action and its object (diagnose, explain, compare, generate commands) and tie it to the evidence you supply. An open-ended or vague task gets a generic answer.
• Platform and release: name the operating system and version (for example IOS XE 17.12) so the commands match the device.
• Evidence: include the relevant show output or configuration (classified and masked as required) and say it is the current state.
• Scope: limit the change to the device, interface or feature you mean, so the model does not "fix" things you did not ask about.

Choose the prompt whose components all match the situation: the data is allowed for that service, the instruction asks for the task you actually need with the platform, evidence and scope stated, the persona fits the reader, and the output format fits where the answer is going. When comparing candidate prompts, find the one problem in the scenario (wrong service for the data, wrong format for a parser, wrong audience, missing platform, unlimited scope) and pick the change that fixes that problem directly.

A short worked contrast: "Help with my trunk." returns a general explanation of trunking because it has no platform, no evidence and no specific task. A strong version names the devices and release, states the symptom, attaches the relevant output, asks for the cause to be identified from that output and, if a fix is wanted, limits it and asks for commands only. Each added part does a different job; adding more of one part (a grander persona, a longer request) does not make up for a missing one.

Finally, every answer is still a draft. Prompting well raises the quality of AI output; it does not remove the need to evaluate that output against the evidence before anything reaches a production device.