NautobotGPT: An AI Assistant for Network Automation

Welcome to the Network Automation Nerds podcast where we explore the latest network automation from a practitioner's perspective. I'm your host Eric Chou, a network engineer who loves everything about network automation. We talked a lot about network automation on the show. The challenges we face in learning, coding, tooling, and upscaling can sometimes feel really overwhelming. I get that. But imagine having a network automation pal with you 24/7 with whom you can ask questions, get recommendations for tooling, get real working code, all with empathetic voice. This pal does not get tired and is always there when you need it the most. Today we'll discuss the recently announced NautobotGPT, an AI tool like a Swiss Army knife that accesses the network automation pal that we just talked about and seems to have the promise to make engineers feel like they have a cape on. Joining us today are two incredible guests, Matthew Schwen, associate director of network automation at Humana, also the co-founder and CTO of PortalCX, who has had some firsthand experience using NautobotGPT and Brad Haas, VP of professional services at Network to Code, who So welcome to the show Matthew and Brad. I'm very excited to talk about the tool that we have heard so much about.

Hey, it's great to be here, Eric.

Yeah. So Matthew, can you tell us a little bit about yourself because your title is multifaceted and I imagine there's a good story behind there. Maybe we should start with how to pronounce your last name because I don't think I did a good job there.

It's okay. It's Schwenn. You were very close. I'd give you an A for effort. Yes, and just a little bit of background. My recent projects I've done have been at Humana as associate director of network automation engineering and our goals were to implement a shared source of truth, which would be the foundation for all of our automation and had an opportunity to use a NautobotGPT there. I did. do a startup as well prior to doing Humana I kind of stretched in like I'm stepping away from that startup right now, but gave me a lot of good experience tying. I've been network engineer for most of my career. So, you know, switching over like 10 or so years ago to learn coding and getting to this point where I'm at. Yeah. It's been a great experience. Also working with the NTC guys for a very long time.

Yeah. How long was that? So when did you start? You said 10 years ago that you start doing this automation and source of truth. So how long have you been working with NTC?

Yeah. Well, I mean, like when Jason just started NTC, I was doing a lot of network automation and he reached out to me and I missed his message. Unfortunately, who knows, I might have joined them a long time ago, but I worked on a lot of open source projects. and all like trying to contribute to like Netmiko and NAPALM. When I worked for Adobe, I had access to a larger infrastructure that Adobe was supporting me on building network automation tools. And I was able to attest across a large amount of infrastructure. And that's kind of what got me into it. Oh, wow. And use NetBox for a very long time. I was very impressed with Nautobot and the recent project we did at Humana was very large. Humana is a large company. And those are your Fortune 100 company and lots of different organizations. My project was kind of just to bring everybody together.

Yeah. So in your own opinion, in your own words, what do you think it's the difference between NetBox and Nautobot? Because obviously you started with NetBox and now you're switching Nautobot. So what is that driving force that make that decision for you?

My primary motivating factor for going with Nautobot is to NetBox besides just having a database of source of truth information. A lot of the way I want to integrate the source of truth into automation, use it as a single platform, like network to code pretty much like you'd say have an idea to do something. It's likely that network to code has already worked on that or knows how to implement it. And that's what primary use cases. I don't want to recreate a bunch of things. And I wrote down a list of things that I wanted to do and Nautobot it. had ability to do almost every single one of them. So it was like, it makes sense for me to go with that fork versus staying with the public roadmap, mainly because human is massive, right? It's a huge organization. And I also needed to partner with somebody that could help us out long-term as we scaled the product. And NTC ended up becoming just a great partner for that. It matched the goals that I set for the project.

Almost like you're just thinking about how do we do AI and ChatGPT in Nautobot and now there's NautobotGPT. It's like, Hey, you know, surprise. We've been working on it for six months. That's awesome. So Brad, you know, if somebody stops you on the street, hands you a mic, say, Hey, you know, Brad, who are you? How did you get here? Summarize your background in two minutes. I know it's hard, but do you want to give it a shot?

I will do my best. Yeah. You know, I've been in the networking industry for 25 years. Got my start working as a network engineer, network manager, and then moved over to a reseller right after that and did a lot of professional services, moved into professional services leadership. And then of course there's lots of opportunity to optimize things. And the best way to optimize things is to automate it. So I kind of get an early start into network automation probably in around 2008, where we started automating documentation first, right? Like automated documentation and building design documents from spreadsheets and things like that. and then quickly realized how much more powerful it is once you actually start automating configurations. And, you know, that's where it all began. Now I lead the professional services division at Network to Code. It's a privilege. There's a lot of brilliant engineers over here and it's exciting every day. And I get to see across all of our customers what everybody's doing. So it's a unique perspective and I really enjoy it. Prior to that, actually I was over at Aruba on the Aruba Central team working on their AI ops feature set in product management too.

So you're almost making a sort of a loop back, right? Because you were working on AI, you know, before open AI and they actually, you know, just kind of spoil a little bit. They'd release the feature after you left, right? So I remember you talking about.

Yeah. The newer Aruba Central was, you know, the platform that my team was helping to develop the features for. It was very exciting.

