Networklearner

Tuesday, 4 August 2026

How AI Agents Actually "Touch" Your SD-WAN Overlay: Tools, Schemas, and Guardrails Explained

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 tunnel
get_sla_performance(tunnel, app_class) — loss/latency/jitter for a given app class
get_control_connections(device) — check a device's control-plane state to vSmart
get_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 tunnel
create_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 findings
correlate_app_degradation(app, time_range) — check if a slowdown lines up with a recent policy or template change
parse_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 to
- app_class — the application or traffic match criteria
- sla_class — which SLA class the traffic should be pinned to
- mode — 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, or scope
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_list is missing or mode isn'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_policy at 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:

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

How AI Agents Actually "Touch" Your Cisco ACI Fabric: Tools, Schemas, and Guardrails Explained

An AI agent that can only talk isn't much use to an ACI operations team. It can summarize a fault log you paste in, sure — but it can't tell you Leaf-104's health score right now, and it definitely shouldn't be pushing a contract change just because it "reasoned" its way there. What separates a chatbot from something you'd actually let near APIC is tools — the functions an agent is allowed to call to read from, act on, or talk about your fabric.

This post breaks down how tools work in an AI agent, using Cisco ACI as the running example throughout, so the concepts map directly onto things you already manage — health scores, contracts, EPGs, and change windows.

Why "Just Talking" Isn't Enough on ACI

Picture an agent with no tools at all:

Agent: "I think Leaf-104 might be unhealthy, but I have no way to check."

Not useful. Now give it a single tool that can query APIC's health score API:

Agent: [calls get_node_health(node="Leaf-104")] → "Leaf-104's health score is 62. Two contract-related faults are currently active on this leaf."

The Four Tool Categories, Mapped to ACI

Every tool an ACI-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: health scores, fault counts, contract relationships, endpoint locations.

ACI examples:

get_node_health(node) — pull a leaf or spine's current health score
get_epg_faults(epg) — list active faults on a given EPG
get_endpoint_location(ip_or_mac) — find which leaf/port an endpoint is learned on
get_contract_relationships(tenant, epg) — list which contracts an EPG consumes/provides

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 ACI operations.

2. Execution Tools — Tools That Change the Fabric

These make actual changes: pushing a contract, modifying a Bridge Domain setting, restarting a service, triggering a firmware upgrade. Because ACI's policy model propagates changes fabric-wide, execution tools deserve the most design care of any category.

ACI examples:

deploy_contract(tenant, epg_consumer, epg_provider, filter, mode)
update_bridge_domain(tenant, bd, setting, value, mode)
trigger_firmware_upgrade(node, target_version, mode)

Notice the repeated mode parameter — more on that below. It's the single most important detail in an ACI execution tool's design.

3. Communication Tools — Looping in Humans

These don't touch the fabric at all — they notify people. Sending a Slack alert about a degraded leaf, opening a ServiceNow ticket for a recurring fault, paging the on-call engineer when a Multi-Site link drops.

ACI examples:

send_slack_alert(channel, message) — e.g., posting when a leaf's health score drops below threshold
create_servicenow_ticket(summary, severity, affected_tenant)
page_oncall(team, reason) — for something like an APIC 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 wall of fault codes into a plain-English summary, correlating a traffic spike with a recent contract change, summarizing a week of APIC audit logs.

ACI examples:

