AI Agents Are Just Another Tool: How to Integrate With Your Network Automation Strategy

Ethan Banks • 00:00

Welcome to Heavy Networking. If you’ve ever had an argument about whether or not it’s okay to disable Spanning Tree because you’re running a layer 3 fabric, you’ve found your tribe. I’m Ethan Banks. Drew Conry Murray is not here because we’re in Munich today at AutoCon 5, and the set we were provided with only involves two chairs. So that means me and my guest, Chris Wade, CTO and co-founder of Itential. And Chris has been on the show a number of times before, as Itential has been right at the forefront of network automation and orchestration for many years now. And they’ve figured out how artificial intelligence fits into the mix.

Ethan Banks • 00:34

So let me give you a quick take on this. AI has, let’s say it’s complicated network automation for us. So we’ve got these new questions we’re trying to answer as an industry now, such as if AI generates code for me, do I need to learn Python? Should I be writing a script to gather network information if I can dispatch an AI agent to gather that information for me instead? Are there skills that I thought I was going to have to have that I can skip now if AI is going to stand in that gap for me? What other automation tools that maybe I’ve been using for a while? They just don’t matter or maybe they’re obsolete because AI has shown up.

Ethan Banks • 01:13

So we’re going to have that discussion with Chris. Chris and his company, Itential, have been right in the guts of network automation long enough to feel the disruption of AI and distinguish the hype from the reality. And they’ve added AI to the tool mix here. So Chris, welcome back to Heavy Networking. You’ve been on a number of times before over the years. And I want to set up the conversation for us this way. We got to a point with network automation, and we’re here at AutoCon.

Ethan Banks • 01:41

We’re at AutoCon 5 having yet an ongoing conversation about network automation. And a lot of the presentations that have happened at this conference are about: hey, if you’re serious about building a network automation platform for your company, you need a developer. You need someone that’s committed to this. Now it could be a network engineer that’s devoted to the maintenance, the care and feeding, and customization of your network automation platform. Are you going to bring in a developer and make them dedicate them as a resource to your network operations team? Because that’s what it takes. That’s the kind of level of commitment that it takes.

Ethan Banks • 02:20

So some people have made that argument. And then there’s lots of other alternates and ways that you could go. Now we’ve got Agentic AI goes come in. We’ve been talking a lot about it to the point of it frustrating the heck out of some engineers. Can we not talk about this conversation? But it is a decision-impacting technology for folks. So could you explain now that Agentic AI is in your world at Itential, how this changes the whole dedicated developer conversation?

Chris Wade • 02:50

Sure. So I think it’s a natural extension to what we’ve been doing. A lot of people see it as it’s very transformational in what’s possible. But I don’t think it’s a replacement as much as a lot of people think. People are talking about reasoning versus determinism and can agents replace maybe my scripts or the automations I’ve built. The way we think about it is we’re adding reasoning to the stack. So we’ve all been building determinism for years, whether it’s playbooks or scripts or automation components.

Chris Wade • 03:23

And that level of determinism requires us to code all these things, as you say, right? So I need a developer. Maybe I’m running it on Tuesday and I have errors. I have logic. The device is offline. So every time that happens, I have to care and feed for the technical debt that’s associated with my automation. And with reasoning, we can really balance that determinism with reasoning to overcome a lot of these corner cases, a lot of this custom development.

Chris Wade • 03:48

So let’s start there. So it’s really about adding reasoning to the deterministic stuff we’ve been building over time.

Ethan Banks • 03:54

The cynical network engineer would say, artificial intelligence agents, AI agents, don’t reason. That’s not what that means, Chris. What does that actually mean?

Chris Wade • 04:03

So. When we build agents, and a lot of people have their 1st experience with AI with ChatGPT, or, you know, people have used chatbots, right? So we’ve become very accustomed to like, how do I craft my engagement with these with these chatbots to achieve the outcome we want? When we start thinking about building agents, we start building concepts around that so that we have the outcomes we want. So people are used to prompting, right? So we would tell it, you’re going to do a port turnup. This is how you do it.

Chris Wade • 04:31

But we can also give these agents tools. We can also give them access to components. We can give them skills to teach them how to do things. Like when you’re troubleshooting a connection, maybe you ping it, then you trace route it, like we’ve always been doing in the NOC. So it’s really about how we give an ecosystem of tools to these agents so they provide the outcomes that we want. And how we’re really thinking about this and how customers are thinking about it is they really want to have that level of determinism facing the network. And they really want to add this reasoning concept on top so that they can kind of incorporate business processes and how we want to manage infrastructure.

Ethan Banks • 05:08

Okay, you just said a ton of things there that are pretty important. We got to make sure we get back to the determinism point, which has been another point of discussion when invoking AI in these discussions. But let’s back up. So, agentic AI, I can train an agent. You said I can have tools, I can have skills, I can make the agent. I’ve had other conversations with folks about this, and they say, Think of an agent like a junior engineer, and you need to train them on procedures and train them on skills and make them knowledgeable about the network in a specific way so that they are useful, right? Absolutely.

Ethan Banks • 05:49

