Demos

An Incident Opens in ServiceNow. Your FlowAI Agent Already Is Troubleshooting.

Video Notes

(So you can skip ahead, if you want.)

0:00 Introduction
0:45 Agent Design & Rules
1:24 Routing & Troubleshooting Logic
2:05 Why Guardrails Matter – Read-Only Execution
2:28 ServiceNow Configuration
4:05 Triggering the FlowAI Agent
4:37 FlowAI Agent Execution
5:35 Agent Reasoning & Parallel Step Execution
6:19 Root Cause Identification
6:50 Ticket Auto-Updates with Findings
8:20 Extending the Agent Further

In this demo, Principal Solutions Engineer Joksan Flores shows how to build and run a FlowAI agent so that a ServiceNow incident triggers the agent instead of a pager. No NOC engineer has to log in. No one runs show commands by hand or writes up findings. The agent does all of it: diagnostics, root cause analysis, and ticket update.

Built on Itential FlowAI, the troubleshooting agent alerts directly from a ServiceNow incident, executes read-only diagnostic commands against the target device, identifies the root cause (in this demo, a downed IPsec tunnel suppressing a static route), and writes a full troubleshooting report back into the ticket. All without human intervention.

What You’ll See:

1. ServiceNow-Triggered Agent Execution

Configure an entry point that fires directly from a ServiceNow incident without polling or middleware
Pass incident context (device, issue summary, incident number) directly into the agent at runtime
Launch the agent and monitor in real time from the execution view

2. Intelligent, Guardrailed Troubleshooting

Define routing conditions so the agent knows how to reason through various failure scenarios
Restrict the agent to read-only command execution: it triages, it doesn’t touch the config
Watch it run parallel steps: static route diagnostics and ServiceNow incident detail retrieval at the same time

3. Root Cause Analysis Written Automatically

The agent identifies that Tunnel 0 is down, the IPsec negotiation has failed, and the static route is suppressed as a result
It writes a complete troubleshooting report directly into the ServiceNow ticket
Full trace and job visibility retained to ensure auditability

Why This Approach Matters

Tier 1 Triage Without the Ticket Queue

When an incident comes in, someone still has to log in, run the commands, read the output, and write it up. A FlowAI agent handles that first level of triage – consistently, immediately, every time – so your engineers work the problem instead of documenting it.

Guardrails That Make It Production-Safe

Read-only command execution isn’t a limitation, it’s the point. FlowAI lets you define exactly what the agent can and can’t do, so you get the automation without the production risk.

A Platform That Can Go Further

Joksan stops the demo at root cause identification, but the platform doesn’t have to. Add more troubleshooting tooling, attach a knowledge base of runbooks, and the agent goes further, too.

–+

Joksan Flores • 00:01

Hi everyone. Today I am going to demonstrate a quick agent that I designed for ServiceNow incident troubleshooting. So what we’re going to do is we’re going to actually be triggering this agent directly off of ServiceNow using the minimal ServiceNow workflow that essentially triggers a agent entry point that we have created in the itential platform that will launch this agent and essentially we start looking at the definition of this agent the job for this agent is to troubleshoot a specific issue on a target device so we’re gonna communicate a particular device a particular issue say a routing issue or some interface or something like that and there are some rules in here the 1st thing that the agent has to do is extract context from the ticket So, the agent will take in some context from the ticket via ServiceNow , namely, the issue summary from the incident itself. It’s going to be getting the incident details using the incident number and parsing some of that data. It also has some tooling from the attention platform, namely, in here, it only has one command template, which is called static route troubleshooting. And we’re going to simulate that kind of problem today.

Joksan Flores • 01:24

But there are multiple issues that it can actually go and execute, or we could actually add a lot more troubleshooting tooling, or we could just let it use its intelligence to use its capability that it has via the attention platform to execute commands on devices and come up with a conclusion. Then it has to investigate a root cause. So in this case, we’re very focused on routing troubleshooting. So we have some conditions in here saying if the route is present and has a valid next hop, investigate the next hop reachability. If the route is missing from the routing table, investigate the routing protocol state. If the route is missing or present via null or drop, investigate the policy or static route config. So a few conditions in there that it can use.

Joksan Flores • 02:05

Instead of letting the agent just reason through that, we have added some of those conditions. We could actually let the agent just reason through that, right? The LLMs are quite good at this. And then it’s going to assess and update the ServiceNow ticket. So this is almost becoming like a tier one. Troubleshooting agent, right? Incident gets created, somebody reports a problem at a remote office or data center or something like that.

Joksan Flores • 02:28

And instead of going to the knock directly and the knock engineer having to triage a ticket and log into the box and capture outputs and you know make an interpretation off of that, we’re going to use an agent to kind of use that, do that 1st level of troubleshooting on triage. So we have the agent here, we have the 2nd tab, which is going to show us the missions once it gets kicked off. Right now, there’s nothing running. I think everything is completed. We have the entry point configured right here, and that lets me do it via the attention platform. I can configure an entry point very quickly that has that route called incident troubleshooting agent and it just requires requires a context object. That’s it.

Joksan Flores • 03:06

