Blogs

AI Network Troubleshooting Agents Built From Your Expertise

Joksan Flores

Principal Solutions Engineer

Last updated November 5, 2026

Summarize this resource

Claude ChatGPT Gemini Grok

Key Takeaways

- Start with a troubleshooting task you understand well.
- Write the investigation steps in the order the agent should follow.
- Provide the source host, destination, inventory, and tools needed to investigate.
- Test the agent, inspect the execution, and improve the instructions.

If you troubleshoot remote sites, you already have a sequence in your head. Start at the host. Check its address and routes. Find the default gateway. Work out whether the problem is local connectivity, reachability beyond the site, or access to one particular destination.

That sequence is valuable material for AI network troubleshooting agents. In our ServiceNow remediation demo, I used the method to guide an agent through an investigation. I gave it an order to follow and tools to gather the evidence.

The work starts with getting your troubleshooting knowledge out of your head and into a process another operator can follow.

Pick a Problem You Know How to Diagnose

For the demo, I chose a straightforward remote site problem: a host could not reach 8.8.8.8. I deliberately added an access control list, or ACL, entry to cause the failure.

Keeping the example simple made the investigation easy to follow and explain during the demo (these agents are capable of very complex troubleshooting). We could watch the agent establish what worked, identify what failed, and use that information to decide where to look next.

That is how I would start building one of these agents. Pick a recurring problem in a site or environment you know. Describe the inputs you need, the checks you normally perform, and what each result tells you.

The scope matters. Remote site connectivity, data center troubleshooting, and cloud connectivity can involve different procedures and tools. In the session, I discussed the option of routing incidents to other specialist agents as those capabilities are added.

Write Down the Investigation Order

I was prescriptive about the sequence. The agent needed to work through the troubleshooting steps in order and avoid repeating completed process steps unnecessarily.

For the remote site investigation, the method included:

Identify the source host and the destination reported in the ticket.
Inspect the host’s network configuration and routes.
Test connectivity to the default gateway and the affected destination.
Investigate the relevant network device and its connectivity beyond the site.
Use the evidence to examine routing, configuration, and policy.
Report the findings and propose a fix with rollback information.

I did not tell the triage agent that the answer was an ACL. I told it to investigate step by step. In this run, it found that the host had network access but could not reach the particular destination, then examined the border device and identified the blocking entry.

That distinction is useful when you write agent instructions: capture the method you use to find a problem, including the observations that change your next step.

Give the Agent the Context You Would Need

The ticket identified the source host, remote site, and destination. Those details let the agent establish where to begin. If someone tells you they cannot reach an IP address, you ask where they are trying from, and an agent needs that context too.

The model’s general networking knowledge does not identify the affected host in your environment.

The platform inventory provided the devices the agent could work with. The underlying connections and secrets integration were already in place, so the agent could use the tools without an engineer manually opening a session to each device.

That is part of preparing the use case. Check that the information and access your troubleshooting process depends on are actually available to the agent.

Match the Tools to the Job

The triage agent had read-only infrastructure tools. It could gather evidence and recommend a change. A separate remediation agent handled the approved configuration.

This gave me a clear boundary while building the investigation. I could focus the triage agent on finding the cause, and then review the proposed change before handing it to an agent with write capability.

The Itential Platform handled the inventory, connections, and tool execution underneath. My work included choosing the tools for each agent, writing its instructions, and arranging the process around the human approval.

You still need to understand what the tools do. If your procedure depends on inspecting a configuration or testing a path from the source host, those capabilities need to be available in the appropriate place.

Use the Execution Trace to Improve the Method

I did some testing before the session. In a few places, I wanted one step to happen before another, so I adjusted the instructions. That is part of designing the agent.

During the demonstration, we could inspect the session and the tool calls. We could see which devices the agent used, the commands it sent, and the results it returned. That made it possible to follow the investigation.

The remediation agent also checked the conditions again before applying the approved change. That is a useful example of operational knowledge becoming a process step. If execution happens later, the original symptom may already have changed.

When you review a run, look at the decisions and the evidence behind them. Did the agent start at the right host? Did it follow the sequence? Was the proposed change supported by what it found? Improve the instructions where the process needs work.

Put Your Expertise Into Improving the Agent

Customers sometimes ask whether agents will take their jobs. The work I want engineers to spend time on is designing, curating, and improving these agents. If you are the expert at troubleshooting remote sites, that expertise is useful in defining the process and judging its results.

💡 AI network troubleshooting agents need your domain knowledge: you know the environment, the exceptions, and the checks that matter.

You can explain why a step belongs before another, then test whether the agent follows the method.

Start with read-only triage for one familiar incident type. Make the findings useful to the next engineer who works the ticket. Once you can review that process confidently, decide what should happen next.

Want to see how I did it. Watch the full webinar I did with John Capobianco here.

Joksan Flores

Joksan Flores is a Principal Solutions Engineer at Itential. Joksan’s passion for putting both systems and software together led him to spend 10 years as a Networking Architect at Cisco prior to Itential. Throughout his career, Joksan has supported enterprises and service providers with massive customer bases to solve their IT challenges, designing cloud peering connectivity, WAN, and data center networks. While helping organizations solve complex network challenges, Joksan has always found ways to leverage automation – either by devising methods to make work more streamlined or by helping customers achieve their project goals faster. Today at Itential, Joksan focuses on advancing infrastructure automation through AI-driven orchestration, helping organizations navigate the journey from experimental AI assistants to autonomous operations.

Keep Learning