So, you’re talking about doing that same thing with an agent. So, am I thinking? Is that the right way to think about an agent? Like, it’s, I mean, I think of it as code, but it’s more like conceptually, the way I can apply that technology, it is more like a person that is going to function in a way that I want an engineer to function.

Chris Wade • 06:10

Yeah, so whether it’s a person or not is an interesting topic. I’m giving an analogy. I’m not ascribing sentient personhood to the agent. Sure. But to your point, if I’m going to have a person do a job, let’s talk about it as the job that’s being accomplished. I do want somebody who has some knowledge of the space. And if you think about an agent, it has the power of the LLM, which has been trained off the internet.

Chris Wade • 06:33

I might have procedures. I might have had a method of procedure that when this happens, these are the steps I take. So that I can provide that to the agent to say, hey, when this happens, these are the types I can train them on skills. This is how you do things in the infrastructure. Maybe these are the commands we run or this is how we achieve this outcome. And when you start to surround what people think of that LLM with prompts and skills and tools, you are creating an environment where the outcome is going to be more well known than one might think, right? People think about the agent might just decide to do whatever it wants to do.

Chris Wade • 07:09

But if I give it three tools and it can do a ping and a trace route and something and notify me on Slack, those are the only things it can do, right? So I’m curating that agent for an outcome that I’m asking it to do.

Ethan Banks • 07:24

And by giving it a procedure, like e.g. , like I would have, like we call them runbooks at one of the shops I was at. It was literally a three-ring binder that was a runbook. This is the circumstance. Like, like we had, and they tended to be for big, big events, but we had smaller procedures too, all depending. But like a big runbook would be, we got to flop this particular application over to the other data center. And because reasons it wasn’t fully automated, we had to take some manual steps. And the runbook walked you through how to do it, preparation steps, implementation steps, you know, post-checks, these kinds of things were all in there.

Ethan Banks • 07:58

I can throw a document like that written in plain English for a human to an agent and it knows what that means.

Chris Wade • 08:06

Absolutely. And the question is: like, when you were following those procedures, what happened if maybe something wasn’t in that book?

Ethan Banks • 08:14

Then the person got stuck, usually.

Chris Wade • 08:17

Yeah. Exactly. So, from an agent’s perspective, if I wrote a script to do that, because historically, when we talk about determinism, maybe that’s a word that we need to introduce. But when we write scripts or code to accomplish that, right? If I run a Jenkins pipeline with Python in there and I try to do that, and maybe the device is offline for a few minutes, or maybe I have to reroute to your point through a different network, that script might hard fail. That Jenkin pipelines might fail. So I need to code every one of those corner cases in there.

Chris Wade • 08:43

Whereas if I have a human running the run book, they might think, I’m going to try a 2nd time, or maybe that device, or maybe I’m going to go through this other jump server. They might know enough to try to overcome those blocking issues, right?

Ethan Banks • 08:53

Well, depending on how junior they are. Because I’ve had a mix of that. The good ones would do exactly what you said. I’m going to try three other things because I’m kind of stuck. Others would just be like, I got to step three and it didn’t do the thing. So now what do I do?

Chris Wade • 09:09

And so we’ve been driving towards determinism because that’s what we had, right? So we had pipelines and scripts and infrastructure as code.

Ethan Banks • 09:16

Determinism, keyword. For the same set of inputs, I get a predictable output. I’m going to get the same result.

Chris Wade • 09:21

Idempoten as you go.

Ethan Banks • 09:23

Okay.

Chris Wade • 09:23

Exactly. So the balance of reasoning allows us to let the LLM help us overcome and reason through maybe the challenges in achieving that out. Rather than having to code for every corner case. Exactly. So we’ve had a set of tools that have. Relegated us to coding every exception, right? If we live in perfect standardized environments with clean data, with networks that are never offline, maybe the outcome is very narrow, but most of us live in environments where I have a variety of inputs, I have a variety of data, I have a variety of networks.

Chris Wade • 09:55

Things are changing. So, allowing my scripts and my pipelines to be augmented with that logic allows me to overcome those things. So, imagine in your prompt, you say, Hey, if the device is offline, you know, use a backoff algorithm. If you get these error conditions, these are okay and these are not in plain English, just like I would talk to on a bridge at 2 a.m. for an outage call, right? But then I let this agent help me work through this, right? So, it’s not deciding randomly what to do.

Chris Wade • 10:25

I’ve told it through tools what to do, but it’s helping me work through what we would have normally done on a bridge at two in the morning. And it’s overcoming that so we don’t have to code in each of these corner cases.

Ethan Banks • 10:36

I’m smiling because you’re saying, you know, on a bridge at 2 a.m. And then evoked a memory of being called literally at 2 in the morning. And I was so out of it when my boss is calling to tell me about the problem. I did not respond to his description of the problem in any way. I said to him, Why are we talking right now? That’s all I could manage to get out.

Ethan Banks • 10:56

I was so irritated. Okay, so I’ve got agents that I have with, what’s the right term here? It’s not I wrote a really big prompt to train it, to teach it all that, or is it? Did we just write a large context prompt?

Chris Wade • 11:13

