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:
- AI Planning Strategies for Cisco ACI Engineers: ReAct, Plan-and-Execute, and Tree of Thoughts in the Fabric
- 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
- Reactive Automation vs Generative AI vs Agentic AI in Networking
- 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