Yeah, I remember that. And you know, it's just kind of interesting to see the cycle where you start development and it's just like people don't understand if they're not in the product development that it takes a long time. I mean, it is software products, so we don't have to have any manufacturing process, but it does take, you know, planning, debugging, releasing beta and then regression and all of these, right? And then before you could release it and all of that. So yeah, it's a long process. And of course, Brad, I mean, we don't have video. I hope one day we will, but I do have to ask about the musical instrument on your back. So care to share a little bit because you know why that wasn't intriguing to me because Larry Wall, who invented Perl, was a musician and Guido van Rossum, who invented Python, was a mathematician. And when I was in their language summit, I do hear the difference. I do hear the opinionated and that goes into language design. Right. So let's talk about your musician background a little bit.

Oh, that's funny. I was a professional musician right out of college, all through college. I was in a band called Foxtrot Zulu. And we recorded five albums for in the studio, one live. We had a top 10 hit in Lithuania radio station.

So you can't walk on the street. You're not normal people walking on the street at Lithuania.

Yeah, I don't get recognized unless I'm in Lithuania. We had a song on MTV Real World way back in the day.

Oh, wow. Okay. Which season? Is this season two? Because that's the only season I watched.

I think it was season two, but I looked back and I was trying to remember it. And it might've been like little later. It was, it was actually the Seattle edition. So whatever season that first Seattle was back in the late nineties, but yeah, it was a good time. So lots of great stories for that.

Yeah, so that goes into your background and maybe someday you would play some tune for us, but not today because today is all about NautobotGPT. And I want to get a user's perspective on NautobotGPT first. And so obviously AI is hot and just judging by the growth that everyone else must have had some interaction and experience with, say, ChatGPT. or other AI tools to begin with, right? So Matt, I wanted to ask you about what was your first impression when you thought, hey, I'm gonna beta test NautobotGPT. So what was your first impression and has it changed after you start testing it?

Yeah, absolutely. Kind of discovered the benefits after I started using it, not before because I mean, I'm a big user of AI. I worked for the trade desk for 40 years as well before I joined Humana, which is an AI company. Well, it's a digital marketing sort of like DSP space, but really heavily around predicting behavior, predicting things with humans and predictions with AI are awesome. And when I first started using NautobotGPT, my first instinct, and I think a lot of… You're just this, well, I use ChatGPT, you know, to help me out. So what's the difference? Why can't I just point ChatGPT to their API and just ask, say, but the main difference for me is the data. I mean, you can feed ChatGPT as much data as it's allowing you to feed it and then have it continuously learn. But a source of truth system has a lot of data in it that is customized to you as well. So And I'm sure with anybody who's used the source of truth, you end up adding maybe custom things to your workflow. Everyone has a different workflow. But what we're able to do is, NautobotGPT is costly, has access to all of the data that I put in there for our infrastructure. So I can correlate multiple tables in the API using NautobotGPT. using just a prompt that correlates with our data that we've privately added in there. And so that's huge time saver for us. And as a network automation engineer, a lot of what we do is just stitching data together and presenting it in a way that makes sense for engineers or systems. And so not having to really do that manually anymore. is you.

Yeah, that makes sense because like you said, you could append the documentation, you know, later versions of ChatGPT, you could actually upload documents and you can make it a kind of RAG system of your own. But why do that? If somebody already spent the time doing it and even kind of pre-planned a lot of the internal documentation that save you some tokens, right? So like why even do it and leveraging other people's effort? I think that makes a lot of sense. Do you have anything to add to that, Brad?

Yeah. I mean, there's two main use cases that NautobotGPT is solving for, you know, one is the, you know, the data aspect of things that Matt just did mentioned, you know, reaching into Nautobot and understanding what's in there and being able to ask like in human language, like, Hey, can you tell me, what circuit is at the Houston location? what interface it's connected to and what device it's plugged into and what rack slot and like all these things that are pieces of metadata about the network, but aren't necessarily things that are in the configuration. So you combine that source of truth with the ability to ask natural language questions now and it's huge. And you know, we've had chat ops for quite a while, right? With slash commands and being able to do things that way, but the whole natural language aspect of things. I think as a human being, you know, my first experience using computers when I was a kid, that's what I thought computers were supposed to do from the get go. So, you know, kind of mentioned like, it feels like a loop back. I feel like what it was like when I was a kid, when I first experienced a computer, you know, we got the first computer with a keyboard in it and we wanted to make a video game. You know, we typed into the computer for like five hours that day. trying to make a video game using natural language and we hit enter and we got, you know, syntax error and, you know, five hours worth of time wasted, but it was a learning experience. Like computers back then didn't take in natural language as input. You had to have a programming language. So that was an early lesson learned in my childhood. So that's the exciting use case of NautobotGPT. But the other piece of it is it can help you code and write automation. So you can actually ask it questions and we have a knowledge base of information from the 100 plus engineers here at Network to Code that have all collaborated and introduced to the system. So it has knowledge that the public LLMs don't. And that's really the differentiator why it is able to do what it can do. And in addition to that, we're actually building internal tooling now, which is, is going to make the responses even more powerful because we're moving into an an agentic approach, which Matt hasn't actually seen in the version that he had deployed with Humana yet. But now we're having teams of agents that are able to one write the code, but also review the code too. So it's like a feedback loop that we're building into the system. So a lot of really cool stuff.