So exactly. So we have a context window that we’re passing to the reasoning step, let’s say, right? So that context could be made up of prompts. Whoever built this agent is telling it how to resolve a thing at two in the morning.

Ethan Banks • 11:26

It’s not a Python script with a bunch of logic in it.

Chris Wade • 11:29

So the context window is not. Now, it might have a tool that is the Python script, right? So the reasoning step is using that context to say, what do I do next? That next thing might be running that Python script. But back to your 2AM example, we’ve all been there. When we get on the bridge, you don’t tell somebody exactly what to do. Generally, like, what’s going on?

Chris Wade • 11:48

Yeah. And you ask a bunch of questions, right? You’re trying to get your own context so you can provide some guidance as a senior engineer of what that person should do. They’ve tried the mock. They’ve tried the runbook. Something’s not good. They call you out.

Chris Wade • 12:03

And your 1st question is, I need context to help provide you guidance. So the agents in a very similar manner, that you’re asking that agent to help you, what is the next step? And it wants context. So the context could be the procedure. The context could be alarms or issues that are happening right now. And selectively deciding. And that’s where it comes to when we’re building these things is how do I provide the appropriate context so that the outcome is something that I like.

Ethan Banks • 12:28

So it is correct to think of the agent in a sense as a human. So when I’m called at two in the morning to because there’s an issue, that is, of course, once I’m awake, that is the thing I begin asking is. Okay, we’ve got an application down condition. I don’t, that is very little context to get to the root cause. Now I need to know, all right, is it gone or is no response or is it slow?

Chris Wade • 12:57

Did you try this? Did you try that?

Ethan Banks • 12:58

Did you try this? Did you try that? What is the nature of the error that we’re seeing? Does it work from this region, but not this region? Are there any alerts on the network management system? Even if you don’t think they’re interesting, anything that’s read, anything that’s come up, give me that, et cetera. It’s an information gathering step.

Ethan Banks • 13:16

I need to understand all of these things. And the agent also needs to know all of the things, but interestingly, can make use of all of that information. In some way. And you see where I’m going with this? If I wrote a Python script, I have to tell it what to do with some set of structured data. I’m going to evaluate the data that comes through and its values and then build logic into the script to know what to do with it. The agent already knows what to do with that information without me telling it, or all of that’s been provided in the context prompt.

Chris Wade • 13:46

So the limitations with your script of coding all those error conditions, long tail issues that could happen is a similar concept with the agent. We have to decide what do we want to provide it for that context, right? And people that have been working in the space understand we have context windows and you do have limits of what context can go into those decision making. Oh, limits. Yeah. So you hear like prompt engineering and context engineering. It kind of comes down to I’m asking it to make a decision.

Chris Wade • 14:14

What information do I want to provide it? And I think that’s kind of thinking through the analogy to the 2 AM brain is interesting, but it’s really about what decisions do we want and what do we want to put in that context window. And these agents are typically referred to as React agents in the sense that they reason and then they act and they reason and they act. And people that use LLM saw maybe with ChatGPT 4.0, it felt like it got slower. But in the background, what it was doing is it’s taking larger requests that we have and it breaks it down into reasoning and act, reasoning, act. And similar to what we need to do in how we’re operating infrastructures, we have to decide what decisions do we want and then what actions do we want to be made on the network, whether it’s paging you out or whether it’s actually modifying the infrastructure to overcome the issue.

Ethan Banks • 15:00

Well, and you mentioned breaking down into smaller steps. So there are. Correct me if I’m wrong here, but you typically don’t have one super agent that does everything. You have a bunch of smaller agents that do individual tasks. You’re the routing agent. You’re really good at that.

Chris Wade • 15:15

Exactly. And that’s where I think the metaphor to humans break down is we really want to think about them as activities that we might want to perform. You might have a notification agent. You might have a change management agent. You might have a port turnup agent. These types of things where, and then it, and then you can break larger problems down into smaller problems that fit into context windows that provide the outcomes you want. And then you’re thinking about how you stitch these together to achieve larger outcomes, which sounds very similar to what we do in pipelines and automation today, right?

Chris Wade • 15:43

We have an orchestrated pipeline, and then I have individual components or individual Python scripts or otherwise that are achieving certain steps along the way.

Ethan Banks • 15:50

So let’s dig into that analogy for a minute. If I’ve got my Jenkins pipeline, I, as a human, have coded that pipeline. Well, not coded, but I mean, I’ve established that pipeline to define what it is and does. It calls a bunch of scripts and there’s a bunch of steps that work through or can break the flow depending on a certain step and so on. With agentic, what does that mean? I’ve got that same thing conceptually, but I’ve got more flexibility depending on the outcome of certain investigations.

Chris Wade • 16:21

So the way we think about it is. We want to put LLMs in the place where they’re really powerful, right? And we can talk about that in a minute. But the question is: do I want the agent to reason the individual steps or do I want it to reason kind of the orchestrated components? And it’s really good at deciding what to do in what order. So, whereas in that pipeline, you might have said, I need these five things to happen in a very strict order, right? It might decide to do one, two, and then do two again because maybe the device was offline.

Chris Wade • 16:51

