An AI agent that can only talk isn't much use to an SD-WAN operations team. It can summarize a wall of syslog you paste in, sure — but it can't tell you a branch's current BFD state right now, and it definitely shouldn't be pushing a centralized policy change just because it "reasoned" its way there. What separates a chatbot from something you'd actually let near vManage is tools — the functions an agent is allowed to call to read from, act on, or talk about your overlay.
This post breaks down how tools work in an AI agent, using SD-WAN as the running example throughout, so the concepts map directly onto things you already manage — tunnels, SLA classes, device templates, and centralized policy.
Why "Just Talking" Isn't Enough on SD-WAN
Picture an agent with no tools at all:
Agent: "I think Branch-42's MPLS tunnel might be down, but I have no way to check."
Not useful. Now give it a single tool that can query vManage's device API:
Agent: [calls
get_tunnel_status(branch="Branch-42", transport="MPLS")] → "Branch-42's MPLS tunnel is down. BFD lost sync 4 minutes ago; the branch has failed over to Internet transport."
Same question, completely different value. That's the entire point of tools — they turn an agent from something that speculates into something that can actually verify against the overlay's real state.
The Four Tool Categories, Mapped to SD-WAN
Every tool an SD-WAN-aware agent might use falls into one of four buckets. Knowing which bucket a task belongs to tells you immediately how much oversight it needs.
1. Retrieval Tools — Read-Only Lookups
These pull information without changing anything: tunnel status, SLA performance, control-connection state, transport in use.
SD-WAN examples:
get_tunnel_status(branch, transport)— pull current BFD/session state for a specific tunnelget_sla_performance(tunnel, app_class)— loss/latency/jitter for a given app classget_control_connections(device)— check a device's control-plane state to vSmartget_active_transport(branch, app)— which underlay path an app is currently steered over
Retrieval tools are the safest category — an agent can call these freely without much risk, which is exactly why they're the easiest place to start trusting AI in SD-WAN operations.
2. Execution Tools — Tools That Change the Overlay
These make actual changes: pushing a centralized data policy, updating a device template, restarting a tunnel, triggering a software upgrade. Because SD-WAN policy is orchestrated centrally, execution tools deserve the most design care of any category — a bad push doesn't stay local, it propagates to every site attached to that policy or template.
SD-WAN examples:
deploy_data_policy(site_list, app_class, sla_class, mode)update_device_template(device, template, mode)trigger_software_upgrade(device, target_version, mode)
Notice the repeated mode parameter — more on that below. It's the single most important detail in an SD-WAN execution tool's design.
3. Communication Tools — Looping in Humans
These don't touch the overlay at all — they notify people. Sending a Slack alert about a degraded transport, opening a ServiceNow ticket for a recurring BFD flap, paging the on-call engineer when a regional hub loses reachability.
SD-WAN examples:
send_slack_alert(channel, message)— e.g., posting when an SLA class breaches threshold on a tunnelcreate_servicenow_ticket(summary, severity, affected_site)page_oncall(team, reason)— for something like a vSmart cluster losing quorum
These tools are how an agent stays useful even when it shouldn't act on its own — escalating to a human is often the correct behavior, not a fallback.
4. Perception Tools — Making Sense of Raw Data
These interpret information rather than fetch or change it: parsing a flood of BFD flap events into a plain-English summary, correlating a voice-quality complaint with a recent policy push, summarizing a week of vManage audit logs.
SD-WAN examples:
summarize_alarms(site, time_range)— turn 150 raw alarms into three actionable findingscorrelate_app_degradation(app, time_range)— check if a slowdown lines up with a recent policy or template changeparse_audit_log(controller, time_range)— extract what actually changed and who changed it
Perception tools are what let an agent reason well before it decides whether a retrieval or execution tool is even needed.
How the Agent Actually Picks a Tool
The agent doesn't understand SD-WAN the way you do — it reads tool descriptions and matches them against the question. This is why the wording of a tool's description matters as much as the code behind it.
Say someone asks: "Is the voice traffic class healthy on the Chicago-to-DC tunnel right now?"
The agent scans its available tools and finds get_sla_performance described as "Retrieve current loss, latency, and jitter for a given tunnel and application class." That's a strong match — it extracts the tunnel and the voice class as inputs and calls it.
A vague description like "Gets SD-WAN stuff" would leave the agent guessing between three different tools that all sound plausible. A precise description — naming exactly what the tool returns and for what object type — is what makes tool selection reliable instead of a coin flip.
Anatomy of an SD-WAN Tool Schema
Take deploy_data_policy as a worked example of what a well-designed execution tool schema looks like:
- Name:
deploy_data_policy— the unique identifier the agent calls - Description: "Push a centralized data policy affecting application routing for a site list. Warning: makes real overlay-wide changes." — the explicit warning matters; it tells the agent (and anyone reviewing its plan) that this isn't a harmless lookup
- Input schema:
site_list— which sites this policy scope applies toapp_class— the application or traffic match criteriasla_class— which SLA class the traffic should be pinned tomode— constrained to an enum of"preview"or"apply", defaulting to"preview"
That last field is the load-bearing detail. A default of preview means the agent's first call only shows what would happen — the policy doesn't actually get activated and pushed to vSmart until a human (or a separate, explicit step) chooses apply.
Schema design principles worth carrying into any SD-WAN tool you build:
- Write descriptions specific enough that two tools never sound interchangeable
- Type every input (don't let a site list or device ID be passed as a free-text string with no validation)
- Use enums to constrain choices like
mode,severity, orscope - Default to the safe option, never the destructive one
- Mark required fields so the agent can't fire a call with the site list or app class left blank
Safety Considerations for SD-WAN-Facing Tools
A tool that can act on a centrally orchestrated overlay needs guardrails baked in from the start — not bolted on after the first incident.
Destructive actions. A tool like deploy_data_policy can affect application routing across every branch in the site list. Mitigation: default to preview mode, require explicit confirmation before applying, and never let an agent's very first call against a tool be a live push.
Credential exposure. If a tool logs its inputs and one of those inputs happens to include a vManage API token or a RADIUS credential passed through for auth, that's a real exposure. Mitigation: never log sensitive fields — scrub credentials before anything gets written to a log or a transcript.
Ineffective guardrails. A tool scoped to "manage the entire overlay" is too broad — it hands an agent far more blast radius than any single task requires. Mitigation: scope each tool tightly — a policy-deployment tool shouldn't also be able to touch device templates or controller certificates.
Cascading failures. SD-WAN workflows chain tool calls — the output of a tunnel-health check might feed into whether a firmware upgrade proceeds. If one tool returns bad or stale data, a downstream tool can act on it. Mitigation: build rollback into any tool that changes state, and don't let a single failed check silently get treated as a pass.
The Validation Pipeline Before Anything Executes
Before an execution tool is allowed to actually touch vManage or vSmart, three checks should pass, in order:
- Schema compliance — Are all required fields present and correctly typed? If
site_listis missing ormodeisn't one of the allowed enum values, reject the call before it goes anywhere near the overlay. - Authorization — Does this user or agent identity actually have permission to call this tool? An agent scoped to read-only monitoring shouldn't be able to invoke
deploy_data_policyat all, regardless of what it "decides" to do. - Safety checks — Is this action allowed right now? A change-freeze window, an active P1 incident, or an in-progress controller upgrade are all reasons to block an otherwise-valid call.
Only after all three pass should the tool actually run against the controllers.
Quick Reference: Tool Category vs. Oversight Needed
| Category | SD-WAN Example | Oversight Level |
|---|---|---|
| Retrieval | get_tunnel_status, get_sla_performance | Minimal — safe to run freely |
| Execution | deploy_data_policy, update_device_template | High — preview mode, confirmation, rollback |
| Communication | send_slack_alert, page_oncall | Low — but should avoid alert fatigue |
| Perception | summarize_alarms, correlate_app_degradation | Low — but accuracy matters, since downstream decisions rely on it |
Final Thoughts
Tools are what make an AI agent useful on a real SD-WAN overlay instead of just a chatbot that can describe what an SLA class is. The four categories — retrieval, execution, communication, perception — map cleanly onto operations work you already do every day. The schema design determines whether tool selection is reliable or a guessing game. And the safety layer — preview-by-default execution, tight scoping, credential hygiene, and a validation pipeline before anything runs — is what determines whether you'd actually trust an agent near production vManage.
None of this replaces your judgment. It's what lets an agent earn a little bit of it, one well-scoped tool at a time.
FAQ
Q: Should an AI agent ever have direct, unsupervised write access to vManage? A: Generally no. Execution tools should default to preview mode and require explicit confirmation before applying, with authorization and safety checks run before every call — the same discipline you'd want from any junior engineer making overlay-wide changes.
Q: What's the biggest mistake in designing SD-WAN tool schemas for an agent? A: Vague tool descriptions. If two tools' descriptions sound interchangeable, the agent will eventually pick the wrong one — and on SD-WAN, the wrong tool call can mean a fleet-wide policy change instead of a simple status check.
Q: Are perception tools (like alarm summarization) risky the same way execution tools are? A: Not in the same way — they don't change the overlay — but their accuracy still matters, because a bad summary can lead a human or a downstream tool call to the wrong conclusion.
Related Reading on Networklearner:
- AI Planning Strategies for SD-WAN Engineers: ReAct, Plan-and-Execute, and Tree of Thoughts Across the Overlay
- How AI Agents Actually "Touch" Your Cisco ACI Fabric: Tools, Schemas, and Guardrails Explained
- AI Agent Reasoning Loop (ReAct) Explained for Network Engineers
- AI Agent Perception and Context Windows Explained for Network Engineers
- Understanding AI Agents for Network Engineers: LLMs, Prompts, Tokens and Context Explained
- Agentic AI for Network Engineers: What It Actually Means
- More posts on Networklearner
Need help with SD-WAN, Cisco ACI, Nexus, data center networking, or network automation?
I am a CCIE Data Center engineer with 18+ years of enterprise networking experience, working hands-on with production SD-WAN and ACI environments.
Contact me for consulting, troubleshooting, design reviews, and project support: rockingoa@gmail.com
No comments:
Post a Comment