Yeah. I think that actually signal a very important piece of the benefit. You know, when I hire a plumber and he comes in and he spent five minutes and fixed my problem, right? And I pay him hundreds of dollars, at least in the US, they're very expensive. So am I paying that hundred dollars for that five minutes of work? No, right? Like I'm actually paying for his 10 years of experience that that's how he was able to fix in five minutes. So when you subscribe to any professional services for that matter and made by extension, NautobotGPT, that you're paying the money for all that experience that accumulated knowledge tribal knowledge. All that, you know, so I think that's part of the point that you made, right Brad?

Yeah. Yeah. And if you think about it, these public large language models like Gemini, Claude, ChatGPT, they're training on the knowledge that's accessible to them, right. And organizations throughout the world, that's just a tip of an iceberg. What's publicly available. All of these organizations around the world have mountains of data underneath. the tip and that's really what we're doing is we're trying to take advantage of what we have to make the products better.

Yeah, I think it was over in AI as in 2025 by Sequoia that they're actually talking about the running out of data to train right like it's amazing. I like think about how long we have accumulated all these data on the internet, digitizing books, podcasts and your YouTube video and transcribing them into text. And now they're running out of it. And therefore, when they do physical AI, they actually have to use simulation, they have to start using that but That's a great point. There's so much more data that are relevant to you. I don't care about what ABC companies doing. I care about my company and that has accessibility. So I want to ask one more question before we return to Matt on, you know, kind of his workflow process. And the question is when we first launched, cause you were there day one, when we tried to design, NautobotGPT was months and months ago, back to that product development process. Right. So months and months ago, did you have a persona on what the core benefit of this tour should be? And what is that?

We started out with, obviously at Network to Code, we're trying to help organizations adopt automation and network automation. So the core target audience for that is network automation engineers. And as we do these deployments, and as I mentioned, I had the privilege of seeing across all of our customers, there's obviously the technology side of things, which is you know, the part that we're helping to consult our clients with, but there's also process and people side of things, which is often some of the harder part of adopting network automation. And so our focus was on like, how can we help solve some of those problems, right? How can we elevate, you know, network engineers to network automation engineers more quickly? And so the focus in the beginning was really just around that coding assistant. and the ability to write automation jobs very quickly with a lot of accuracy. And so it's like an AI powered co-pilot was the first kind of target feature that we started building. And then we started to realize as things evolve within the AI industry and the capabilities increased, we saw how much more we could do with this. It wasn't just that coding assistant, it was so much more very quickly.

Yeah, that auto complete quickly becomes just another auto complete IDE tool, but you could do so much more, right? So Matt, how has NautobotGPT impact your work process or has it impact your process at all?

One of the real world examples that proves my point of what a network automation does primarily throughout the day that can save a lot of hours. So an example would be, I need to build a report on, let's say we have a Humana, maybe thousands of circuits. And part of what we're doing is this source of truth is getting the data from all the places, putting it in. But that doesn't mean the data is linked together appropriately. So we have all of these circuits, which we get from an output. Then we have all of these edge devices, which support the circuits. And if you think that even most companies, that's documented. from A to Z all the way through. I can tell you after years of growing a company that gets disaggregated with every company that's older in technology. So one thing that we did in real world that really saved us a lot of time was we got a download of circuits from our providers. I got a download of devices and interfaces that connect to circuits along with other data. And then I asked NautobotGPT, essentially. I don't need to tell you the whole prompt, but I asked NautobotGPT to connect the circuits to devices and specific interfaces with A side, B side, all documented all the way through. So when there was a circuit maintenance or an issue, it was really easy to not only identify what was being impacted, but automate the process as well. And so when there was a maintenance or something was down, something like that, NautobotGPT helped us connect in that notification of that as well, not just identity. The process for that is going to be pretty large. You're going to have to write a lot of data scrubbing. Once you understand the data scrubbing, data validation, once you understand that, understand that, linking it between multiple IDs and descriptions and everything to do a successful update to not a lot. So I would say that it saved us hundreds of hours over the course of a few months, which adds up to a lot of ROI pretty immediately. So it's more so the workflow of the network automation engineers has been greatly reduced when implementing these things. And so they can go focus on more projects.

Yeah, totally. I think the human capital is really what we're sometimes hidden because you know, we're paying the salary already, but you know, it is the time with especially a really skilled network engineers. We do want them to focus on the non boring stuff and the most productive projects. So if you could just walk me through that process, because what I'm

So Brad, before I answer this question, did you want to add anything to this?