Maybe I got an error condition and I think I can just achieve it. So, instead of having to code all of that in the pipeline, you can have that agent help reason through getting to the end. And the way I would think about it is, I’ve been thinking about analogies, trying to, I don’t know if this one works, but it’s kind of like you have a recipe and you have ingredients, right? And when you follow a recipe, you have a very strict set of things that you have to do in a certain order to achieve the thing you want to do. With an agent, you can kind of give it the ingredients, tell it the outcome you want, and it’s going to figure out how to put the ingredients to achieve your outcome, which starts to sound a little bit like the intent-based words that we used for a long time, right? So, I can focus on the quality of the Python scripts and the determinism without being so rigid and structured about how you put them together to achieve the outcome.

Ethan Banks • 17:37

But intent-based, if we just jump off of that for a moment, still required a high degree of specificity. I still needed to, it needed to know what a VLAN was and what my intentions were for that VLAN. I still had quite a bit of prescription in there, even if I didn’t say exactly how it needed to get it done. I was quite specific in what it was I wanted to get done. Does that. Does our analogy still hold with that when going back to Agentic?

Chris Wade • 18:10

I think it’s the answer to it. So we’ve tried to do the intent-based thing, which is a powerful concept, right? Maybe I’m less concerned about the vendor implementations. Maybe I have high-level abstractions. So application developers. And how we’ve tried to achieve this is through data models. And we’ve tried to create all these different frameworks for how we achieve intent-based.

Chris Wade • 18:28

We have and did and reinvented the wheel several times. Exactly. But if we can keep going on the Agentic way of operating this, you give it the ingredients, you give it maybe some different configs for different types of infrastructure. It determines what type of infrastructure and which one to apply using its reasoning. So now instead of having to hard code and build these data model structures on top, I can say, in this situation, use this, in this situation, use that. And I think it’s the optimal intent-based way of operating because we can move away from, I add my 3rd vendor, I buy this company, and they have a different way of operating. I have a different, you know, data centers are operating different from my WANs.

Chris Wade • 19:10

But, you know, a port turnup sometimes is a port turnup or a config on a on a router is a certain config.

Ethan Banks • 19:16

You just unlock the key, though, for me. No, actually, keys are used to unlock things. Yes, you just unlock something for me, Chris. So. Multi-vendor has been a thorn in everyone’s side for a long time for everything you said. Everybody’s data model is different. There might be some commonality, some common shared models, open config models, e.g. , but everybody’s models are otherwise largely different.

Ethan Banks • 19:39

As an industry, we blew it once again. We’ve got a history of this problem in multi-vendor. But what you’re saying with Agentech is, oh, you need the map to deal with this Arista box instead of this Juniper box. Here’s how you do it. And you can point it at what documentation that’s going to make it knowledgeable about that.

Chris Wade • 20:02

So this is where. Some of people in engineering and operations get concerned in the sense that I don’t think we have got to the point where the LLMs are good at building the actual config themselves. And maybe we talk a lot for a minute. So, obviously, the LLMs have been trained off the internet, and there’s all sorts of vendor-specific information. You brought up some vendors there that is defined in their code base, defined in their tech tickets, defined in their best practices that wasn’t made available to the LLMs, right? So, when we think about we want to use this reasoning where it’s really good, right? So, it’s really good at RFCs because, guess what, RFC?

Chris Wade • 20:41

Well-defined, structured design documents.

Ethan Banks • 20:44

Annoyingly so. Yes. Yeah, the machines love it, though.

Chris Wade • 20:48

The machines love it, right? Absolutely. So, if you want to ask it to speak BGP or OSPF, very good. It’s very good in the generic. It understands what a software upgrade is. It understands what a port turnup because there’s a lot of information on the internet, but specific versions, specific operating systems, specific map configs, as you say, less so. So, that’s where this balance of determinism reasoning really comes in and where people start to get uncomfortable is when we rotate so much that it’s not good at, and if you test it out, and that’s where people get uncomfortable with some of the AI concepts because they test it out, build me a config for this, build me a config for that.

Chris Wade • 21:23

And maybe it’s maybe it’s less good at those things because of the reasons I’m saying. So, we can still build those configs. We can still build the ingredients, but when to apply them, how to apply them is really the balance we’re looking for, which is the combination of these two concepts.

Ethan Banks • 21:39

In the problem you just described, where a certain model might not be so good in specific situations because its training data was poor, poor quality. That’s right. We’re talking about what if we had a custom model then that we did train on our specific knowledge domain that we cared about. Does that help us much in that? And I don’t want to get too straight, too far from the reasoning component because you’re making a point there. But this is, I think, an important rabbit trail to go down for that.

Chris Wade • 22:08

I mean, to poke on equipment providers, they’re going to need to provide that, right? And whether they provide it through an agent that we interface with or whether they provide small language models that encode those things is yet to be seen. But I think as a group of people focused on operating infrastructure, we need to expect those vendors to provide that information. I don’t think we’re going to see that from the frontier models. So it kind of comes back to we are still writing deterministic scripts and code specific to the configuration. And when we balance these things, that really achieves the outcome where we can adopt agentic concepts without putting it in a position to be less successful.