So that’s all we’re requiring for the ServiceNow . A context object that publishes and sends me the incident summary ticket and then some data from the incident. Let’s see. We’re going to go here and we’re going to go and call it a routing reachability issue on route. And I got to go find out what that route is. Let’s go. We have tested this before, so why don’t we just go and look through the older incidents?

Joksan Flores • 03:34

Let’s go back. Okay, so we’re gonna go ahead and create our ticket. We got our ticket number there, which is self-assigned. I’m gonna put the call as my name. Category is network and subcategory. I’m just gonna leave it alone. I don’t have the proper, I mean, I could call it IP address or something.

Joksan Flores • 04:05

And then the short description is what matters here. So I’m gonna hoe and I’m gonna go and I already have something that’s you know pre-described here. I have a routing issue to IP100030/24 on this router. And then I have this itential AI here. Now, this serves as a trigger to tell ServiceNow anything that has this kind of namespace or prefix here, itential AI, will call my itential agent for troubleshooting. This could be configured in many, many, many different ways. This is a very ServiceNow specific thing.

Joksan Flores • 04:37

I have decided to do it this way. I’m sure there’s probably a lot of other ways to do it via, you know, creating some sort of custom object in here or something that says I want to request a particular type of troubleshooting or something like that. So that will create that incident there, and then I will see an entry point here, and I should see my agent being launched. So, we’re going to refresh my Flow AI executions table here in the platform. Let’s go refresh the page now then. Okay, so my incident routing trouble, incident troubleshooting agent is running. I’m gonna go back and look at it here, and we actually get this really nice view that’s live on the agent.

Joksan Flores • 05:35

So we got the agent reasoning here. It says, I’ll start by extracting the key details from the prompt. We got the device, we got the route, we got the prefix. So notice that everything that was done in ServiceNow, right? This ticket that was custom 12601 that has no notes on it whatsoever at the moment. We’ll see that change in a minute. We’ll actually got some of the details as well with the incident number.

Joksan Flores • 05:55

So it’s saying now let me kick off steps two and three in parallel. So it’s done the static route troubleshooting. It’s gotten the ServiceNow incident details as well. And it’s now decided to go ahead and actually supplement the results from the static route troubleshooting, which it got some data there, right? There’s some output from the commanding here. So it’s looking, oh, it found the route right here somewhere. And excellent findings.

Joksan Flores • 06:19

I see critical data static route for 10000/24 access via tunnel zero with this next hop, but the tunnel is down. So it’s actually executing a direct command into the device. Now, notice this is a show command only. So only read-only access to the device, right? So this is what’s really important: having those guardrails added to the agent so that it can’t just go and start, you know, turning things on and turning things off and stuff like that. We’re only having it do triage for us. And while I’ve been talking here, it’s done.

Joksan Flores • 06:50

I now have a complete picture. The root cost is clear. Tonel0 is down due to an IP6 failure. Let me update the ServiceNow incident with all the findings. And they did that, right? It did the update ServiceNow incident. We have all the job tracing, everything with the ACD response.

Joksan Flores • 07:05

And if I go to ServiceNow , I’m going to go and refresh my page with my incident. And 001261. Here we go. Perfect. Look at that. Wow. So, this is really impressive: the amount of stuff that we could do.

Joksan Flores • 07:17

I could actually have it condense this down, but I think this is a good level of detail where it actually shows you the automated troubleshooting report for this ticket. It’s got the device, the route under investigation, the commands executed, show IP static route, show IP route, show interfaces tunnel, operationally down. It’s got the details here. You know, the route is configured, but the route is inactive. And then it’ll give you the actual root cause analysis. The route is unreachable. The route is configured.

Joksan Flores • 07:50

And let me zoom in in here a little bit. The static route is configured with outbound interface tunnel 0 and NextUp 182.168.100.2. However, tunnel 0 is down, which causes the route to be suppressed from the acting routing table. As a result, traffic destined for 100.00.30 has no valid forwarding path. And that’s great. Most probably cause is an IPsec negotiation failure between the local endpoint and the remote peer, pretending, preventing the tunnel from establishing. And it has recommended remediation action.

Joksan Flores • 08:20

Now I controlled it, I told it to stop there. But if I were to say, hey, go and identify what the peer is, go and identify the peer device, because actually the platform has access to both those devices, I could actually have it go further. And even troubleshoot the crypto issue. I didn’t do that. I opted for just keeping it simple, just for the sake of this ticket. But you can imagine the power of this thing, and we could actually make this agent generic by providing it a knowledge base. We’ve done some of this knowledge base experimentation with perhaps attaching a GitLab markdown document with some guidelines on how to troubleshoot and so forth.

Joksan Flores • 08:55

You can imagine the kind of power that an agent like this would have, and it’s pretty amazing. So, pretty cool stuff. That’s all I wanted to show today. We got the whole Flow AI trace and execution of the agent. The design is pretty straightforward. We got the conclusion right here in Flow AI as well with all the jobs and everything. So I got visibility to everything that went on, all the commands, all the outputs, as well as my ticket fully, fully, fully triaged.

Joksan Flores • 09:21

Thanks for tuning in.