I mean, I could add, you know, my team was helping on the project quite a bit, but you know, I know NautobotGPT was definitely leveraged to help write in the Nautobot jobs, right? And Matt, as an early field trial user that kind of helped us shape the actual product over time, helped contribute the feedback as they were going. And so The feedback loop was basically like asking NautobotGPT to generate a job to do these pieces. And then it would create that code. They would test it out, iterate on it. And actually some of that feedback is what's going into the additional tooling, which we might talk about later on how we do job code validation in Nautobot and how, you know, you're kind of taking this. something that you would historically have done as a needing to be oriented with Python and have a pretty strong understanding of Python to being more of a low code effort where you're just iterating and asking questions and refining that way, which is a whole new process of how to write automation jobs.

That's a great point because one of the misconceptions I encounter when people talk about, you know, whether ChatGPT or vibe coding, however you rephrase it. was they think it should work right out of the box. They were like, "Hey, I gave it a prompt and I thought it was long and hard. It was like two paragraphs or two pages of prompt and it's not working and therefore it sucks. And I shouldn't not use it before. I totally write it off." But when the vibe coding really is iterative process, you learn something new, you refine your prompt even from the next project or you put something in the say the profile, all the vibe coding has some sort of global settings and project settings. Now you could just like Obviously, you were kind of the guinea pig and we have to leverage on your real world experience to make this product better. So yeah, take us back to that experience.

Yeah, I'll take you back. So how it started with us is, you know, network engineers traditionally have so much to do during the day. And you know, you have these meetings and people come up with amazing ideas during the meetings. And it was like, hey, we've got these problems. And a lot of engineers have amazing ideas, right? But actually implementing those ideas when you're focused on building and supporting and designing networks, it's like so hard to do. So what I found is one of the processes that worked really well for us, and I'm a person when I run my teams, it's like iterate quickly. If you can do something, right then and there you just do it. So during our sprint planning sessions, when we were talking about, hey, what did we do last time? What are we doing for the upcoming sprint? And we would go over a list of also like what went well and what we could do better next time. But a lot of ideas are written down during those meetings and we have noticed we have follow up items. One of the things I was doing during the meetings was actually, hey, I had a not a lot up. being shared the whole time. And during those meetings, we would just mess around with NautobotGPT with ideas and actually potentially implement those by the end of the meeting, which it's like, you can just kind of work on this in real time versus just generating a list of a bunch of tasks. It's hoping somebody follows up on it at one point. So it's like, Hey, we're going to sprint planning. Oh, you got this idea. Okay. Let's implement it right now. And then show us, you know, have a, have NautobotGPT, write out and let's kind of go over it a little bit and then, you know, push it to a GitHub repo. And that's what I love. I love for everyone to just talk and get in the flow state and people start going back and forth on ideas and then being able to actually look at what the implementation would be right then and there. You know, that's kind of the way that we did it a lot. And then we're like, okay, now let's follow up and get this fully deployed a lot easier.

That's so much to unpack there. It's amazing because I think just the speed of innovation and the speed of proof of concept that alone makes you so much more ambitious, right?

And it makes hackathons easy. It's like no more hackathons anymore. I'm sorry. We're moving into a different age where we don't spend four days trying to discover how to do something anymore. And so every meeting can be a hackathon, which is nice.

Right. Worry less about the syntax and more about what it's going to actually do. Like that's where we want to be.

Exactly. Matt's team actually, I think you had mentioned to me that they did have some automation jobs already kind of scattered throughout the organization and they actually use NautobotGPT to convert.

I want my automation all in one place because it's way more consumable that way. And having it in one place, you have onboarding or new requests that need to go to the network team. And these new requests can come from anywhere. But when you have all the automation in one place, then you can get your onboarding and your automation to work seamlessly. in one location, that way everyone in your organization knows I go to this one place. And a lot of the questions, a lot of the requests are automated now because you have everything in one place together. And so you kind of like have this like end to end sort of like automated workflow that you can start to build out. And that was one thing that I took advantage of that a lot. And data ingestion is massive. I can say NautobotGPT. Hey, I'm ingesting this data. Here's a data set of what I've been given from the data center team or whatever other team. And I'll be like, okay, take a look at this, build me my import based on all this data that's relevant to my data within Nautobot and match it up and make sure I have everything added to the right site, application, everything. So I use NautobotGPT for that as well. And that's huge. That saves me a ton of time. Importing data can be hard because you have to scrub it and you have to figure out what's right and what's wrong. And just asking a prompt to do this for you and correlate to private data that you have within your database already. I mean, every automation engineer knows what this is like is going through and scrubbing that. and iterating and iterating and iterating till the import's correct. So being able to just ask a question and prompt, it's like, no brain.

Yeah. I think that friction is real, right? Because the person who has the knowledge of the data center tech or the data center manager, who has the ability to scrub it is different skill set than the ability to code it. So if you have to put them both in a room to actually talk to each other, we got that limitation in the communication. But if you have that person being able to just speak to it and then having in a low-code fashion.

Also reports. Your boss asks for a report. You know you're in the background. Other people are talking, asking NautobotGPT to generate this report for you. So by the time he gets back to you talking, you have to show them already and the report can be something like brand new. Like one thing we did was capacity management. We're like hey take this site, this data center in this area. Look at all the access switches of this group type. look at all the ports and tell me the percentage of available ports in this entire section of the data center. So we know whether we can expand it or whether we were using like only 30% and we're wasting ports, we have a set, but that doesn't really matter. What matters is I wanted a report we didn't have. I ask it via a prompt. It goes and grabs all this data and immediately just shows us what we need to know during.