Ethan Banks • 22:47

So it gives us a layer that allows us to be flexible in our automation and orchestration. And handle certain unanticipated circumstances that otherwise we would have had to have written specific code to deal with. And every time we ran into that specific situation, we’d be gone, okay, yeah, gotta write a module to cope with that specific situation. Now we should be able to have an agent reason their way through that situation and just go with it.

Chris Wade • 23:18

Exactly.

Ethan Banks • 23:19

Okay. Okay. So let’s talk about itential-specific implementation of this. I want to dig into this. When I think of you guys, I think of a few things, I guess, but the big one is orchestration. I can, if I’ve already got an investment in network automation, my own Python scripts, Ansible playbooks, and so on, I can bring them to the party, to the itential party. As an orchestrator, you’re going to allow me to use and reuse those.

Ethan Banks • 23:46

I’m going to be able to build workflows around that work that I’ve already done and then add new ones. You can read and open up APIs for me and tell me all those things that all the actions that you can take against a specific device based on discovery of that and so on. So 1st of all, it confirms that I have that picture about right. And then anything else you want to add, and then they’ll fit Agentic AI into the Itential product set.

Chris Wade • 24:15

Yep. So previous times we’ve spoken, we talked about the separation of automation and orchestration and bringing up the orchestration concepts, similar to the Jenkins pipeline and Python scripts we were just talking about. So we have atomic automation components. And because we had tools that were deterministic, we were trying to build the best environment to tie these things together and achieve the outcomes with all the constraints we’ve talked about today, right, with air conditions and retry logic. And now with this new technology available to us, we were introducing our Flow AI product, which is this reasoning component in the same platform that we know and love so that we can balance kind of that deterministic concept with reasoning. So just like the challenges we’re talking about today, the question is, how do we introduce this reasoning concept in a governed way so that we can balance the two concepts and achieve the use cases and the outcomes that we’re talking about with the least amount of technical debt possible?

Ethan Banks • 25:14

So, okay, if I’ve been using Itential, I’ve got orchestration that I’m familiar with, my workflows. Now I’ve got Flow AI that you’ve added to the product. So what changes in my interaction with the Itential platform?

Chris Wade • 25:26

Sure. So when I spoke, we’ve spoken on previous episodes, we talked about the separation of automation and orchestration. So none of that changes. We still think deterministic is a key component of how we’re going to achieve automating our operations and outcomes.

Ethan Banks • 25:41

I know I say it almost every show when we say the word deterministic determinism, but the idea of for a specific set of inputs, I get the same output every time. Is that what you’re referring to? Okay.

Chris Wade • 25:49

Exactly. So we still think that’s a critical component for how we want to operate.

Ethan Banks • 25:54

Yeah, I don’t want my network automation solution to feel its way to an answer. I need to be able to have a trustworthy answer.

Chris Wade • 26:01

Exactly. But. With all the stuff we talked about, now we’re introducing the concept of agents running in the platform. So, just like you would maybe run orchestrated events to run a pipeline, now we’re running these agents in the platform. So, we’ve built an agent harness in the platform so we can balance both the reasoning and deterministic requirements that our customers have. And because we’ve hooked into all these platforms, now you have the tools and the skills built into the platform so that these agents can have successful outcomes.

Ethan Banks • 26:31

You said agent harness. Can we define that? I work on cars for spare time because I’m weird. And there’s wiring harnesses that there’s pins and pinouts, and it tells me, oh, it reads a whole bunch of things. And if I plug into that harness, I know exactly what is it that kind of a concept with an agent harness? What do you mean by that?

Chris Wade • 26:48

Well, I don’t work on cars, so I don’t know how that works. But as far as agent harness goes, you know, we’ve all used chat chat interfaces, right? So, when we tell these agents we want to achieve some outcome, something is gathering the prompts, gathering the tools, putting it in the context window, engaging with the LLM. So, just like you would think we have a workflow engine that’s running all these orchestrated workflows, we have an agent harness that runs these agents.

Ethan Banks • 27:13

Okay, so it’s more like kind of a dispatcher. I need you to do this and you to do this and you to do this. And is it going to gather all of the data that is returned and do something with it?

Chris Wade • 27:25

So when we build those React agents, we’re reasoning and acting, reasoning and acting. So it’s basically walking it through that. So the LLM, just like we engage with ChatGPT or Claude, you ask it a question and you get a response. So it’s managing the interaction through your prompts to get you from the beginning to the end. Just like we talked about, the pipelines are going from the beginning to the end. The agent harness and the agent definition is walking through that reasoning and action steps until I achieve my outcome. But because this agent harness is living within the Itential platform, all of the governance that we’ve talked about for years now becomes even more important.

Chris Wade • 28:02

So when people start running agents, they want to understand how do I authenticate? How do I log in, audit? How do I know what it’s doing? How do I stop it if it’s doing something I don’t want? So that becomes a critical piece to people getting the confidence and trust that they can run agents at scale like we’re talking about.

Ethan Banks • 28:19

I want to understand where the agent ends and the human begins, or maybe the other way around. So if I’m interacting with Flow AI via some sort of a prompt, how much autonomy does an agent have once I’ve kicked off a process with that prompt?

