Manav Gupta: What if your network had a CCIE level engineer on call one who never sleeps? never misses a BGP stage transition and Can visualize your entire topology in 3d in under 30 seconds in natural language? Well, my guest today has done something remarkable. I I today have the pleasure ⁓ of hosting John who is the head of AI and developer relationship at i10show, a Google developer expert, a former Cisco AI technical leader, and the former senior network architect for the Parliament of Canada. That one really caught my attention. And by the way, last but not the least, a fellow Canadian to boot. John also happens to be the creator of Netclaw, which is a open source AI agent inspired by OpenClaw. that clause through your network. And he's also the founder of VibeOps Forum, a community that went from what I can tell zero to 400 plus members in weeks. John's thesis is simple and uncomfortable. After a decade of network automation evangelism, John's belief is 70 % of the networks are still not meaningfully automated. And he is no longer sure that the remaining 70 % will ever bother to catch up with the old way just because AI is going to change the on-ramp entirely. So this is a conversation for enterprise architects, infrastructure leaders, telco experts, and CTOs who need to understand what's happening on the ops floor right now. I'm Manav Gupta. This is ShipAI and John, welcome to the show.

John Capobianco: Manav, thank you so much and what a wonderful introduction. really, ⁓ you know, reflect on my career when you, you know, kind of covered in that way, but it's an exciting time to be in network engineering. Let me start there. And ⁓ this is going to be a story of optimism and of hope and of opportunity. I think the tide has shifted though, Manav, in that, like you said, the VibeOps forum has grown. My net claw has gotten, you know, really international attention. I think the general mindset has started to shift to acceptance of artificial intelligence in our, in my little sphere of network automation and networking. That wasn't always the case. And that is a very recent trend, let's say. So I think that we're reaching critical mass, you know?

Manav Gupta: Absolutely. Or and let's listen. I really like that you started that this is going to be a story of optimism and hope and opportunity I gotta say that's quite unlike many other speakers guests that I have So without further ado, let's dive in. I got a whole bunch of questions for you So I'm gonna start with what I call the builders origin because I really think that you truly are a builder So you've been in the networking industry for 25 years. You've been at Cisco, Parliament of Canada, selector AI, and now at i10 show. You also run a website called Automate Your Network and you're shipping open source tools constantly. So where does that builder instinct come from in a career that could have stayed so squarely on the operations side?

John Capobianco: Um, it's that's a very good question. I think when I reflect, I think it's because of my very early introduction to the home computer and, and particularly bulletin board systems. Now that's, know a lot of people maybe have never even heard of what a bulletin board system is, but, when I was very young, I was like, as a child, we, my brother and I got access to a 286 computer.

Manav Gupta: ⁓ my God, is going back some time.

John Capobianco: You have a long time 40 years ago. I was introduced to computers as a kid and We had to figure it out on our own and we built what was exciting was that we could build You know a bulletin board system that allowed other people to dial into our computer and we could exchange files and have Conversations and we had a you message boards and things of that nature seems simplistic now one-to-one communication ⁓ but That really, you know, as a very, at a very young age, to be able to take this magical box, this computer made up of a CPU and RAM and a hard drive, and now network connectivity through a modem, it really stuck with me my whole life. I went back to school to learn to be a programmer because I wanted to learn how to code and actually wanted to study and learn. Object-oriented programming at the time was sort of a big deal. and there was a lot of opportunities in programming. And then what was really interesting is that I spent, let's call it 15 years doing network networking, network engineering, network architecture, network design, operations, everything involved around networking, some security, some wifi, some voiceover IP, some data center, you know, but then ⁓ network automation intersected with networking. So I could apply those skills that I had learned as a programmer, broadly speaking, but now to apply it to the way that I was operating and designing and deploying and monitoring and diagramming and testing infrastructure. So that's where I sort of felt like I had maybe a bit of an advantage over other maybe purely network engineer people who only did networking ⁓ but weren't exposed to programming. So when those two intersected, I really really saw an opportunity and I thought to myself that this is a bit of a joke, Manav, but I've been saying for the last 10 years that... Within the next three years network automation is going to be the only way to do things So i've been saying that a very very long time and now you know, it's 10 years into network automation as a proven discipline I like you mentioned in the intro Only 30 according to the the you know, the network automation forum study Roughly 30 are doing something meaningful with automation Right and and I sort of look at the 70 % and I wonder what's What's holding them back is that you know, what are the constraints here? I've given it a lot of thought and i'm not sure i'm gonna have do you believe that does that reflect does your opinion reflect that That maybe network automation didn't really take off and take hold ⁓ based on the promises of of ansible and python and write all of these frameworks