I could already see a lot of value in that just in the data scrubbing, like you mentioned, right? Especially for big companies such as yourselves, that is one of the main hurdle even just to begin using your network source of truth. We paint a pretty rosy picture in the last five minutes on this low code and low-code capability and functionality. And I'm wondering, Brad, do you see any downsides? I mean, we've covered a lot of advantages. Yeah. What are some of the disadvantage of this hybrid approach for this low-code functionalities that we offer?

Well, you know, I think bigger picture wise, like with the ability for AI to write code, the junior engineers that are kind of up and coming right now, like what happens there, right? Like there's a whole aspect of social aspect of this that I think we need to talk about as a society. And as it gets better, you know, like what does that mean now? Because we have got senior engineers who are kind of junior engineers, right? And so like when, you know, that team begins to age out of the job industry, who's taking over? Is it just the AI that begins to watch the AI, you know, like, where are we going with this is something that I think about, but I also feel that, you know, still whatever we're inputting into the system is what you're going to get out of it. Right. And so that is something that is never going to go away. And to the point that Matt was saying before, to implemented without all these steps that used to be in between. So like that kind of, I wanna call it menial work, but like the syntax and all those things, the knowledge of that, you want me to talk about the downsides of it, who's gonna maintain the knowledge of how that stuff works going forward. And maybe it is just good enough that we describe what we want and it gets produced. Maybe that is the ideal end state. I think it is, but like somebody still has to maintain under the covers. And I will say there's some other challenges that, you know, LLMs aren't, I think everybody's heard of the strawberry problem, like count the number of R's in the word strawberry or something like that. We did just through trial and error pretty quickly learn that the large language models, the public ones are not very good at math. So we had to build tooling behind the scenes, which were still refining. refinement that needs to happen in this. You know, even with the knowledge base I was referring to that our engineering teams that are put together, that's a continuous thing, right? It's as we learn more, we need to continue to update the document repository that holds that knowledge to you and make sure that the AI is still giving solid answers. I mean, like as we built this. solution, there probably were like five or six earth shattering changes in how you do things. You know, it was all about prompt engineering in the beginning. And then there was this thing called rag that came out, which is, you know, retrieval augmentation. And it pulls documents in to make sense of that through querying and then agentic AI. And now we have agent to agent protocol and model context protocol. All of these technologies are moving so, so fast. It has been a challenge, but I will say that even though that has been difficult, every single one of those things that has come out, it's not like, you know, with the JavaScript frameworks as like a parallel example, some of them were very similar to each other, like Vue and React and like Next.js. There's similar ways to do the same thing, but what's evolving in the AI industry right now? All of these concepts like model context protocol and a way to serve tools to AI agents as a standard approach totally makes sense. And so like, it's like, okay, it doesn't feel like a pivot. It feels kind of like surfing a giant wave. So it's been a challenge, but also extremely exciting working on it.

Yeah. What do you think, Matt? What do you think are some of the downsides that you observed? I mean, one of the things that Brad brought up was excellent was this lost generation, right? Like we do need data. or human tribal knowledge that we took us a long time to get there, then what's this gap that we're going to fill even for the next generation? And as a parent of two, I do worry about that. So what do you think, Matt?

You know, I see these patterns coming up with regards to this. And one of the things that, you know, kind of like not shocked me, but turn on the light bulb, right? Because if you look at my background, I've done multiple companies in automation roles for 15 years, like just specifically tied to networking. And one of the things where the light will really turn on for me was about four or five years ago. And I was implementing an automation project and we're in this design meeting. And I'm like, we start talking about automating IP address assignment. And we're all during the meeting coming to the amusement, like we don't want to know what the IP addresses are actually. We don't want to have to care about it. If we don't know, we don't care about the automation works and everything's good. What does it matter? What does it matter if we know it or not? And so it comes down to similar things in automation now. Oh, okay. Well, maybe we don't write documentation anymore. Maybe we don't need to. It's always been hard for people. It's always been hard for every network organization I've ever been in. And it's like, who knows where this documentation is and how to find it. And I think going toward the future is things that we used to have to pay attention to. We're not going to have to anymore. We won't have to write READMEs. AI will be better at doing that for a project than we ever could be. And so there's a lot of things I think that we're used to context switching and managing the specific details of these things. I don't think we'll have to do that very much anymore because if it works the way we intended, deficiencies, speed, reliability, and security, I don't know what it's doing in the back of it. I don't really care. It's not in my mind. So I'm freed up to do what a network engineer should do, which is engineering. You know?

I think that's part of the emerging trends that if you will, that we're, you're definitely going to replace some of the manual tasks or some of the things that as you're saying Matt, that you don't really want to do anyways, right? You don't want to write that MOP or you just want to focus on the steps in the MOP that have high value and the other stuff like check the alarms or notify your NOC. Those could be.

