Artificial intelligence is changing the way network engineers approach monitoring, troubleshooting, and automation.
Traditionally, a network engineer might receive an alert, log in to the Cisco SD-WAN management platform, check device health, investigate WAN links, examine tunnel status, review application performance, and then decide what action should be taken.
Now imagine an AI agent performing many of these activities automatically.
It could collect SD-WAN information, analyze the results, decide what to investigate next, evaluate whether its findings make sense, and continue until it identifies the likely problem.
If a production configuration change is required, it could stop and request approval from the network engineer.
This is the idea behind the Agent Loop.
For network engineers, the concept can be summarized as:
Understand → Act → Observe → Reflect → Decide → Repeat or Stop
The source material describes the complete agent loop as an extension of the basic Think → Act → Observe cycle, adding reflection and a termination decision.
1. What Is an Agent Loop?
An Agent Loop is a continuous cycle in which an AI agent works toward a defined objective.
A simplified workflow looks like this:
Network Problem
↓
Understand Goal
↓
Think
↓
Act
↓
Observe
↓
Reflect
↓
Should I Stop?
↙ ↘
Yes No
↓ ↓
Result Next Action
↓
Repeat
The important part is that the agent doesn't necessarily follow one fixed sequence.
The result of one action can influence the next action.
This makes the concept particularly interesting for SD-WAN troubleshooting.
For example, an agent might initially decide to check WAN connectivity. If the WAN links are healthy, it may decide that checking path performance or application routing is more useful than repeating the same connectivity check.
The source material describes reflection as an evaluation performed after an action, including questions about whether the action succeeded, whether the agent is closer to its goal, whether it should try something different, and whether it is time to stop.
2. Why Is Agentic AI Interesting for Cisco SD-WAN?
SD-WAN environments generate a large amount of operational information.
A network engineer may need to investigate:
- WAN connectivity
- Transport availability
- Tunnel status
- Latency
- Jitter
- Packet loss
- Application performance
- Routing
- Device health
- Policy behavior
- Control-plane information
- Security events
A human engineer can investigate these individually.
An AI agent could potentially correlate multiple pieces of information and determine what to investigate next.
For example:
Problem: Users report that an application is slow.
The agent could investigate:
WAN health → path performance → application traffic path → policy → routing → possible remediation
The important concept is that the next step can be influenced by the result of the previous step.
That is what makes an agent different from a simple fixed automation script.
3. The Basic Think → Act → Observe Model
A useful way to understand agent behavior is:
Think → Act → Observe
Let's apply this to a Cisco SD-WAN troubleshooting scenario.
Think
The agent receives:
"The ERP application is slow for users at the branch."
The agent decides that it needs to investigate whether WAN performance is affecting the application.
Act
The agent collects WAN performance information.
Observe
The agent discovers that one transport has elevated latency and packet loss.
Now the agent has new information.
It can decide what to investigate next.
For example:
"I found a degraded transport. I should determine whether ERP traffic is currently using this transport."
This is the beginning of an agent loop.
4. Reflection: The Step That Makes the Agent Adaptive
Reflection is one of the most important parts of the complete Agent Loop.
After an action, the agent evaluates the result.
It can ask:
- Did my action succeed?
- Did I receive useful information?
- Am I closer to the objective?
- Should I investigate something else?
- Should I change my approach?
- Is there enough evidence to continue?
- Should I stop?
The source material identifies reflection as a self-assessment step after each action.
For SD-WAN troubleshooting, this can prevent the agent from blindly following a predefined checklist.
For example:
Check WAN transport
Result:
Both transports are operational.
The agent should not necessarily conclude:
"WAN is healthy, therefore WAN is not the problem."
Instead, it can reflect:
"Transport availability is normal. I should investigate latency, packet loss, application path selection, or policy behavior."
It then performs the next appropriate investigation.
5. Cisco SD-WAN Troubleshooting Example
Let's consider a practical example.
A branch office reports:
"The corporate ERP application is very slow."
The AI agent receives the objective:
Investigate the cause of ERP performance degradation.
The agent starts investigating.
Step 1 – Check Device Health
The agent checks the branch SD-WAN device.
Result: Device is operational.
The agent continues.
Step 2 – Check WAN Transports
The agent checks the available WAN transports.
Result: Both transports are available.
The agent continues.
Step 3 – Check Performance
The agent checks latency, jitter, and packet loss.
Result: Transport A has elevated latency and packet loss.
Step 4 – Reflect
The agent evaluates the result:
"Transport A is degraded. I need to determine whether the affected application is using this transport."
Step 5 – Check Application Path
The agent investigates the path being used by the application.
Result: ERP traffic is using Transport A.
Step 6 – Reflect Again
The agent now has stronger evidence:
"The application is using a transport that is experiencing performance degradation."
The agent can now investigate whether an alternate transport is available and whether the configured policy allows the traffic to use it.
This is a practical example of:
Think → Act → Observe → Reflect → Act Again
6. Agent Loop vs Traditional SD-WAN Automation
This distinction is important for network engineers.
| Traditional Automation | Agentic Automation |
|---|
| Predefined workflow | Goal-oriented workflow |
| Fixed sequence | Dynamic next step |
| Engineer defines each step | Agent can select the next investigation |
| Usually predictable | Context-dependent |
| Rule-based decisions | Observation-based decisions |
| Limited decision-making | Reflection after actions |
| Fixed stopping point | Dynamic termination |
Traditional automation remains extremely useful.
For repetitive and predictable tasks, a script or predefined workflow may actually be preferable.
Agentic AI becomes more interesting when the problem requires investigation and the next step depends on what was discovered previously.
7. The Most Important Question: When Should the Agent Stop?
An autonomous system should not continue forever.
Imagine an agent repeatedly checking the same WAN path:
Check Path
↓
Timeout
↓
Check Path
↓
Timeout
↓
Check Path
↓
Timeout
↓
Repeat...
This wastes resources and does not solve the problem.
Every agent therefore needs termination conditions.
The source material identifies several common termination triggers, including task completion, maximum iterations, confidence thresholds, human handoff, and error states.
For network automation, these termination conditions are extremely important.
8. Termination Condition #1 – Task Completed
The simplest condition is:
The objective has been achieved.
For example, the agent was asked to investigate why ERP traffic is slow.
After investigation, it identifies the degraded transport and the application path.
If the problem has been safely resolved and verified, the agent can stop.
A final response could be:
"The application was using a WAN transport experiencing packet loss. Traffic was moved to the healthy path and application performance was verified."
The task is complete.
9. Termination Condition #2 – Maximum Iterations
Every autonomous troubleshooting workflow should have a maximum number of attempts.
For example:
Maximum iterations = 10
If the agent reaches ten meaningful actions without reaching a conclusion, it stops.
This prevents an uncontrolled troubleshooting loop.
The source material describes maximum iterations as a safety mechanism that prevents an agent from continuing indefinitely.
A good response could be:
"I could not determine the root cause within the configured investigation limit. Human investigation is recommended."
10. Termination Condition #3 – Confidence Threshold
An agent may also evaluate its confidence in a particular diagnosis.
For example:
"There is strong evidence that Transport A is responsible for the application performance problem."
However, network engineers should be careful with confidence scores.
An AI system can be confident and still be wrong.
Therefore:
AI confidence should support a decision, not replace engineering validation.
The source material specifically highlights the risk of agent overconfidence and recommends human validation for critical actions.
11. Termination Condition #4 – Human Handoff
Sometimes the agent identifies the likely solution but should not execute it automatically.
For example:
"Transport A is degraded and ERP traffic is using it. I recommend changing the traffic policy to prefer Transport B."
At this point, the agent can request approval.
The workflow becomes:
AI Investigation
↓
Diagnosis
↓
Recommended Change
↓
Human Approval
↓
Execute
↓
Verify
This is called Human-in-the-Loop, or HITL.
The source material describes HITL as a mechanism where the agent pauses and requests human input when the action is high-stakes or outside its authority.
12. Termination Condition #5 – Error State
Sometimes the problem isn't the network itself.
The management system or required tool may be unavailable.
For example:
Agent
↓
Query Management Platform
↓
API Unavailable
↓
Retry
↓
API Unavailable
↓
Retry Limit Reached
↓
Stop
The agent should report the issue instead of pretending that the investigation was completed.
The source material describes an error state as a situation where a required system is unreachable, a tool repeatedly fails, or a dependency does not respond.
13. What Happens When an AI Agent Gets Stuck?
An AI agent can get stuck even when the network itself is operational.
The source material identifies four important stuck states:
- Loop
- Oscillation
- Dead End
- Hallucination
Let's translate these concepts into SD-WAN troubleshooting.
14. Stuck State #1 – Loop
A loop occurs when the agent repeatedly performs the same action without making progress.
For example:
Check Tunnel
↓
Timeout
↓
Check Tunnel
↓
Timeout
↓
Check Tunnel
↓
Timeout
The agent is not learning anything new.
A properly designed system should detect the repeated operation and either try an approved alternative, escalate, or stop.
15. Stuck State #2 – Oscillation
Oscillation occurs when the agent keeps switching between approaches without making progress.
For example:
Check Transport A
↓
No conclusion
↓
Check Transport B
↓
No conclusion
↓
Check Transport A
↓
Check Transport B
↓
Repeat
The agent is changing tactics but not actually moving closer to the objective.
Action-history tracking can help identify this behavior.
16. Stuck State #3 – Dead End
A dead end occurs when all useful investigation paths fail.
For example:
- Management API unavailable
- Device access unavailable
- Performance data unavailable
- Monitoring data unavailable
The agent has no reliable path forward.
At this point, the safest action is to stop and escalate to a network engineer.
17. Stuck State #4 – Hallucination
Hallucination is particularly important when AI is connected to network automation tools.
An AI agent could potentially assume that a tool or API exists when it does not.
For example, it might attempt to call an invalid API endpoint or provide an incorrect input format.
The source material describes hallucination as attempting to call tools that do not exist or passing invalid inputs.
This is why tool validation and restricted permissions are important when building AI-powered network automation.
18. How Can We Prevent an Agent From Getting Stuck?
The source material recommends a layered approach that combines iteration limits, action-history tracking, fallback strategies, and human escalation.
For SD-WAN automation, we can apply the same principles.
18.1 Set Iteration Limits
Define the maximum number of actions the agent can perform.
18.2 Track Action History
Record what the agent has already checked.
For example:
Action 1: Check device health
Action 2: Check transport
Action 3: Check latency
Action 4: Check application path
The agent can use this information to avoid repeating the same investigation.
18.3 Detect Repeated Actions
If the same operation repeatedly produces the same result, the agent should recognize the pattern.
18.4 Provide Fallback Strategies
If the primary information source is unavailable, use an approved alternative.
For example:
Primary:
Management API
Fallback:
Approved telemetry source
Fallback:
Monitoring platform
Final:
Human escalation
18.5 Escalate to a Human
If all approved automated strategies are exhausted, the agent should involve a network engineer.
The objective isn't to keep the agent autonomous at all costs.
The objective is to solve the problem safely.
19. Human-in-the-Loop in Cisco SD-WAN
HITL becomes particularly important when an agent wants to modify production network behavior.
Imagine the agent determines:
"Transport A has high packet loss. ERP traffic would perform better over Transport B."
The agent can recommend a policy change.
Instead of immediately making the change:
AI Agent
↓
Analyze
↓
Recommend Change
↓
HITL Checkpoint
↓
Engineer Approval
↓
Execute
↓
Verify
The engineer can:
Approve → Agent executes the approved change.
Reject → Agent stops.
Modify → Engineer adjusts the proposed action.
The source material identifies these approval outcomes and emphasizes HITL for important production decisions.
20. When Should Human Approval Be Required?
For SD-WAN automation, human approval can be appropriate for actions such as:
- Changing traffic policies
- Modifying routing behavior
- Changing path preferences
- Modifying security policies
- Changing production configuration
- Actions affecting critical applications
- Actions outside an approved change window
The source material identifies destructive actions, sensitive operations, uncertainty, policy requirements, and learning-mode deployments as situations where HITL may be required.
A good principle is:
Let AI investigate, but make production changes subject to appropriate controls.
21. Example: AI Agent Troubleshooting a Cisco SD-WAN Branch
Let's put everything together.
Imagine a branch office is experiencing poor ERP application performance.
Objective
"Investigate ERP performance from the branch."
Step 1 – Check Device Health
Result:
Device operational.
Step 2 – Check WAN Transports
Result:
Both transports are available.
Step 3 – Check Performance
Result:
Transport A has elevated packet loss and latency.
Step 4 – Reflect
The agent determines:
"Transport A is degraded. I need to determine whether ERP traffic is using this path."
Step 5 – Check Application Path
Result:
ERP traffic is using Transport A.
Step 6 – Reflect
The agent concludes:
"The degraded transport may be contributing to the application performance problem."
Step 7 – Check Alternate Path
Result:
Transport B is healthy and available.
Step 8 – Generate Recommendation
"Recommend moving ERP traffic to Transport B."
Step 9 – Human Approval
The agent waits for the network engineer.
Step 10 – Execute
The engineer approves the change.
The agent performs the approved action.
Step 11 – Verify
The agent checks the application performance again.
Step 12 – Terminate
The issue is resolved.
This is a complete Agent Loop:
Think → Act → Observe → Reflect → Act → Verify → Stop
22. What Should the Agent Log?
For production SD-WAN environments, logging is extremely important.
A useful agent trace might look like:
Incident ID: INC-10234
09:10 - Task received
09:11 - Branch health checked
09:12 - WAN transports checked
09:13 - Transport A degradation detected
09:14 - Application path analyzed
09:15 - ERP traffic found on Transport A
09:16 - Alternate transport validated
09:17 - Recommendation generated
09:20 - Human approval received
09:21 - Approved action executed
09:22 - Application performance verified
09:23 - Task completed
This creates an audit trail.
If something goes wrong, the engineer can understand:
- What the agent attempted
- What it observed
- Why it made the decision
- What action was performed
- Why the agent stopped
The source material emphasizes that termination reasons should be recorded because silent failures make diagnosis and accountability difficult.
23. Why Network Engineers Should Care About Agentic AI
SD-WAN already provides significant automation.
Agentic AI potentially adds another layer.
Traditional SD-WAN
Provides automated connectivity, routing, policy enforcement, and path selection.
AI-Assisted SD-WAN
Helps engineers understand network behavior and investigate problems.
Agentic SD-WAN
Could potentially investigate a problem, collect evidence, determine the next troubleshooting step, recommend remediation, and execute approved actions.
This is why network engineers should understand Agentic AI.
You don't necessarily need to become an AI researcher.
But understanding concepts such as:
- AI agents
- Agent loops
- APIs
- Tool calling
- Reflection
- Termination
- Human-in-the-Loop
- Guardrails
- Automation
- Observability
can become increasingly valuable.
24. Automation vs Agentic Automation
A simple way to remember the difference is:
Traditional Automation
IF condition
↓
Perform predefined action
Agentic Automation
Goal
↓
Observe
↓
Reason
↓
Act
↓
Evaluate
↓
Select Next Action
↓
Repeat
Safe Agentic Automation
Goal
↓
Observe
↓
Reason
↓
Act
↓
Evaluate
↓
Safety Check
↓
Human Approval if Required
↓
Verify
↓
Terminate
For production networking, the third model is the most useful mental model.
25. Cisco SD-WAN + AI: A Possible Architecture
A conceptual architecture could look like this:
Network Engineer
│
↓
AI Agent
│
↓
Reasoning / Planning
│
↓
Safety Layer
│
┌─────────┴─────────┐
↓ ↓
Read Operations Change Operations
│ │
↓ ↓
SD-WAN Information HITL Approval
│ │
└─────────┬─────────┘
↓
SD-WAN Network
│
↓
Telemetry / Data
│
└────→ AI Agent
The key component is the Safety Layer.
An AI agent should not have unrestricted access to a production network.
26. Read-Only vs Change-Enabled AI Agents
Network teams can approach AI adoption gradually.
Level 1 – AI Assistant
The engineer asks:
"Why is this SD-WAN path being selected?"
The AI provides an explanation.
Level 2 – Read-Only Agent
The agent can collect operational information such as:
- Device health
- Transport status
- Performance
- Routing information
But it cannot modify the network.
Level 3 – Investigation Agent
The agent investigates an incident and provides a likely root cause.
For example:
"The application is using a transport experiencing high packet loss."
Level 4 – Recommendation Agent
The agent proposes remediation.
For example:
"Recommend moving the application to the alternate transport."
Level 5 – Human-Approved Automation
The agent proposes the change.
The engineer approves it.
The agent executes it.
Level 6 – Controlled Autonomous Operations
Selected low-risk actions can potentially be automated under strict policies and guardrails.
This should only be considered after extensive testing, monitoring, validation, and governance.
27. Safety: Never Trust an AI Agent Blindly
One of the most important lessons from Agentic AI is that confidence does not automatically mean correctness.
An AI agent can produce an incorrect conclusion with high confidence.
The source material highlights several safety considerations, including silent failures, overconfidence, context loss during human handoffs, and automation bias.
For network engineers, remember:
AI recommendation ≠ Network Truth
Critical conclusions should be validated.
For production changes, consider:
- Change approval
- RBAC
- Audit logging
- Rollback capability
- Iteration limits
- Tool restrictions
- Human approval
- Post-change verification
28. The Importance of Verification
The agent should not simply perform an action and assume that the problem is solved.
For example:
Agent: Move traffic to Transport B.
That is not the end of the workflow.
The agent should verify:
- Is traffic now using the expected path?
- Has packet loss improved?
- Has latency improved?
- Is the application responding normally?
- Did the change introduce another problem?
The complete workflow should therefore be:
Diagnose → Change → Verify → Terminate
This is a familiar concept to network engineers.
After all, we rarely make a production change without checking whether the expected result occurred.
29. The Golden Rules for AI-Based SD-WAN Automation
If you are designing an AI agent for SD-WAN operations, remember these principles:
Rule 1 – Define the Goal
The agent needs a clear objective.
Rule 2 – Limit Iterations
Never allow unlimited execution.
Rule 3 – Track History
Know what the agent has already attempted.
Rule 4 – Detect Loops
Repeated actions should trigger investigation or escalation.
Rule 5 – Provide Fallback Paths
Don't depend on one data source.
Rule 6 – Use Human Approval
High-impact production changes should have appropriate approval.
Rule 7 – Log Important Actions
Maintain a useful audit trail.
Rule 8 – Don't Trust AI Confidence Blindly
Validate important conclusions.
Rule 9 – Verify the Result
After an action, confirm that the expected outcome occurred.
Rule 10 – Define When to Stop
Every agent needs a clear termination strategy.
30. How This Applies to FortiGate SD-WAN
The same Agent Loop methodology can also be applied to FortiGate SD-WAN environments.
The vendor terminology, management interfaces, APIs, and available operational data will be different, but the basic methodology remains the same.
For example:
Application Performance Problem
↓
Understand Goal
↓
Check SD-WAN Health
↓
Observe SLA Status
↓
Analyze Path Choice
↓
Reflect
↓
Identify Likely Cause
↓
Recommend Remediation
↓
Human Approval
↓
Apply Approved Change
↓
Verify Result
↓
Stop
This demonstrates an important point:
The Agent Loop is a methodology rather than a vendor-specific feature.
It can be applied to Cisco SD-WAN, FortiGate SD-WAN, Cisco ACI, and other network platforms when appropriate data and controlled automation interfaces are available.
31. A Simple Mental Model for Network Engineers
If Agentic AI terminology seems complicated, think about how you already troubleshoot a network.
When an application is slow, you don't normally execute commands randomly.
You:
- Understand the problem.
- Form a hypothesis.
- Collect information.
- Analyze the result.
- Change the hypothesis if necessary.
- Investigate another area.
- Identify the likely cause.
- Apply a controlled fix.
- Verify the result.
- Close the incident.
This is remarkably similar to an Agent Loop.
The major difference is that an AI agent attempts to automate portions of this reasoning and execution process.
32. Final Thoughts
SD-WAN has already changed the way organizations design and operate WAN infrastructure.
The next evolution could be the combination of:
SD-WAN + APIs + Automation + AI Agents
For network engineers, the most important concept is not simply learning how to build an AI agent.
It is learning how to build an agent that operates safely.
Remember the complete loop:
Think → Act → Observe → Reflect → Decide → Repeat or Stop
Then add the production safeguards:
Iteration Limits + Action History + Fallback Strategies + Logging + Guardrails + Human-in-the-Loop
This combination can turn an AI agent from an interesting experiment into a potentially useful network operations assistant.
The future network engineer may not be the person who manually performs every troubleshooting step.
Instead, it may be the engineer who understands:
What should be automated, what should be delegated to AI, what must be validated, and what should always require human approval.
That is where Agentic AI becomes particularly interesting for Cisco SD-WAN and modern network operations.
33. Frequently Asked Questions
What is an Agent Loop in networking?
An Agent Loop is a process where an AI agent investigates a network objective, performs actions, observes results, reflects on the findings, and decides whether to continue or stop.
Can AI troubleshoot Cisco SD-WAN?
AI agents can potentially assist with SD-WAN troubleshooting by collecting operational information, analyzing performance data, identifying patterns, and recommending the next troubleshooting steps.
Can an AI agent automatically change SD-WAN policies?
An agent can potentially be connected to automation interfaces capable of making configuration changes. However, production changes should be protected by authorization, policy controls, validation, and appropriate human approval.
What is Human-in-the-Loop in SD-WAN?
Human-in-the-Loop means that the AI agent pauses and requests an engineer's approval before performing a decision or action that requires human judgment or carries significant operational risk.
What happens if an AI network agent gets stuck?
The agent should detect repeated actions, oscillation, dead ends, or tool failures and either use an approved fallback strategy, escalate to a human, or terminate.
Is Agentic AI the same as network automation?
No. Traditional automation generally follows predefined workflows, while an AI agent can evaluate observations and dynamically determine the next step within its defined boundaries.
34. Related Articles From Netterrene
Generative AI Fundamentals for Beginners
https://netterrene.blogspot.com/2026/06/generative-ai-fundamentals-for-beginners.html
Agentic AI for Network Engineers
https://netterrene.blogspot.com/2026/07/agentic-ai-for-network-engineers-guide.html
Cisco ACI Explained
https://netterrene.blogspot.com/2026/04/cisco-aci-explained-concepts-learning.html
Cisco ACI vPC Explained
https://netterrene.blogspot.com/2026/06/cisco-aci-vpc-explained-architecture_01563772518.html
Cisco ACI Service Graphs
https://netterrene.blogspot.com/2026/05/why-service-graphs-matter-in-cisco-aci.html
Understanding L3Out Subnet Scope Options in Cisco ACI
https://netterrene.blogspot.com/2025/08/l3out-subnet-scope-options-in-cisco-aci.html