Manav Gupta: No, so I think it's multiple factors. think number one, I don't agree that 70 % of networks have not been automated. I think the number is actually far higher. I'd be surprised if it's anywhere near 30%. Heck, I don't think that even it's even near 20%. I think telcos are trying constantly. And John, you're a man after my own heart. I spent over a decade in telco. So I know a thing or two about network automation, consideration, performance management, event management, and so on. And even back then, when we were discovering networks, helping clients build their network inventory systems, build a network topology. Just three weeks ago, I had a conversation with one of the biggest telcos in Canada. And guess what problem they're trying to solve? Exact same problems that I left or that I thought were solved 20 years ago. Everything to do with topology, inventory, finding out blast radius, being able to do RCA of the network. So I chalk it down to the classic innovators dilemma. So we build these networks, the telcos build these networks, by the time they build and scale it out and build nationwide infrastructure, the next wave of telco ⁓ innovation comes in. Now they gotta go chase something new. And then while they are getting better at it, you had all the OTT providers come in. So I think they've had... winds of change buffering them from every angle. And therefore that leads to this mess that they are in. I mean, in some ways we've sort of accepted that if I called my telco, which first of all, all of us hate doing, but if I call them, I'm going to be on hold for 20 minutes and then it's going to be an hour long conversation before anything gets involved. That's reality that we have all accepted.

John Capobianco: It's unfortunate, and I think it's a mix of the tooling, let's say, that the vendors have provided, right? Also the complexity of a network engineer's job, right? They're focused on the network. They're focused on keeping the uptime. When they're not focused on operations, they're working on documentation, they're working on the latest networking skills and their latest networking certification, right? So I understand, I empathize, I really do. But I think, you know, I still think that this hybrid approach as a practitioner, and maybe the good news is here, is that artificial intelligence is here. So where a network engineer can apply their domain specific knowledge,

Manav Gupta: Yeah.

John Capobianco: About let's say bgp or ospf or whatever it is in their their sphere 20, 20 15 10 years of network experience They can use that right there That's what is being filtered through to their prompts and to what the way they can build agents now Right. So the good news for the for the you know, everyone's understaffed Even if there was budget to hire new staff, you can't just immediately wave a magic wand and hire even the best network engineer is going to need some time To learn your topology to learn your configs, right? Like there is no magic solution here But I think maybe agents are or could be part of the solution Maybe not the overall solution, but they could play a part And I'd like to think of it is that each individual like manav you are going to have your 10 agents or five agents or six agents, you as an individual, I, John, am going to have my five or 10 agents, right? And individual operators and network architects and engineers and designers, right? So we can scale, but with digital coworkers, right? So like if the gap right now is, let's say log analysis, right? ⁓ Maybe look at finding a way to ingest those logs and using artificial intelligence in some way to parse them. You know, there is some lower hanging fruit here. We don't have to come up with, you know, the magic unicorn agent that does absolutely everything, right? The modularity of MCPs as well, Manav, makes it quite easy to snap in the particular skills and tools into the agent that you want to build, right? If there's a deficiency in your... ⁓ Here's a good example. ⁓ Cisco, there's an article on their webpage, just I introduced yesterday. or the day before. So by the time this airs it'll probably be more well known. ⁓ The DevNet MCP. Now what this is if you look at it, it's the Meraki APIs and the Catalyst Center APIs. So two very popular and prominent products. Well all of their APIs have been documented underneath this DevNet MCP. So now you, you meaning the listener, can snap that into your And I call them agents because they are. You don't have to build an agent, but let's say Microsoft Copilot. You know, if you're listening, you should probably be using VS Code or your team should be probably using VS Code. Even if you're network engineers, VS Code should be part of your toolkit. Yet within VS Code, there's a Copilot now, a Microsoft Copilot that you can plug MCPs into. So imagine driving your Meraki or your DNA Center from VS Code through the Copilot. Please make a CSV file of all of my down to access points. Enter. And it uses the MCP calls the right API gets the right payload gives it back to you in natural language. Here's your CSV. And then in VS code, you'll have a new CSV file of all your access points that are having problems through the DNA center. Like we're, we were moving very fast Manav. And then that's just, that's one example of their MCP. Now I am going to be adding that MCP to netclaw. And that's the wonderful thing about netclaw is that it's architecture is that it's all modular and it's built on skills and MCPs. So as these open source MCPs come out that are, you someone sent me an Aruba MCP and said this is an Aruba CX MCP. It would be great in Netclaw because then I could run my Aruba through Netclaw. Sure. Okay. So I'm working on that, you know, as we speak right now on my other computer. I think that's why it's crashed. In the background, I'm using GPU locally to build the skills and I think that's why it crashed. Anyhow, ⁓

Manav Gupta: Ha ha ha.

John Capobianco: So the, will evolve. It's kind of like a lobster. like this open-claw idea that it's constantly evolving and molting and growing. So there's going to be more skills, more MCPs. I just tied it into blender. Manav, you mentioned 3d topology of people wondering how that's done. Have you ever played with blender Manav or know anyone who's played with this 3d? Okay. So it's not, it is a very sophisticated tool, right?

Manav Gupta: Yeah. ⁓ yes my friend, I am a true geek, yeah.

John Capobianco: Blender is not a very simple ease. It's got a high learning curve, a steep learning curve to really get going in this 3D designer. Well, now there's an MCP for it. So you turn the Blender MCP on and NetClaw can now go get CDP neighbors and literally draw a 3D topology of your network.

Manav Gupta: Absolutely. a free rendering of the network. I absolutely love it. Listen, you know, you're talking to a builder when you go from networks to topology to bulletin boards to 286 object oriented programming through to OpenClaw and Blender. But let me peel some of the layers of the onion here. So let's talk about Netclaw and quite candidly,