or searching through massive amounts of API information to try to figure out which API you need and how to do it and what the data structure looks like. And so just asking a question.

Right. Yeah. Yeah. For sure. Let me turn that question to you as well. So Matt, you know, kind of from a users and practitioners perspective on these are the things that I see as the trends in the AI driven for network automation, you know, taking out these manual work. What about you from a kind of a backend perspective, what do you see those AI driven network automation trends are?

Yeah, I definitely see agentic AI being the path forward, where you can actually build a hierarchy of AI agents that all have specialized types of things that they do.

Do you want to explain a little bit about what agents are? Because I think that's kind of very different from just RAG. RAG is a, explain RAG.

Yeah, yeah, we can talk about RAG. Yeah. Maybe we should start on that. Yeah, maybe we should. Let's do it. So RAG is basically this concept of having the AI be able to query a vector database. A vector database is simply a place where you can store documents and make them searchable. And so that context that gets retrieved, the AI will query that vector store. It will retrieve the information based on the question you asked. So it's like the context of what you asked is what it's going to search for. That's what retrieval augmented generation or RAG is. Agentic takes a step forward from that. So with a typical approach with just straight up ChatGPT or Claude, when you go straight to an LLM, the provider itself, you're asking a query. The LLM provider has a system prompt that you can't see that just kind of tells it what it's persona and how to answer the question. It does the inference and reasoning, and then it sends a response back to you. a request response straight up. With agentic, we're now segmenting that out. So we have little pieces of code that now you can write your own instructions for rather than rely on the provider to have the instructions. I can say you are an agent that specializes in writing jobs for Nautobot. This is what you're going to do and how you're going to do it, where you're going to get the knowledge. These are the best practices and the guidelines that you should follow, et cetera, et cetera, et cetera. The other thing that So what is a tool is the next question that you should be asking. And a tool is basically another piece of code that doesn't have AI, but the AI is able to use it. So think of a straight up Python function that does something. Maybe it makes an API call. And in the case of NautobotGPT and it's Nautobot read agent, it has access to GraphQL. And it knows how to make GraphQL API calls. And it knows the order because in the instruction set of those tools, it knows the order of operations of things. And so these agents are aware of the tools capabilities. And so then you can have an agent can have sub agents and you can create trees of these things. So in the case of the Nautobot read agent, it may have a sub agent that says, okay, I just received this data from the raw API call. I need to do some math here. So maybe there's some math functions or math tools that it has access to, which will group things. you basically have an agent that writes the code and then you literally have another agent that can do code reviews. And so these agents all start to work together and they have specialized functions. I think that's the easiest way to describe agents. There's a little bit more to it. And the way they retrieve tools can be like static and dynamic. And you can do routing between these agents, which is super interesting because– You know, we're all coming from networking backgrounds. There's a lot of similarities to static routing and dynamic routing when it comes to agents. You can have a prompt that says, Hey, if you need to talk to an Nautobot, go to this agent, or if you need to do math, go to that agent. And it's a static prompt that points you to an agent or a tool, but you can also have these things learned dynamically in the code, in the doc strings of things. or the description of the agent can describe what the agent is capable of doing or what the tool is capable of doing. So when you attach that tool or that agent to another agent, it's learning. It's learning about what those sub-agents are capable of doing or are responsible for. And it's also learning what the tools that it has access to are responsible for. And so as you route– A question through this chain of agents now, this context starts to build up as you go step by step by step through the routing. It's very interesting stuff.

You have me at routing, sir. So to me, I have to admit I wasn't a believer in an agentic approach approach, but once I tried it, it made all the difference. And the way that I would paraphrase it in my own puny little mind was, you know, having augmented retrieval, it's almost like you're scaling up. You're putting more smarts into the single unit that best, the person who does co-review best, the person who does the job best, they should all work harmoniously on the back end where you still have this root interface toward that world. But hey, when I launch amazon.com, there's 300 API calls. I don't care. I just want the product I want to search for. Exactly. Yeah. So that's how I imagine it'd be. I don't know if you have any other insights to that, Matt. I mean, because I think you're the person who's very close to the rubber meets the road, right? So I'm very interested in hearing. your opinion about that as well. You know, for me, I think of a distributed model versus a centralized model as being centralized as a rag and distributing as an agentic approach. So do you see any kind of from a operator perspective? I'm just wondering about your experience.

Yeah, for me, I think it just depends. The way that I always run things is like I don't really prioritize the technology. You know, I prioritize the processes and the people's ability to use the process. And for me, it's like, it kind of varies depending on the needs. I'm not going to be stuck to one specific thing. And everybody, I think, ideally wants to be able to just keep things simple, have a single source, a single source model where it's like, but there's use cases where that's just not even possible. And especially when it comes down to scalability and everything kind of works well in the beginning until you scale it, then that's when you're like, okay, none of this works anymore.

I actually like that answer a lot because the answer is who cares, right?