Chris Wade • 28:36

So just like you can run a workflow from an API call or a form, or maybe you kick it off from ServiceNow, or maybe you kick it off from your Slack interface, you can interact with these agents in the same way. So back to the 2AM example, if you get an alarm or need to check on a device health or an application team has said they’re having issues, if you have an agent that maps to that request, then that agent is going to work through that React cycle we talked about to try to achieve that outcome. So it is autonomous in the sense that it’s going to run without you sitting there and interactively talking with it. But you’ve built and defined it ahead of time, just like you would with a workflow or a Jenkins pipeline. The massive improvement is now you have that reasoning logic in there. So it’s going to try to reason to the end versus hard fail and call you out.

Ethan Banks • 29:27

When it gets to the end, does it just give me the results? And here’s a bunch of information I found. What would you like to do now? Or does it take actions based on what it found out?

Chris Wade • 29:40

So, because Itential is plugged into all these tools and components in your environment, they might be plugged into your Ansible playbooks, your Python scripts, your controllers, your data center, your cloud. You can build these agents to do anything, the tools that you give it access to. So, if you give it a read-only type of concept, let’s say you’re working in the NOC, like we talked about earlier, and you’re saying, I want to build agents that don’t actually change my config. If you only give it read-only tools, it can only have read-only outcomes. So, its job might be to collect data. Put it in a ticket and call you out because that maybe is the design pattern you want. But if you want it to reroute traffic, if you want to provision a new circuit, as long as the tools and the infrastructure are there to do that, that agent can achieve that outcome for you as well.

Ethan Banks • 30:28

Having a minor freak out internally because the thing I hadn’t thought about with this and Itential is the fact that you guys as Itential are, in a sense, a master key to all of these other network devices that are on the network. You are the center point that knows exactly how to talk to all the APIs and so on to accomplish a given task. And you’ve probably baked all those tasks in if you’ve been using itential for a while. You got a bunch of workflows, you got a bunch of processes that are able to deliver a specific network configuration that does a business outcome for you, whatever it is that you need. You’ve been using it for that. Now you’re saying with Agentic, it’s got all of the capability that everybody out there that’s been talking about Agentic has been talking about, but it’s in the Itential context that already knows everything that’s going on in your network and has got workflows baked in that can accomplish a lot of things. And so when you want the agent based on the information it just gathered through that, its reasoning processes to take a particular action, it’s fairly easy for it to take that action because it’s sitting on the platform that can do it.

Chris Wade • 31:35

100%. Okay. So this is so just to maybe quell your concern a little bit. So, you know, a lot of listeners have probably played or read about like open claw type of agents, right?

Ethan Banks • 31:47

I have had it open in a tab and said, I can’t. It looks so cool, but I just can’t.

Chris Wade • 31:53

So, so it’s just like people have had their chatGPT experience, people have either had their claw experience or read about a claw experience.

Ethan Banks • 32:00

I’m too scared to give claw access to all the things. You need a Mac Mini so you can do it on a screen. Yes, exactly.

Chris Wade • 32:06

So the difference is. When you have a claw type of agent running, it picks tools at runtime. So, what I mean by that is you ask it to do something and it decides how it’s going to happen. You read about it like listening to emails or Discord or Slack, and then deciding amongst the hundred things it can do, it starts sending emails and doing things, which makes people very uncomfortable, right? So, we’ve taken the approach that we need to pick tools at build time. Okay. So, what that means is whoever’s designing this agent, whoever’s building this agent, just like when you write a playbook or a script or you’re writing a workflow in itential, you decide ahead of time what it has access to.

Chris Wade • 32:42

And when people ask it to run, those are the only things it can do. So, in your example, itential might be connected to lots of critical infrastructure. Everything. Yes, but at build time, you decide what that agent has access to. And again, if you want to give it only read-only access, you can only have read-only outcomes. If you don’t let it talk to your big ITP controller, it can’t do that, right? Whereas the analogy before is it could pick tools at runtime.

Ethan Banks • 33:09

So, my minor freakout was not, it’s too powerful. It was like, oh, that just, that’s good. I can make it do all the things. And I was assuming governance because again, with you guys in your context, governance has been part of the Itential platform for a very long time now.

Chris Wade • 33:26

Exactly.

Ethan Banks • 33:27

So, I’m assuming that, and what you just said that that’s the case, I am not giving my agents free-for-all. I have governance that is limiting what access they have, in what context that they run, whether it’s read-only or not. But no, where I was going was it just dawned on me that a Gentic. I don’t need to have some other big complex library of things off to the side because I’m building my own custom thing to enable the agent to take these actions and do things if I do want it to act autonomously to mitigate a particular situation or whatever it might be. It’s already there. It’s already on the platform that the agent, the platform of Itential, has those capabilities baked in. And now I, so I can safely introduce autonomy to my network, have the agents act autonomously, and again, do it safely and without having to code the specific procedures to make all those things happen because I probably have that baked into the platform already.

Ethan Banks • 34:32

That’s more where I was going.

Chris Wade • 34:34