John Capobianco: Hahaha

Manav Gupta: I've been playing with OpenClaw quite a lot. I got into some trouble as well because, you know, that's the nature of these things. I ended up burning through some $200, $300 worth of API cost overnight because I had a misconfigured agent, but that's the price you pay. But I was fascinated by your post. I think you called it six days of Netlaw, which was in turn written, of course, as these things go by Netlaw itself, which documents what you shipped in less than a week. It had a whole bunch of skills and domain that had the first community pull request. So walk me through the inspiration for creating NetLaw and what were you trying to accomplish or prove with that project?

John Capobianco: Well, what I had seen in OpenClaw won the popularity and won the opportunity. And it wasn't just about hype. It's not just because I'm chasing the next hot thing. When you read news that OpenClaw has more stars than ⁓ Linux, right, or Git itself, it opens your eyes and you wonder, well, what is this all about? So when I looked at it and I saw some examples, I thought, wouldn't it be neat to fork this and And and make it network centric So all of the things that come with openclaw so really to be you know i'm going to like you mentioned an onion At the core of netclaw is an openclaw instance And that really gives me some advantages because I don't have to wire in All of the communication channels that openclaw offers Right. I don't have to write the telegraph or the whatsapp or the teams or google chat All of the supported platforms from openclaw claw can now call the skills and the skills is the top layer. So it's a markdown file explaining the skill to the LLM. And then if there's an MCP to support the skill, I'll typically ship the MCP as well. It started with PAI-ETS. So here's my book. I am the author of the Cisco PAI-ETS book. Hard to see with the blur, but I always, that's always my inspiration is to

Manav Gupta: Yep, there we go. Let's go buy APS.

John Capobianco: See if I could connect pyts to open claw and then and then it was more mcps and more skills and eventually I thought okay i'm going to call this net claw it's a it's an it's an open client implementation to claw through your network And I use the slack channel. So it's actually live I typically have a live net claw in the vibe ops forum in its own channel for people to play with and interact with and it's connected to a live cml network on my back end and It can do a lot of really neat things And and more and more people are using it I see it You know people on LinkedIn are tagging me or not tagging me or I saw a couple posts They were just saying I've just spun up my first net claw and I'm actually talking to my network through telegraph on their phone on the fly ⁓ It's really exciting to me to think that this little you know Project it really was what what if I could connect by ETS to an open claw? And then it just evolved from there and kept growing and building steam. ⁓ And it's really exciting. It's a really exciting time. I went to the OpenClaw meetup and I want to give Sebastian Maniac another Canadian man of you might want to have Sebastian on here next. He's a wonderful guy. He hosted an OpenClaw meetup in Toronto, the first one that I know of. So I flew in from Ottawa to go to the meetup and to speak and to talk about NetClaw. Now,

Manav Gupta: I'd to. Yeah, that'd be amazing, yes.

John Capobianco: You know the obvious question. think if anyone is listening how to get started i've tried to make it easy In that you can get clone the repository and then run an install.sh bash script And it will walk you through the open call questionnaire And then a net call questionnaire I call it a questionnaire because you get to pick what api keys what services what you want to connect to by ips It's alacarte. You don't need to configure everything ⁓ For more advanced people, I would recommend that you actually maybe fork the repo and trim it down. And maybe like if you're only using, let's say the identity services engine ⁓ skills, you know, and nothing else, or a few of the other skills, you know, you, as a, because it's open source have full control over the code to trim out all the other skills that you're not using. If you want to make a nice lightweight claw. And then what we get is purpose driven clause. We might have the security claw. the network claw, the observability claw, right? All these different agents with different skills and different access to different things in terms of data as a backend. ⁓ And they all work together and they all surface problems and they all make do configuration management changes and testing. And you can talk to it right on your phone in any platform you want. I just added Webex support and it's kind of neat is that cross channel communication works. So from Webex, I can tell the NetClaw to let the Slack room know about some event and they will work cross channel.

Manav Gupta: serving. I think that's the key. I mean, listen, the more I think about all these claws, net claw, open claw, et cetera. I think the future of how we triage RCA outages, how the war rooms assemble very quickly, that that's going to evolve because rather than have humans gather around the proverbial telephone and try and triage and debug, we could fire up an army of agents, do that debugging for us in real time and potentially debate each other, contest each other, and come up with a mutually agreed upon proposal that multiple models can all vote and a human can provide the oversight.

John Capobianco: I think you're absolutely right and I think we're going to...so there's two... Let's say there's sort of three scales here that I'm sort of looking at as sort of like layers, right? So we sort of have human in the loop, which is where I think most people want to start where the agent says to you, ⁓ here's my proposed config, John, would you like me to apply it to router one? And I'm in full control. I'm in the loop, right? On the loop. I'm still watching it. I'm still paying attention. Maybe it's making tickets for me. Maybe it's sending an email recaps. Maybe I'm just sort of monitoring it loosely. And then there's full autonomous full. Whatever the agents doing it's doing I trust it like a co-worker or a subordinate worker. Let's call it right and it's funny enough ⁓ Not funny, but ⁓ kind of prophetic ⁓ Jensen Wong said I think this was at the start of last year That the future of IT departments is going to be an HR department for agents And that this sort of shifts away from a technology problem into more of an ⁓ org chart and a human org. So if I have those five agents, they sort of report to John. And John is responsible to human in the human world. If they make a mistake, if they get something wrong, right, we have to correct the code. We have to adjust the agent's data source or the prompts. That's up to me, the human that's in charge of those agents, right? But we all want to collaborate. We don't want to have overlapping agents. And this is what I like about itential is that we have a platform. to host those agents so then we can all collaborate and reuse. There's no reason John can't use Manav's agent and Jim's agent and Sally's agent and Rebecca's agent and put them all into a nice workflow like you said and bring in the hundreds of agents that all get to work together. That's what we're moving to and it's gonna be human. And then like you said, that war room, that WebEx call or this Zoom might have three or four agents in it and they participate just like people.