It's kind of true. Right. Exactly. It's like, who cares about the technology? This is what I want. And I don't care where you have 10,000 agent or if you have one rack unit back there, if you had just this ginormous L.M. that works. Right. Yeah. I love that. And maybe at minimum, like my career has been based on automation scaling. I've worked with a lot of companies where the networks are just massive. Scale is all that matters. But, you know, like there's also So we don't have to consume the WAN with massive amounts of data between systems. So it's like, well, let's leave the data in the data center and then let's just communicate back what we're doing with the data. So, you know, the distributed model in these large data centers always put remote task workers, for example, in each space. so that it can be executed locally and then managed centrally.

Yeah, I think that high level design is truly kind of analogous to what we're talking about here, right? You put the workforce closest to where the action is so you don't backhaul everything back into the cloud or whatever. So I wanna ask one question as far as just future looking, right? As far as we're on the AI trends and future looking. So Matt, if you have a magic wand that you could say, I wanna add these features. What would those be?

You know, one of the things that like I would like, you know, moving forward, there's multiple, multiple areas where I think I would go with this, which is the ability even to have like an execute button within NautobotGPT. So it's like, okay, now we have this. I don't have to copy anything, paste it. I want to be like, okay, I've asked you this prop. Now what do you want to do with it? Shall I execute it right now and show you or execute might be. creating the job directly from the prompt, not like necessarily executing code against your infrastructure. And then you click one button and then you're good to go. It's like, okay, then write the documentation for me and put it in there. And boom, click one button, it goes and saves it to GitHub, whatever. And then another thing is onboarding. Onboarding to me is like massive and I want some automation that's focused. more around onboarding as well, getting data into the system. And there's a lot of like, I think thought processes that might need to go into how that would be useful. Those are just kind of like two of the things that I would like to see improved in that or added as features and maybe add another feature where we can execute NautobotGPT questions, maybe even from like a slide channel too. Like hitting it remotely instead of having to go to that. devices here and tell me what's in this side or where is this located and it could be in the same place where we have integrations with everything else.

Yeah, I would definitely agree with that. And you know what that shows Matt is that you now have a higher confidence of AI. Now you're just like, you know, trying to trust it more. And I see that same kind of feature requests in cursor as well, cursor, which being like the vibe coding tool. where they used to have a setting in there that says YOLO. You only live once and if you turn on that, then the tool becomes much more liberal in what they want to do, like push to GitHub repo, whatever. So I actually like that a lot because that just shows that the natural progression that you have higher confidence, they're just like, hey, why do you even ask? I always accept it. So what would be different this time?

As in automation engineers, everything, the goal is self-service. The goal is so you don't need an engineer. Right, right. Right? And so if you can even give prompts to people outside of network engineering based off of rewrite access, you know, you can't write, but you can ask as many questions as you want about the network. And it would be useful for many teams outside of engineering to be able to have access to something like that. For questions for the network, 'cause everybody has questions about the network. It's one of the things, server guys, application. You know, security, DevOps and all that. Everybody's like, "Okay, what's going on with the network? What's going on with the network?" It's like, "Go ask."

It's like having Google for the network.

Yeah, exactly. Precisely.

And after I just give you like a next six months feature request, Brad, do you have anything out to that as far as just what's next for, you know, NautobotGPT?

The answer is there's a lot of what's next. The hard part for us is to pick which ones are the most compelling to do first, you know, without committing to any of the features. I know one of the things Matt just mentioned is the ability to make change. That's a big thing when you start to trust AI enough to actually make a change in an environment. Yeah. You got to have guardrails, even though it's the only live once we have some good ideas there. One of my colleagues actually, suggested a solution on which we've got a planning session around coming up on how that's going to work. But there is a right capability coming between NautobotGPT and Nautobot itself. it will be very specialized to start and we'll pick and choose what it's able to do and not to do. Part of the other challenge to that is, you know, the technology is evolving very quickly. And so passing things like credentials and role-based access control through these various agent-based systems is still evolving, right? And so we're waiting to see like there's this agent to agent protocol and OAuth. Based authentication was just recently added into a lot of the agent tooling and frameworks. So what does that actually look like? You know, one month from now, two months from now, it's like every two weeks, something is changing in that regards,

but every two hours, man.

Yeah. And you mentioned a vibe coding and probably the lower hanging fruit here for features that we're planning to release is integration to code editors and having NautobotGPT be able to live right within your. get a co-pilot or cursor or any agentic coding style IDE that can talk to an MCP server or a model context protocol server, which would be the way you would attach to NautobotGPT. And what that would allow you to do is kind of bring the coding agent capabilities closer to you when you're actually writing code, but eventually. We would like to get to that point where you can just ask NautobotGPT to write the job and it also deploys it and integrates to GitHub and all of these things. So they're all possible and we are absolutely working on those.

Yeah. Or as Jason would say, right? No for now. Yeah.

Yeah. The timing of things is the key. Yep. And prioritization. Yeah.

If Phil Gervasi, which is our guest on the show before, has his way, he'll be, "Everybody please just freeze for like two weeks so I could get caught up on all the latest technology." Then you could go, right? But we know that's not possible. We are coming up on time. We cover a lot of ground here. And I do want to ask you, Matt, do you have any call to action for people just from a operation perspective, being a beta user, being such a long veteran of network automation, now in the leadership role? What's your call to action for this whole AI network automation thing?