That’s right. And when I talk to most people, they think of it as a fork in the road. Am I going to do it the deterministic way or am I going to build agents? And the reality is most of the Agentic platforms are fairly new in their cycle, right? So a lot of the concerns people have will be baked in over the coming years. But that’s why we chose to put it in the governed platform we have today so you can have the balance of the two and apply it. The same port turnup or different use cases with different customer environments with different networks require a different balance.

Chris Wade • 35:06

And that’s really the goal.

Ethan Banks • 35:09

And there’s a start small capability. This isn’t an all-or-nothing thing, obviously. Now we’re in a situation where you can start with information gathering, as we’ve said, the read-only kinds of context, get comfortable, get used to this, and then iterate and approve where you need to, and then begin to delegate actual autonomy to agents for limited tasks that do things, and it’s all auditable and so on. And we can grow. We can grow agents with us as trust grows and as the robustness of the system grows so that we can can delegate more and more to the agents in a way that we are comfortable with over time.

Chris Wade • 35:54

So I start to have deja vu from our previous conversations when we talked about automation. I think, you know, if we circle back 10 years ago, it was a very similar concept, right? So when we started with automation, it was, I need lots of, we didn’t call it at the time, human in the loop, right? I need, I need a human to review every config before the script or Ansible pushes it to the network. I need lots of checks and balances, you know, so I feel like we’re in the same kind of operational. Style here where we got through the automation cycle to the point where most automation runs as a pipeline, infrastructure as code. Nobody’s, well, I want to say nobody, but very rarely is somebody interjecting themselves unless there’s a concern, right?

Chris Wade • 36:38

It runs autonomously and lets me know how it happens. And we had to go through that entire trust and confidence cycle with automation. I think today most people feel pretty confident if they run the test and they test in their dev environment and they use Container Lab, that the outcome is going to be what they thought it would be. And now we’re kind of resetting, I don’t want to say back to square one, but through the AI concepts, we’re kind of going back to the beginning. And I think we’re going to have a similar adoption cycle where we want read-only, we want diff sets, we want even in the loop. And then as we get trust and confidence, to your point, we’re going to let it run more autonomously. And we’ll probably migrate more deterministic logic into reasoning once we get more confidence that the logic holds.

Chris Wade • 37:14

So we have less technical debt.

Ethan Banks • 37:15

Yeah, and I think that’s the same problem set now as we had, I don’t know, five, 10 years ago with. With network automation and scripting with that approach, we don’t know what we don’t know when the blast radius is high. Exactly. I’m scared. I don’t want to, I’m not ready to trust this thing until I’ve gone through a whole lot of time and tests and iterations to get that confidence. And we are starting over again. AI is now this thing that a lot of us don’t understand the guts of it, how it works, how it does what it does, how it makes its decisions.

Ethan Banks • 37:51

We know it doesn’t actually think or make decisions. What’s actually going on? When they say reasoning, what do they mean? That’s stupid. I hated that they say that, you know, and so on. And then getting to a point of like, It’s fine.

Ethan Banks • 38:03

Agentic AI is here to stay. What does that mean? How do I use it? Do I have to buy a thing? Can I do it myself? How does it actually work? How do I make it so that I can trust it?

Ethan Banks • 38:11

And we get there eventually because the backdrop is still the blast radius is high. And we’re not going to trust an AI agent to do anything for us in our behalf until we have a very high degree of confidence that we can trust it to do the thing. As we have all been working through our early, very early exposure to LLMs, ChatGPT and whatever else, I use Google Gemini. We know it makes mistakes because we put a prompt in, even a fairly articulate and detailed prompt, and we’ll get things that are mostly right, but wrong in some important detail. And that does also color our thinking as engineers. You want me to apply this sort of technology to my network? Yeah, I’m not going to do that.

Ethan Banks • 38:53

It’s clearly not fully baked yet. It’s fine if I want to ask it for a recipe on how to make a chocolate cake. I’m not going to talk about it about how to change my BGP infrastructure. So I guess I don’t know if there’s a question here, Chris. I’m just agreeing with you that yes, in some ways we are starting over again. So maybe the question is, you guys have added flow AI to your product. Obviously, you’ve done enough testing to get to the point where it’s like, well, you trusted enough to add this capability.

Ethan Banks • 39:22

And how did you get to that point?

Chris Wade • 39:25

I like to think about it as a new tool and a new technology that we’re trying to take advantage of, right? So we’re not turning over our future to this LLM that has unknown outcomes.

Ethan Banks • 39:37

Flow AI didn’t replace the other capabilities that Idential’s had for a long time.

Chris Wade • 39:41

Exactly. And I think in our automation industry, and a lot of industries are trying to figure out how to leverage AI, and it feels kind of bolt-on. It feels like in certain industries, why are we doing this? To me, this is a natural extension and a tool and a technology that really accelerates all the outcomes we’ve been looking for. But it’s still a tool and a technology. We need to, I think, view it through that lens. So the question is, in your environment with your stack, how can you take advantage of this and advance the ball?

Chris Wade • 40:11