Manav Gupta: Exactly. But the crux of all this boils down to the critical fact that the network is a living entity. And I think a lot of time people will tend to not appreciate it. So while agents in IT, agents in development, in ADLC, et cetera, I think people get it. And probably the bar is not that high. but agents applying a config change in real time on a living entity such as a network, which will have profound implications because hey, might cause a critical outage, right? Might cause a jitter and latency, know, things that only the technical folks know, but eventually on the consumer side, it boils down to can do my job. Taking too long when I get disconnected. So how do you establish the critical word in in your description? You use was trust. How do you establish trust?

John Capobianco: Well, I think it rhymes with network automation. I don't think there's a huge difference in terms of your approach ⁓ as an organization to consuming artificial intelligence agents, let's say. So a couple of things to understand is I like to call them specifically React agents. And there's an ARVIX paper that's about this. I'm not making this up myself. I'm not taking credit for the term, but I would look into that paper and what it explains is that reasoning agents. as of, as of chat GPT 01, the 01 model introduced this idea of reasoning where instead of where you ask an LLM a question and instantly responds and spews back an answer, it now recursively and for lack of a better term thinks about the initial prompt before it just answers you. So they would be They classify that as a reasoning capable model. Then around the same time, models got the ability to act. And what I mean by act is run external code, execute code. And that's where MCP sort of comes in is that the act. the model can run the MCP so it can reason and call tools, right? So I like to start with read-only activities, just like we did with network automation. There's some low-hanging fruit. So documentation of your network, reconciling with your sources of truth, maybe building your first source of truth in Netbox or something. ⁓ Testing is a wonderful place to start. And then maybe something like triage where your IT tickets, any ticketing system that you can ingest, you're just asking it for its opinion and maybe connecting it to some read-only data sources. So maybe that is where you start as an organization is to get its opinion, not to let it change or remediate or to fix. That's where something like, like I said, ⁓ with an Itentio platform, it's totally flexible. So you could start with a read-only agent. ⁓ Here's a practical example. I made an agent that can read the network interfaces and IP addresses. So using PyETS and MCP, will connect to the router or switch or whatever and run some commands and return the data back to the LLM as JSON. From there, the LLM can use the NetBox MCP. and populate the source of truth. So it would add your router to the site that you specify and all of the interfaces and all of the IP addresses, any services it finds, literally build your source of truth with an agent. I think that's a wonderful use case for people to get started with. And there's gonna be more videos and content about that out there. ⁓ I like pass fail tests. My very first potential flow AI agent, I had it connect with PyTS and I said, go tell me, know, the interfaces healthy on this device? And it went ahead and came back with an interface health report, right? So there's a lot of opportunity to start. I know people are really timid and really scared, but with the right guard rails and the right approach and the right access to the right data. There's no reason why you wouldn't treat it like a junior engineer to start with. So I'm gonna have here that's I've had this discussion with someone else actually just yesterday. I bet maybe a better analogy for people to absorb. What was one of the first things you would give a junior engineer if you hired a junior network engineer? What would you have them do? Yeah, like if you actually could magically hire one person right now What would you have them do? And I know when I was at parliament or even at Empire life when a new network person joined the team Typically, they got the crappy job of reconciling the source of truth

Manav Gupta: That's right.

John Capobianco: Here's the link to the documentation folder. Here's your login and password into the network. For the first couple of weeks, all I want you to do is update documentation. Make sure everything that is in the source of truth is up to date. Right? Because you don't even know their skill. They don't know the network. You haven't established trust. So why not do the same thing with that AI agent? Bring on an AI agent and what its first primary purpose is doing ⁓ compliance, let's say.

Manav Gupta: Exactly.

John Capobianco: Right? Are your, you know, compliance standards, templates, testing, documentation. And then, you know, let's say three or four months go by and it's done a wonderful job of doing all those things you've had to do. then maybe you start to incorporate some change management. Maybe you start to incorporate it in a little bit more risk, maybe take on more risk as we would say, as you've earned trust and know how to prompt it, know how it works, understand the technology you're working with. If it did a great job of doing testing and documentation and remediation, maybe the next step in that remediation agent is to give it the keys to the castle and say, okay. send your recommendation, human in the loop, to the senior network engineer, right? Or like send the Slack message or send the email, send the communication to the human to get their approval. The human approves the change. The agent makes the change and redoes the tests and proves that it worked and fixed it. Then what's the next step, Manav, right, would be to say, okay, now I guess I don't need the human. If it can prove itself over a thousand tickets and it gets 995 of them right, well, now I don't need to be bothered by it. And now my whole ITSM, when tickets come in, we send them to the agent. If the agent can't solve it, then we escalate to people, right? Does that not seem like a natural path forward for people?