My call to action would be, I really want to spend less time doing things that I don't need to do. Okay. My call to action would be like, let's just forget about 90% of the stuff we do after something's implemented in an automation strategy. And so it really frees up your mind and there's a lot. of potential that we have when we clear out the garbage and we have less things to think about. And even if, you know, you don't have like a source of truth maybe, but you're thinking of getting one, think about the future, you know, AI needs data and everything needs data. So what I think it's focused on is AI assisting in gathering. and normalizing the data. And then AI assisting in interacting with the data. I would say call to action is people need to start figuring out where the data is adjusted, where it comes from. And I see a visual work where AI is primarily managing that. So we don't need to like maybe we have a naming standards. AI understands that and automatically adjusts. You know, and things like that. And so what I wanted to build there was a foundation. A human was a foundation where all the data was in one location. So it can be consumable by AI.

That makes sense. I mean, so your core action would basically be if your company today doesn't even have data, don't think about AI just yet. You should have this AI driven mindset first, build the foundation. Then you can move to the next step. If you really look at that garden, that's beautiful. You start planning now. Yeah. Any call to action there, Brad? For people who are AI curious or NautobotGPT curious.

Yeah. 100% agree with Matt. Data is the fuel to this fire and it can't burn without it. And, I will say the one thing that I would say as a call to action is AI can do a lot and you know, it's easy to try it out and then get a response that you didn't necessarily expect and to be dismissive of what that was, even outside of NautobotGPT, but just in general, right? This is not deterministic software anymore, right? Like where you're writing if this, then that. It is using probability and all sorts of black magic under the hood. But I will say the reality is the technology is moving at such a pace right now that the capabilities are to dismiss anymore. And for anybody who's previously had a bad experience with trying something out and getting an unexpected response, I say, try it again and use it as an iterative tool. And I would say we really should be jumping in and leaning in on this technology. to understand what it can do rather than being dismissive of it. And the reason I say that is because to get to that next level of operations, you know, where what's in your head as an idea becomes reality more quickly, it is going to be an enabler for that. If you're not there kind of playing around with vibe coding and understanding AI agents and what's possible. You may not get to that conclusion of idea to product or feature or automation code as fast as you could have. And so like I'd say, embrace it, lean in and don't be afraid.

I think you stole my call to action because that's my two. Me and Jason talk about it. Me and a lot of guests talk about it as well, right? Like what's the next step? And there's so many things going on. So if you're not sure which way to go. then how can you get there? If you don't even know your destination. So my call to action and I'll throw it right in and kind of, you know, right on your tailwind is start learning, right? Start forming an opinion, start having some hands on experience. Don't be dismissive and just, you know, trust us and take that leap of faith. Go try it out to form opinions. Just start learning. I don't think you go wrong with that. Even if there's 10 different directions that the industry is going. So let me stick with you a little bit, Brad. Where can people find you as we wrap up this episode? Where can people find your word, connect with you, or just follow your leadership?

So obviously, Network to Code, all of the GitHub organizations there, you can see some of my work there. My personal GitHub account, bradh11, and then up on X, Bradford Haas is my handle there. And you can DM me at LinkedIn as well, Bradford Haas.

Yeah, thanks so much. Matt, what about you? Where can people find you and where can people connect with you or follow your work?

My primary mode of communication is LinkedIn. Okay. So Matthew Schwenn, type it. There's literally two Matthew Schwenns in the whole world. And still, I don't exactly like my name. So I think one of them is like my third cousin. And so just hit me up on LinkedIn. I'm very, very responsive there. I'm very involved in the automation community. I also sit on the Network to Code Slack channel, which is free. And if you're a network automation engineer, even a network engineer, you're not part of that Slack channel like you're really missing out. Tons of amazing engineers would love to answer questions and interact with you, including me. I watch multiple channels on there. Join and hit me up and I'd love to talk. to anybody just, it's a passion of mine and any projects you're working on, more than happy to interact and connect with you.

That's awesome. I really do appreciate both of you being on the show today. I know it's only been, what is it a week and a half or two weeks since NautobotGPT was announced. And, you know, Matt was kind enough to do a joint presentation at ONUG. for us. And it's just so rare to have something concrete and something that's been developed that we could finally released and have a user's perspectives. I really appreciate both of you being on here. Thanks, Brad. Thanks, Matt.

Yes, you are welcome. Thank you.

Thank you for listening to this episode of Network Automation Nerds. Do you have any feedback for network automation? And I bet you do. Our guests today, Matt and Brad, or any of the content that we cover in this episode, do send us some follow-ups on packetpushers.net/followup. And we do want to hear from you. Follow me, Eric Chou, and connect with me on LinkedIn at LinkedIn.com/in/choueric. And check out our website at packetpushers.net to find other network engineering focused podcasts, blogs, YouTube videos, sign up for our newsletter, and there's so much more there. And we do want to thank you, the wonderful listeners for your support. Last but not least, remember that too much network automation would never be enough.