summarize_faults(tenant, time_range) — turn 200 raw fault codes into three actionable findings
correlate_traffic_anomaly(epg, time_range) — check if a spike lines up with a recent policy push
parse_audit_log(node, 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 ACI 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 EPG WEB-EPG healthy right now?"

The agent scans its available tools and finds get_epg_faults described as "Retrieve current fault count and severity for a given EPG." That's a strong match — it extracts WEB-EPG as the input and calls it.

A vague description like "Gets ACI 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 ACI Tool Schema

Take deploy_contract as a worked example of what a well-designed execution tool schema looks like:

Name: deploy_contract — the unique identifier the agent calls
Description: "Push a contract between two EPGs in a tenant. Warning: makes real fabric changes." — the explicit warning matters; it tells the agent (and anyone reviewing its plan) that this isn't a harmless lookup
Input schema:
- tenant — which tenant this applies to
- epg_consumer / epg_provider — the two EPGs the contract connects
- filter — the port/protocol filter being applied
- mode — 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 actual zoning-rule programming on the leaves doesn't happen until a human (or a separate, explicit step) chooses apply.

Schema design principles worth carrying into any ACI tool you build:

Write descriptions specific enough that two tools never sound interchangeable
Type every input (don't let a device ID be passed as a free-text string with no validation)
Use enums to constrain choices like mode, severity, or scope
Default to the safe option, never the destructive one
Mark required fields so the agent can't fire a call with the tenant or EPG left blank

Safety Considerations for ACI-Facing Tools

A tool that can act on a shared fabric needs guardrails baked in from the start — not bolted on after the first incident.

Destructive actions. A tool like update_bridge_domain can affect flooding or ARP behavior fabric-wide. 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 an APIC admin token or a TACACS 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 fabric" is too broad — it hands an agent far more blast radius than any single task requires. Mitigation: scope each tool tightly — a contract-deployment tool shouldn't also be able to touch fabric access policies.

Cascading failures. ACI workflows chain tool calls — the output of a 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 APIC, three checks should pass, in order:

Schema compliance — Are all required fields present and correctly typed? If tenant is missing or mode isn't one of the allowed enum values, reject the call before it goes anywhere near the fabric.
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_contract at 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 firmware upgrade are all reasons to block an otherwise-valid call.

Only after all three pass should the tool actually run against APIC.

Quick Reference: Tool Category vs. Oversight Needed

Category	ACI Example	Oversight Level
Retrieval	`get_node_health`, `get_epg_faults`	Minimal — safe to run freely
Execution	`deploy_contract`, `update_bridge_domain`	High — preview mode, confirmation, rollback
Communication	`send_slack_alert`, `page_oncall`	Low — but should avoid alert fatigue
Perception	`summarize_faults`, `correlate_traffic_anomaly`	Low — but accuracy matters, since downstream decisions rely on it

Final Thoughts

Tools are what make an AI agent useful on a real ACI fabric instead of just a chatbot that can describe what a health score 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 APIC.

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 APIC? 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 fabric changes.

Q: What's the biggest mistake in designing ACI 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 ACI, the wrong tool call can mean a fabric-wide policy change instead of a simple status check.

Q: Are perception tools (like fault summarization) risky the same way execution tools are? A: Not in the same way — they don't change the fabric — but their accuracy still matters, because a bad summary can lead a human or a downstream tool call to the wrong conclusion.

Monday, 3 August 2026

AI Planning Strategies for SD-WAN Engineers: From a Single Edge Query to Multi-Site Policy Design

SD-WAN engineers already live in a world of layered decisions — underlay vs. overlay, per-app policy vs. site-wide policy, one control-plane failure that can silently affect hundreds of branches at once. That's exactly the kind of environment where how an AI agent plans before it acts becomes critical, not optional.

This post walks through the same five AI planning patterns from the ACI-focused piece, this time mapped to real Cisco SD-WAN (Viptela-based) and general SD-WAN scenarios — vEdge/cEdge devices, vSmart policy, vManage templates, and application-aware routing.

Why Planning Discipline Matters More on SD-WAN Than on Traditional WAN

A misconfigured VLAN on a single branch router is a local problem. A bad centralized policy pushed from vSmart, or a template change rolled out from vManage, can affect every branch attached to that policy in minutes.

SD-WAN is centrally orchestrated by design — which is exactly why it's powerful, and exactly why an AI agent acting on it needs a visible, reviewable plan before it pushes anything control-plane-wide. The same five patterns from the ACI world map directly here.

1. Single-Step ReAct — One Question, One Answer

Quick, read-only, no multi-step reasoning required.

SD-WAN scenario: "What's the BFD session status between Branch-42 and the DC hub?"

The agent queries the device or vManage API for that BFD session state and reports it back — done in one pass.

Other single-step SD-WAN use cases:

Checking a specific site's control connection status to vSmart
Pulling current SLA class performance (loss/latency/jitter) for one tunnel
Looking up which transport (MPLS/Internet/LTE) a branch is currently using
Checking a device's software version and reboot history
Reporting current CPU/memory utilization on an edge router

Fast and low-risk — this is where SD-WAN teams will trust an AI agent first, the same as with ACI health checks.

2. Multi-Step ReAct — Following a Known Runbook

Repeatable SD-WAN procedures that follow a fixed sequence, reacting to each step's result before moving to the next.

SD-WAN scenario: Onboarding a new branch edge device (Zero Touch Provisioning).

Confirm the device authenticates and registers with the vBond orchestrator
Verify it establishes control connections to all vSmart controllers
Push the correct device template (system, VPN, interface, routing)
Confirm both underlay transports (e.g., MPLS and Internet) come up and form BFD sessions
Validate the branch inherits the correct centralized data policy and SLA classes
Confirm end-to-end reachability to the DC/hub over the preferred transport

If step 4 fails — say, the Internet transport won't form a BFD session — the agent checks NAT/firewall rules and STUN/TURN behavior on that transport before continuing, the same troubleshooting instinct you'd apply.

Other multi-step SD-WAN use cases:

vSmart/vManage software upgrade sequence (stage → upgrade one controller at a time → validate cluster/control-plane health before continuing)
Site migration from MPLS-only to dual-transport SD-WAN, step by step
Scheduled maintenance window pre-checks and rollback validation
Certificate renewal and re-establishment of control connections across all controllers

3. Plan-and-Execute — For When the Overlay Is Telling You Conflicting Things

SD-WAN issues are rarely single-cause: an app slowness complaint could be transport degradation, an application-aware routing policy misfire, an underlay MTU/fragmentation issue, or a vSmart policy conflict. Jumping straight to a fix risks masking the real problem.

SD-WAN scenario: Voice quality complaints from three branches, all pointing to the same regional hub.

The agent proposes a plan before acting:

Pull SLA class performance (loss/latency/jitter) for the voice traffic class across the affected tunnels
Check whether application-aware routing actually steered voice traffic onto the best-performing tunnel, or if policy is pinning it to a degraded path
Compare current transport performance against baseline to rule out an ISP-side issue
Check for recent centralized policy or template pushes correlating with when complaints started
Verify QoS queuing/shaping is still correctly applied on the WAN interface after any recent template change
Correlate the timeline across all three sites to confirm it's a shared hub/policy issue, not three unrelated local problems

Only once you review and approve that plan does the agent move into root-causing — so if it's about to check the wrong SLA class, you catch it before time is wasted.

Other Plan-and-Execute SD-WAN use cases:

Multi-region latency/convergence issue after a WAN policy change
vSmart control-plane instability or intermittent control connection flaps
Investigating a brownout on one transport affecting failover behavior fleet-wide
Diagnosing asymmetric routing after a dual-hub topology change

4. Tree of Thoughts — For Architecture and Design Decisions

Design decisions in SD-WAN rarely have one obviously-correct answer — they depend on transport availability, app requirements, and resiliency goals. Tree of Thoughts has the agent lay out multiple candidate designs and weigh trade-offs instead of committing to the first idea.

SD-WAN scenario: A customer wants to redesign branch connectivity to reduce reliance on MPLS.

The agent compares branches of the decision tree:

Option	Strength	Trade-off
Dual-Internet, no MPLS	Lowest cost, fastest to deploy	No guaranteed-SLA transport; relies entirely on app-aware routing and forward error correction to mask ISP issues
Hybrid (single MPLS + single Internet)	Keeps a guaranteed-SLA path for critical apps	Doesn't fully solve the cost/dependency problem; still one MPLS circuit as a dependency
Dual-Internet with regional SD-WAN hubs (Cloud onramp)	Reduces backhaul distance, better cloud app performance	Requires cloud gateway design and more complex routing policy
Full mesh with Direct Cloud Access (DIA)	Best performance for SaaS/cloud apps, minimal hub dependency	Higher security policy overhead — every branch now needs local internet breakout security

The agent weighs these against the customer's actual requirements — how latency-sensitive their critical apps are, whether they need a guaranteed SLA, how much cloud/SaaS traffic they run — and recommends the best fit.

Other Tree of Thoughts SD-WAN use cases:

Choosing centralized (hub-and-spoke) vs. full-mesh vs. partial-mesh topology
Deciding transport-side vs. tunnel-side application-aware routing policy design
Evaluating single-vSmart vs. dual-vSmart-cluster resiliency models
Weighing security service insertion options: local branch firewall vs. cloud-delivered SASE vs. hub-based inspection

5. Self-Reflection — Catching Mistakes Before They Hit Every Branch

This is the pattern that matters most for anything an agent pushes centrally, because a mistake in a centralized policy doesn't stay local — it propagates to every site attached to it.

SD-WAN scenario: An agent drafts a new centralized data policy to prioritize a new SaaS application across all branches.

Before presenting the policy, it reflects:

Does the match criteria (App/App-list, DSCP, prefix) actually match only the intended traffic, or is it broad enough to accidentally catch other flows?
Does the SLA class assignment make sense for this app, or did it get assigned a stricter class than necessary, starving other traffic?
Will this policy override an existing site-list-specific policy unintentionally?
Is the policy scoped to the correct site-list/VPN, or could it apply fleet-wide when only a subset of branches needs it?
Does this match the customer's existing policy-numbering and naming convention, to avoid confusion during future audits?

Catching an over-broad match statement — one that would have silently reprioritized unrelated traffic across the whole fleet — before it's activated is exactly what Self-Reflection is for.

Other Self-Reflection SD-WAN use cases:

Reviewing an auto-generated device template before it's attached and pushed to production branches
Validating a drafted QoS/queuing policy against the customer's bandwidth allocation standard
Auditing a generated SLA compliance report against actual tunnel performance data before sending it to a customer
Second-pass review of an AI-suggested software upgrade plan for skipped compatibility or downtime-window checks

Which Strategy Fits Your SD-WAN Task?

SD-WAN Scenario	Recommended Strategy
Checking a tunnel's BFD state or SLA performance	Single-Step ReAct
Onboarding a branch via ZTP or running a known upgrade runbook	Multi-Step ReAct
Troubleshooting a multi-site voice/app performance complaint	Plan-and-Execute
Choosing hub-and-spoke vs. full-mesh vs. Cloud onramp design	Tree of Thoughts
Drafting a centralized policy or template for review	Self-Reflection

Final Thoughts

The patterns don't change between ACI and SD-WAN — only the blast radius and the objects being reasoned about do. Single-Step ReAct answers a quick status question. Multi-Step ReAct runs your onboarding or upgrade runbook. Plan-and-Execute is how you investigate a fleet-wide performance complaint without guessing. Tree of Thoughts is the topology whiteboard session before a redesign gets signed off. Self-Reflection is the second pair of eyes before a centralized policy touches every branch at once.

As AI agents get closer to actually pushing policy through vManage and vSmart, the discipline behind how they plan matters as much as what they execute. An agent that shows its plan — and reflects on its own output — is one you can trust near a live overlay.

FAQ

Q: Which planning strategy should an AI agent use before pushing a centralized SD-WAN policy? A: Self-Reflection combined with Plan-and-Execute — the agent should draft the policy, check it against a scoping/match-criteria checklist, and present it for approval before anything is activated fleet-wide.

Q: Is Plan-and-Execute overkill for checking one branch's tunnel status? A: Yes. A single tunnel or BFD status check only needs Single-Step ReAct. Plan-and-Execute pays off on multi-cause, multi-site problems — not routine status lookups.

Q: How is this different from the ACI version of this framework? A: The planning patterns are identical — the difference is the blast radius. On ACI, a bad change can spread across a fabric or Multi-Site domain. On SD-WAN, a bad centralized policy or template can spread across every branch attached to it. Either way, visible planning and self-review are what make an agent safe to use near production.

Related Reading 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