Manav Gupta: Yeah. I think it absolutely does. I love the majority model that you laid out really for graduated adoption of these, of not just agents, but AI in general in an enterprise. I think that's fantastic. Okay. So let's pivot to vibe ops. know, I mean, I did some Google food and I think I can pretty much credit you for coining the term vibe ops. So give me your 60 second version. What is it and why did the industry need a new word?

John Capobianco: Well, I, a couple of things. I wanted to marry the idea of vibe coding and it's funny now vibe coding. think we just call it coding. Don't we? Isn't that the way everybody does it now? Anyway, that's an aside. So I wanted to take the premise of vibe coding that anybody can use natural language to achieve outcomes with infrastructure. That's where the ops comes in vibe ops. And with an approach that follows things like

Manav Gupta: Yep.

John Capobianco: You know, like I go all the way back to the agile manifesto that had a big impact on me moving the agile and CICD pipelines and Kanban boards and stand ups. And there was a whole wave of adoption about ⁓ using agile for software. Now it took networks a few years and we get DevOps, right? So we have traditional ops. We move into DevOps DevOps is wildly successful. So then we try net DevOps, right? Or right. AI ops, I think is a thing. And I think it's a little different than vibe ops, but AI ops is kind of the machine learning and the generative AI. Right. So ingesting lots of data, you doing what selector does and selector does it very well. Take all the data and feed it to the AI and we'll crunch down and make the connections and give you the root cause. I think the vibe ops portion is using natural language to use model context protocol, the protocol itself and AI agents. where we introduce sort of a third party into our approach. Where network automation and even human or so even before network automation humans write SSH in devices going into the command line and doing everything by hand. We sort of shift to scripts doing that with automation and now we can have agents do that and the humans interface with the agent. Now the difference between network automation is that to interface with the scripts you had to know the domain specific language. You had to know some YAML and some or you had to know some Python and some PyETS or Nornir or whatever. So there was some friction there that it was still highly coupled to the network engineer with VibeOps. Now the solution is an agent. that anybody can speak to it in any human language with any level of knowledge about the network or the infrastructure and still achieve the outcome, right? So it could be someone asking for a change and it's a well-informed human that knows how to interface with the AI agent and give it the specifications. But also I think what backs up VibeOps now ⁓ is spec-driven development, SED. So if anyone listening has not heard of this, don't feel bad. It's only six to eight months a year old. The official GitHub SDK, and it's called SpecKit on GitHub, and you should go find it. It's about six months old. So much like test-driven development, TDD, where you write a failed test. and then write the most minimal amount of code to fix it and make it pass. And then you iterate. This spec-driven development lets you build a constitution. So your guardrails, highest, highest level form of instruction set, the constitution of this project you're working on. And then you get into specifications. Now, Manav, what's really neat to me, I think this is going to be a huge breakthrough for people in general, human beings, because anyone can adopt it, spec-driven development, and it can apply it to anything. I'm applying it to network automation and to AI agents for network automation, but you can build literally anything you want from specifications. What's really neat is they're markdown files, and in the markdown files, they're user stories and functional requirements and acceptance criteria and testing criteria. They're these wonderful markdown specifications. And then the last step...

Manav Gupta: Definitely.

John Capobianco: You do a slash implement so slash spec kit dot implement And the llm takes all the previous specs and plans and tests that you've developed And gives you the outcome the application the software the agent the skill whatever it is. You're trying to build ⁓ I I I really like this approach And I think that it's actually going to turn a lot of network engineers in particular Because they've they've done specs their whole life Network design, network architecture is nothing if not a specification, right? They live and breathe by IEEE specifications, BGP and OSPF. So specifications are going to become very naturally to network engineers, I think. And I think it's going to maybe lead to some breakthroughs.

Manav Gupta: Yeah. Yeah. And I think what's ironic is what you're describing with spectrum driven development. Ironically is this is how software engineers got their lives started, at least in the universities and early projects. You write the spec first to your point, you you write, you write the best, most complete spec you can, then you write the minimal optimal code. It's not the minimal code that fulfills that spec. Right. And then of course, with vibe coding because code generation became so much easier. People sort of got carried away that listen, I can generate all this AI slop. Turns out while you can generate copious amounts of code, you can't really get it to do anything. Nobody can manage it. mean, heck, when I was looking at the cloud code code, which got leaked, it is fascinating. You can see the amount of guardrails they clearly had to put in their own specs because

John Capobianco: Right.

Manav Gupta: If you look at some of the files like the main.tsx is over is almost 5,000 lines long. No human can manage it. It's it breaks every principle of, you know, DRY as an example, single responsibility. It's a massive singleton itself. Anyhow, we're getting sidetracked, but this is so fascinating. maybe a follow up question on why VOPs. So I think ⁓ why coding people are beginning to get comfortable. I really like where you're going with vibe ops. So what happens today, not just network, but in general operations at any large enterprise, there is a ops team. And then to your point with the agile manifesto, everybody moved to agile adopted DevOps, then move people started moving to SRE. Of course, there is still an operations team. You can still say that that ops is part of SRE. I really think. your take on hey, vibe ops will eventually become ops. I think the way to your point, vibe coding is just becoming coding. So do you think that the term vibe ops has a shelf life? Or is it doing important work right now just as a bridge concept until we eventually get there?