We’re not relegating, we’re not delegating, but it’s a powerful tool that fills a gap that we’ve had as an industry. We’ve been trying to create some level of intelligence through a number of technologies over the years, with many, many very smart people coming up with articulate answers with the toolkit they had, right? But the toolkit’s changed. And I think we should really think deeply about how we can take advantage of this to achieve the outcomes we’re looking for.

Ethan Banks • 40:42

One of the, as I’ve been having more of these agentic AI-related conversations, one of the themes that’s come to me is: oh, I don’t have to rely on a new Yang model that I can leverage in my code to get to this capability when there were other ways to do it before, if only I knew the exact config sequence or whatever it was to get that task done. I don’t have to rely on a data model to describe it for me so that I can more programmatically deal with it effectively. AI and the ability to train a model to understand these things feels like the magic that obviates those concerns. I’m not endlessly looking at new models, data models to accomplish this. I can still use them, they’re still helpful. Maybe I even use them to train the AI in some cases, but there are other ways I can train the AI to get that stuff done. And I can start worrying more about the overall process and what the task I’m trying to achieve rather than every little implementation detail along the way, because I can delegate that responsibility off to the agent by training it appropriately.

Ethan Banks • 41:53

Does that feel right?

Chris Wade • 41:54

100%. We want to put the reasoning and the LLM in a position where you can use the tool and it will be successful. We could start talking about all sorts of tools. If I take a cloud tool and try to apply it to networking, we’ve all had work with our CloudOps team and maybe it doesn’t fit. These, you know, different technologies and DSLs we’ve invented over time are built to achieve a certain outcome and support that. And this needs to be in our toolkit just like anything else. It’s just so powerful that it creates different dynamics in how we think about it.

Chris Wade • 42:23

And a lot of the human-related metaphors continue to drive that. But if we, you know, it’s just because we’re trying to rationalize how this thing works. But if we can put it in that bucket and say, hey, I need to add this tool to my toolkit in whatever way makes sense so that I can achieve better outcomes for either myself or the company I work for, that’s going to get us there.

Ethan Banks • 42:45

I think in some future conversations, we’ll have to see how this is developing, where it’s going to make sense to stick with a traditional script and a workflow and versus where it’s like, ah, we delegated that off to Agentic and it made better sense that way.

Chris Wade • 42:58

Exactly. Who knows what we’ll look like a year from now?

Ethan Banks • 43:00

Yeah, but you’re not wrong in the tool. It’s a tool. It’s a tool in your toolkit. It’s something to add. It doesn’t necessarily replace anything else. Those tools that we have today are important and they matter. They still matter.

Ethan Banks • 43:11

We’ll continue to matter. But Agentic gives us a whole new set of capabilities and solves certain problems for us and makes certain of these. Difficult challenges we’ve had go away in the context of we can now train an agent to do those things for us with that knowledge. Okay, so Flow AI is an announcement. Was it forward-looking or is this available for everybody today?

Chris Wade • 43:37

So, we did a preview program for the past seven months working with a handful of our customers, which was super exciting.

Ethan Banks • 43:43

And this is June 2026 that we’re recording this, in case people listen to it at it, but okay.

Chris Wade • 43:47

Sure. And we’re going GA July 1st.

Ethan Banks • 43:50

So, okay.

Chris Wade • 43:51

We’re very excited about that.

Ethan Banks • 43:52

Okay. You know, GA July 1st. And so, for folks that want to dig into Flow AI more and understand what’s going on with Flow AI and itential, itential.com.

Chris Wade • 44:03

iTential.com. Reach out to me on LinkedIn.

Ethan Banks • 44:06

Chris Wade on LinkedIn. Yeah.

Chris Wade • 44:08

Exactly.

Ethan Banks • 44:09

Yeah. You get a lot of DMs, Chris. I do. So, okay, Chris Wade, CTO and co-founder at iTential. I got that right, right? For sure. For sure.

Ethan Banks • 44:17

Okay. Thanks for coming back to Heavy Networking. And I’m sure we’ll have more conversations in the future. Always a pleasure. And dude, we’ve been recording these for a few years now. It’s wild how much the conversation has stayed the same but changed. You can track how network automation orchestration has progressed over our conversations that we’ve had over the last several years.

Ethan Banks • 44:37

It’s really interesting. Oh, enjoy it all, as always. And then thanks to you for listening to Heavy Networking today. If you pay attention because of this episode, please let them know that you heard about them on Packet Pushers. Our sponsors are how we feed our families. And you telling a sponsor that you heard them here means we get to feed our families not only today, but tomorrow too. I’ve been Ethan Banks.

Ethan Banks • 44:57

We recorded this show with Chris in person at the AutoCon 5 conference. And if you’d like to attend AutoCon 6 in the fall of 2026, check out networkautomation.forum. That event is going to be held in the U.S. somewhere, location to be announced at the time that we are recording this. So once again, that’s networkautomation.forum. And since you fired up a browser to check out NAF, open a 2nd browser tab and visit packetbushers.net, where you can see our entire lineup of podcasts for your professional career development, along with newsletters, our YouTube channel, resource pages, and more. It’s all free and privacy-respecting as we can possibly make it.

Ethan Banks • 45:29

No login required, no trackers. Last but not least, just remember, too much networking would never be enough.