John Capobianco: What? ⁓ I just ⁓ thought, so you're right, it might have a shelf life if this sort of becomes the way everyone does it and sort of we look back and think of ⁓ why we needed a special term for it. ⁓ But again, the idea was I used to do and I still do lots of AI demos. And I think there's some power in saying, ⁓ please connect to router one and help me understand the health of my interfaces. You and I understand that right and I didn't have to know any show commands. I didn't have to have any passwords or credentials or Connectivity like there's so much friction eliminated just by using human language and for it to answer In a human voice and say actually, you know gigabit ethernet 2 is dropping packets at this rate You might want to look into it That is powerful, right? And we've tried it a few different ways over the years to get there. ⁓ I think a lot of like, let's say software defined network, right? And we can argue about the success or failure of SDN as a concept where controllers, where you log into a controller and you tell the controller what to do and the controller pushes those configs down. Interfacing with those controllers typically meant XML or REST APIs with JSON. Those controllers now could maybe be repurposed to accept natural language through model context protocol. We don't have to throw the baby out with the bathwater. We just need to upgrade and evolve that whole layer of software defined controllers and give them model context protocol as an interface. I've tried to do that with Netclaw. That's the whole idea. I talked to net claw and net claw can do a CI work in the data center if you need a new You know bridge domain in your ACI you can ask net claw to do that You just ask it because neck because ACI is is rest API first It's it's all API driven and it was easy to build an MCP for for for ACI Right now that alone, right? So I used to do training for ACI to add an interface and an ACI is like seven different GUI menus That's the drawback of SDN is that you either have to drive it through the GUI, menus, menus, submenus, clicking here, remembering where to go, how it all works, or trying to do it programmatically, but now you have to know Python. Right? So this is different. This is a whole new... That's why I think it does need its own sort of terminology. Maybe as an evolutionary point. Maybe after VibeOps, let's hear your point, Manav. Maybe we just call it Ops. Maybe the next step is that we've perfected VibeOps so well, and the artificial intelligence models have become so good. Did you see the news about this new anthropic paper? It's going to be new as of this...

Manav Gupta: Makes sense. Yeah.

John Capobianco: Glassware? Did you read the glassware paper?

Manav Gupta: Yep, yep I was actually browsing through it myself yeah it is fascinating with where they're going with that.

John Capobianco: Yeah, that it's finding flaws in decades old software and languages and things. They're tentative to release it. so powerful, right?

Manav Gupta: I think I mean I had one of my guests couple of weeks ago and she said something profound that at some point we're going to reach a point where The question becomes not can we do it? The question becomes should we do it? Right because we are skirting at that thin edge of the capability of this tech versus the ramifications and in this tumultuous world where What happens with every technological change is regulations tend to lag. Historically, this has been okay because yes, the technological changes are profound, but they're spaced out long enough. The technology is something that most of the humans understand, that we can build academic institutions around it. We can build practices around it. I think this time around, this just feels predominantly different. I mean, since, because you mentioned entropic. with a bunch of the stuff that they're doing, they're now getting an acceleration on their research. So if I can, you know, I believe I read that they're at 1.5x return. So now a researcher is able to do what they could do. For example, in 12 months, they're able to do it in eight months. Now we're getting to real lift. Imagine what happens when you're at 200, 300 % lift, right? The whole paradigm shifts. So planting all of that into your head. I wanna pivot to what I call enterprise reality and governed operations. And I wanna tie this from Netlaw eventually to Itential, but let's start with Netflor in. So something that is so powerful and I really admire you for thinking about Netlaw and not just thinking, but making it happen. And quite frankly, where it is with... all the integrations and the control gating it has, the support for all the MCP servers it has, it's no longer a toy. So when you take something like this into a regulated enterprise, and I know you're a telco guy, but all large organizations, they run their own networks. So what's the first objection you hear from the security or the risk team, and how do you answer it?

John Capobianco: One, think I need to maybe take my role in this and what I've created a little bit more seriously. And there's definitely a difference now in a split between Netclaw and me. It's become really its own entity. And I hope it doesn't turn into a Frankenstein's monster. ⁓ That I lose control of it in some way. So in the Fibops forum just this morning, someone said that they wanted to bring it into production at their enterprise. But that the pushback was that open claw is not secure and that was sort of a brother broad sweeping statement, right? So I Need this to tell both sides of this because I understand I've been in that position and if I was at Parliament right now Try to put myself in my own shoes. Would I turn this on at the Parliament? I you know Maybe in a limited fashion in a lab in a secure completely isolated Offline environment if I could use a gpu in an open source model So netclaw does have that going for it during your installation. You can pick custom model Pointed at olama or lm studio or microsoft foundry and run a local model Offline completely devoid of the cloud so it does have that that capability. I'm proud of that So there are certain certain circumstances where it may be able to be used or if I had a ⁓ trusted key in partnership with let's say Anthropic or OpenAI, right? If my enterprise had that key and I already had the Guarantee that they're not learning from my data and that it's safe and approved for me to use in the enterprise That's the only missing piece You know, ⁓ you can maybe put it in a lab and put a firewall in front of it and see what ports it's trying to use See where it is trying to go really put it under a rigorous test and bring those test results But I think adoption is probably Right knocking on the door. I think people right now are trying to figure out how to solve that problem and how to answer that question Because they do see the value of running this on their network. The other thing is is that I'm investigating Open shell which is an Nvidia ⁓ shell that complements so they have something called a ⁓ Nemo claw

Manav Gupta: Mm-hmm.

John Capobianco: And it's based on the nemo Tron models from Nvidia and has this extra shim called open shell. That is basically the way I see it. Maybe I'm incorrect is kind of like a proxy where all of your commands from open club go through first And you as the human configure your open shell as to what it allow what permissions your claw has access to So I'm investigating whether an open shell complementary ⁓ ⁓ You know a sidecar or or shim or if I add a you know, a new open source project product Project based on open shell for net claw and give people permissions to say you can't talk to ice You can't talk to this that that might be interesting. So so so there's you know for every problem Hopefully there's a solution right? So I'm trying to see the solution to maybe make it something that could be enterprise adopted ⁓ But it's exciting to even know that people think it's so good that it is something they would run on their network. It's a pretty exciting time.

Manav Gupta: No, that's right. It absolutely is. And listen, I think it's equal parts fascinating and to some extent I'll say terrifying because I think eventually again, going back to telco network being a living entity, people's lives are at stake. So we absolutely want to make sure that anything they're putting in that could have a impact, a detrimental impact or even a profound impact on it. We want to make sure that it's secure, it's trusted, we can govern it, we can monitor it. And to your point, You already prescribed sort of a maturity model on how to adopt it and how to start getting, ⁓ how to start using these things. So let's talk about itentials flow AI, which I think is positioned around governed intelligence by design. And I think I really liked the term and you in particular, think are the probably one of the few unique individuals you've lived on sort of both sides and open source community builder, as well as a. enterprise platform. I don't want to call it vendor, but partner. So is governance a feature you add to agent tech operations or does it have to be or does it have to be foundational from day one?

John Capobianco: So I think it's. I absolutely I was going to say I think it needs to be foundational. So I potential adds the you know and it's It's not the sexy stuff and it is grounded in reality, right? So as much as a dreamer I am and the amazing things I'm able to pull off in an enterprise, we need things like audit trails and guard rails, exactly how many tokens we used, what the input was, what the output was for every turn, let's call it, the human's input and the LLM's output. We need to be able to control the data sources through our back. We need to be able to find grain access to MCP tools. So as you know, MCP is client server. And when you connect with a client, the server advertises all of its tools and typically binds all of its tools to the agent. want it. We at selector or at I-Tential, excuse me, we have the ability to find grain and pick the actual tools we want to bind to the workflow. Now, the real exciting thing is that I-Tential has 10 years of network automation workflow experience. With hundreds of adapters and hundreds of REST API integrations all of those things become available to the agent now as well So itential has its own MCP which uses OAuth 2 and it binds securely with RBAC access Well, I actually tried to break it so I made a Flow AI agent with access to a particular workflow and then I tried to invoke it through the netclaw because netclaw has itential integration, which is pretty neat from your netclaw you can build workflows. But the netclaw didn't have the OAuth permission, the actual fine-grained access to the workflow that it tried to access, and the potential flow agent denied access to it. So it's respecting even agent-to-agent calls. If it doesn't, you know, if it's part of the RBAC group, it doesn't have access to the tools, so it will deny it, right? So we want to make it easy though. We want to make it where you can bring your own agent, build your own agent, bring your own MCP servers, much like I-Tentials let you bring your own Ansible playbooks and Python scripts and Terraform code into the platform. So we centralize it. We put the guardrails around it. We put the R back and the AAA around it. And we make it reusable. We make it composable. We make it so you can build workflows and attach these things together. And you can run these workflows scheduled on demand. They're item potent workflows. They will do the same thing every time. ⁓ But now once you have that workflow, we can let an AI agent determine when it's best to run that workflow. Right, so you may have a, to the point of the inbound triaging agent, that's what that agent might do. That agent might make the ServiceNow ticket. It may update the ServiceNow ticket. It might have read-only access to certain parts of the network through other MCPs or API calls. And it comes to the determination on what the root cause might be. It sends the Slack message, it sends the email, it amends the ticket, it waits for input back from the user. Is the problem resolved? this fix? Can you try it now? Truly a digital co-worker in a platform that you have full guardrails and full control over. And we mentioned spec-driven development. To build those workflows that I was talking about, you can do it all through spec-driven development now. On itentual's GitHub right now, we have the spec-driven development kit for itentual. And you develop through a few simple prompts. and it will build the workflow that I just described just using spec and natural language. It's all in Git. It's all version and source controlled. So we're moving away from no code, low code, which is still an option to drag and drop workflows together. And we're moving into spec driven workflows. ⁓

Manav Gupta: ⁓ thank you. think this was fantastic. So two other questions as we close this out. So one a prediction and the second is your guidance for others that are starting out. So let's start with the your boldest prediction. Yes.

John Capobianco: So my boldest prediction is that by 2030, I would suggest that 70 or 80 % of this, what we're talking about infrastructure, is going to be fully agentic. It's going to be humans. I'm not saying, and don't immediately associate that with job loss. I know people think of the negative of that. We're not going to see people lose their jobs because of that. It's going to be like Excel with accounting. Okay, accountants didn't just disappear when they suddenly had Excel at their fingertips, right? They elevated their positions. They became more strategic. They became more about the direction of the organization. They became a higher level function than previous to the spreadsheet. So now network engineers are going to be building agents and those agents are going to be doing the infrastructure for them. that by 2030, you know, and that's not going to cause a lot of job loss, but it's going to, it's, we're going to need to rethink things, right? So, so Minov, to your point, the models in 2030, who knows what they're going to be capable of, but even just with today's models, these agents can do very, very powerful things. So I think, We need to rethink the role of the network engineer as more of a human resources function in the organization who's taking care of agents. And I think that's a big change, but I think our functions are gonna change.

Manav Gupta: I agree. Okay, so network engineers will be building agents will have proliferation of agents of all sorts everywhere in the network and we'll have to rethink the role of network engineers. I think those I can stomach and agree with. Now, John, you obviously are a fountain of knowledge. You know, so many things about so many items being this storied and so deep and obviously the passion is just seeping through the screen. But for those that are starting out. And I can probably attest to this a little bit because I was lost as a puppy when I started working with clients in the telco industry. What do you tell those that are starting their careers early in their journey? Where do they begin?

John Capobianco: Right so early in your journey I think that you have so access to knowledge. Has it's never been more accessible the knowledge that you need and the resources available to you And now you have access to artificial intelligence in your early early in your career so foundational knowledge is still Absolutely required right? I'm the last person to tell you not to pursue Your certifications in the industry, right? And if you're early in your career, that might mean you're a plus that might mean you're n plus that might mean you're ccna mid-career it might be might mean your professional level. Later in your career, it might mean your expert level. I think those are still extremely valuable. But as you pursue them, now I would use artificial intelligence to augment your studies, to help you with flashcards, to help you with memorizing key protocols and ports. you have an expert at your fingertips now. The other thing is become proficient at things like prompt engineering. at making a REST API call against an LLM and accessing it programmatically. Start adding MCP tools into your copilot, into your cloud desktop. And if you're saying to yourself, what's cloud desktop? What is copilot? Like I know that there's a lot of people that this is new and I've been doing it for about three years now. The train is still really close to the station, everyone. And that's what I mean by optimism. If we go backwards, Spectraven development is less than six months old, ⁓ practically speaking. ⁓ Model context protocol is about 16 months old now, less than two years. Retrieval augmented generation is about two years old. Chat GPT 3.5, which I think is like, and I'm not trying to be crass here, but to me reminds, it's like the atomic bomb going off. I think there's a pre and a post November, 2022. ⁓ Period in human history like when that came out that was a human inflection point that changed more than just technology The whole world is still reeling from what that means to live in an artificial intelligence world So again, I know Google I know I'm a Google developer expert now, but I really do not consider myself an expert I consider myself curious. I consider myself a builder and explorer And I want to do it together. That's why I made the VibeOps forum because I think we're all, Manav, like you would agree, you are just trying to figure this out yourself, right? I am just trying to figure this out myself. There's something new every hour, every day, every minute. And I think we're all just trying to do our best, you know?

Manav Gupta: John, couldn't agree more. And listen, this is exactly the episode I wanted to make someone who's not just talking about the future, but actually shipping AI and you're actually doing it, you know, seven years a week or to quote your natural article six days at a time. John, want to thank you sincerely for your time, the enthusiasm, the energy that you spend and really the candor with which you shared all your knowledge for listeners. Links to Netlaw on GitHub, the YWAP's forum, John's Automate Your Network website. I'll have it all in the show notes. If you're a network or a infrastructure leader and you haven't looked at what's possible, now's your nudge. John, what's the best place for people to find you and follow what you're building?

John Capobianco: Please follow me on LinkedIn. I think that's my central place and on Twitter and suddenly automate your network.ca is relevant again. Now I'll leave you with this Manav. This is a trick of mine that I just figured out. There is a WordPress MCP. Okay, so I added the WordPress MCP to my CLAWD code and now at the end of every vibe coding session and every SDD session I do, I say can you please write the blog for me summarizing our activity here today. So that's how I get so many blogs written today is because I'm using to recap our Vibe Coding sessions, our VibeOps sessions together. Namanav, I am sincerely grateful for this platform and for you having me in your leadership as a Canadian technologist, your work with IBM, the work you've done in the field. I also want to invite you to a tour of the Parliament if you're ever in Ottawa. Just let me know if next time you are in Ottawa, we will go downtown and have a coffee and I'll give you a tour of the Parliament.

Manav Gupta: I would love to take you up on that, for sure. I love it, John. Thank you so much. And I hope to bring you back sometime in the future. We have lots to discuss. Thank you. Absolutely. Thank you.

John Capobianco: All right. Thank you. I'm game anytime at all. Thanks again. Take care.