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

0:00 Introduction: Meet John Capobianco, Head of AI at Itential
1:50 What Is the Current State of Network Automation?
9:53 How Can AI Act as a Digital Coworker for Network Engineers?
15:22 What Is NetClaw? The Open-Source AI Network Agent
22:31 How to Establish Trust in AI-Driven Network Automation
28:21 A Maturity Model for AI Adoption in Network Operations
29:50 What Is VibeOps? Natural Language for Network Operations
32:50 Spec-Driven Development for Network Automation
46:49 Governance and Guardrails for Agentic Network Operations
51:26 The Future of Network Engineering: AI Agents by 2030

Manav Gupta • 00:10

What if your network had a CCIE level engineer on call, one who never sleeps, never mrs. a BGP state 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 think. I today have the pleasure of hosting John Capubianco, who is the head of AI and developer relationship at iTential, 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 an open source AI agent inspired by OpenClaw that claws through your network. And he’s also the founder of Viwops Forum, a community that went from what I can tell zero to 400 plus members in weeks.

Manav Gupta • 01:16

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 Shiperi. And John, welcome to the show.

John Capobianco • 01:50

Manav, thank you so much. And what a wonderful introduction. I really, you know, take it, I 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 Vibe Ops forum has grown.

John Capobianco • 02:15

My NetClaw has gotten really international attention. I think the general mindset has started to shift to acceptance of artificial intelligence 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 • 02:38

Yep, absolutely. And listen, I really like that you started that. This is going to be a story of optimism and hope and opportunity. I got to 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 going to start with what I call the builder’s origin, because I really think that you truly are a builder.

Manav Gupta • 03:04

So you’ve been in the networking industry for 25 years. You’ve been at Cisco, Parliament of Canada, Selector AI, and now at iTential. 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 operation side?

John Capobianco • 03:30

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 particularly bulletin board systems. Now, that’s I know a lot of people maybe have never even heard of what a bulletin board system is, but when I was very young, like as a child, my brother and I got access to a 286 computer. Oh my God, that is going back some time. Yeah, 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.

John Capobianco • 04:15

And we could exchange files and have conversations. And we had 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 were a lot of opportunities in programming.

John Capobianco • 04:59

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 Wi-Fi, some voice over 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 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.

John Capobianco • 06:12

And now, you know, 10 years into network automation as a proven discipline, like you mentioned in the intro, only 30%, according to the network automation form study, roughly 30% are doing something meaningful with automation. And I sort of look at the 70% and I wonder what’s holding them back. What are the constraints here? I’ve given it a lot of thought. And I’m not sure, Manav, 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 Ansible and Python and all of these frameworks?

Manav Gupta • 06:55

No, so I think it’s multiple factors. I 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 it’s even near 20%. I think telcos are trying constantly. And John, you’re a man after my own heart.

Manav Gupta • 07:20

I spent over a decade in telco, so I know a thing or two about network automation, configuration, 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 innovator’s dilemma.

Manav Gupta • 08:02

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 got to 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 call my telco, which 1st 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 resolved.

Manav Gupta • 08:43

That’s the reality that we have all accepted.

John Capobianco • 08:48

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?

John Capobianco • 09:11

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 about, let’s say, BGP or OSPF or whatever it is in their sphere, 20, 15, 10 years of network experience, they can use that, right? That’s what is being filtered through to their prompts and to the way they can build agents now, right? So, the good news for the, for the, you know, everyone’s understaffed.

John Capobianco • 09:53

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 like to think of it as 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 gonna have my five or 10 agents, right? And individual operators and network architects and engineers and designers, right?

John Capobianco • 10:34

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 the magic unicorn agent that does absolutely everything. 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. If there’s a deficiency in your, here’s a good example.

John Capobianco • 11:17

Cisco, there’s an article on their webpage offer just 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.

John Capobianco • 11:53

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. Within VS Code, there’s a co-pilot 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.

John Capobianco • 12:25

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 were moving very fast, Manav. And 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 its architecture is that it’s all modular and it’s built on skills and MCPs.

John Capobianco • 12:56

So as these open source MCPs come out, that are, you know, 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.

John Capobianco • 13:21

Anyhow, so it will evolve. It’s kind of like a lobster. I like this OpenClaw 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?

John Capobianco • 13:43

Oh, yes, my friend. I am 3D. It’s not, it is a very sophisticated tool, right? Like Blender is not a very simple, easy. 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 • 14:10

3D 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 2H6 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, you know, quite candidly, I’ve been playing with OpenClaw quite a lot. I got into some trouble as well because, hey, you know, that’s the nature of these things.

Manav Gupta • 14:46

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 Night Law. Which was intern, of course, as these things go by, Netclaw itself, which documents what you shipped in less than a week. It had a whole bunch of skills and domains. It had the 1st community pull request. So, walk me through the inspiration for creating Netclaw and what were you trying to accomplish or prove with that project?

John Capobianco • 15:22

Well, what I had seen in OpenClaw, one, the popularity, and one, the opportunity. And it wasn’t just about hype. It’s not just because I’m chasing the next hot thing. You know, 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 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?

John Capobianco • 16:14

I don’t have to write the Telegraph or the WhatsApp or the Teams or Google chat. All of the supported platforms from OpenClaw 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 PyETS. So here’s my book.

John Capobianco • 16:41

I’m the author of the Cisco PyTS book. Hard to see with the blur. But I always, that’s always my inspiration is to see if I could connect PyETS to OpenClaw. And then, and then it was more MCPs and more skills. And eventually I thought, okay, I’m going to call this NetClaw. It’s an OpenClaw implementation to claw through your network. And I use the Slack channel.

John Capobianco • 17:06

So it’s actually live. I typically have a live Netclaw in the VibeOps 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 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 that were just saying I’ve just spun up my 1st NetClaw and I’m actually talking to my network through telegraph on their phone, on the fly.

John Capobianco • 17:39

It’s really exciting to me to think that this little project, it really was what if I could connect PyETS 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 Maniak, another Canadian manav. You might want to have Sebastian on here next. He’s a wonderful guy.

Manav Gupta • 18:05

That would be amazing. Yes.

John Capobianco • 18:06

He hosted an OpenClaw meetup in Toronto, the 1st 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, you know, the obvious question I 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 claw questionnaire and then a netclaw questionnaire. I call it a questionnaire because you get to pick what API keys, what services, what you want to connect to PyETS. It’s a la carte. 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.

John Capobianco • 18:49

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 you as a because it’s open source, have c 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 back end. 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.

John Capobianco • 19:38

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. Yeah.

Manav Gupta • 19:51

I think that’s the key. And 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’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 • 20:31

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.

John Capobianco • 20:56

I’m still paying attention. Maybe it’s making tickets for me. Maybe it’s sending email recaps. Maybe I’m just sort of monitoring it loosely. And then there’s full autonomous, full, whatever the agent’s doing, it’s doing. I trust it like a coworker or a subordinate worker, let’s call it, right? And it’s funny enough, not funny, but kind of prophetic.

John Capobianco • 21:17

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 human, more of a an org chart and an or a human org, right? Like, so if I have those five agents, they sort of report to John. And John is responsible, the 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?

John Capobianco • 21:56

But we all want to collaborate. We don’t want to have overlapping agents. And this is what I like about Itential: 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 where we’re moving to, and it’s going to be human.

John Capobianco • 22:22

And then, like you said, that war room, that WebEx caller, this Zoom might have three or four agents in it, and they participate just like people. Exactly.

Manav Gupta • 22:31

But the crux of all this boils down to the critical fact that the network is a living entity, right? And I think a lot of times 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 jitter and latency, you know, things that only the technical folks know. But eventually on the consumer side, it boils down to can’t do my job, taking too long, or I get disconnected.

Manav Gupta • 23:21

So, how do you establish the critical word in your description you used was trust? How do you establish trust?

John Capobianco • 23:29

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 Arbix 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, so as of ChatGPT 01, the 01 model introduced this idea of reasoning, where instead of where you ask an LLM a question and it 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.

John Capobianco • 24:18

So 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.

John Capobianco • 24:47

So documentation of your network, reconciling with your sources of truth, maybe building your 1st source of truth, a 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. Right? So maybe that is where you start as an organization: to get its opinion, not to let it change or remediate or to fix. That’s where something like, you know, like I said, with an Itento platform, it’s totally flexible. So you could start with a read-only agent.

John Capobianco • 25:35

Here’s a practical example. I made an agent that can read the network interfaces and IP addresses. So using PyETS as an MCP, it 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.

John Capobianco • 26:16

And there’s going to be more videos and content about that out there. I like pass-fail tests. My very 1st Itential Flow AI agent, I had it connect with PyTS and I said, go tell me, you know, are 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 guardrails 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’ve had this discussion with someone else actually just yesterday.

John Capobianco • 26:55

Maybe a better analogy for people to absorb. What was one of the 1st things you would give a junior engineer if you hired a junior network engineer? What would you have them do? 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. Here’s the link to the documentation folder. Here’s your login and password into the network.

John Capobianco • 27:26

For the 1st 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. That’s why. Right? Because you don’t know their skill. They don’t know the network. You haven’t established trust.

John Capobianco • 27:40

So, why not do the same thing with that AI agent? Bring on an AI agent, and what its 1st primary purpose is doing compliance, let’s say, right? Are your 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 a little bit more, more risk, maybe take on more risk, as we would say, as you’ve earn trust and know how to prompt it, know how it works, understand the technology you’re working with. Right?

John Capobianco • 28:21

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, Manov, 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.

John Capobianco • 29:06

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 • 29:18

I think it absolutely does. I love the maturity 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 VibeOps. I know, I mean, I did some Google foo, 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 • 29:50

Well, a couple of things. I wanted to marry the idea of vibe coding. And it’s funny, now vibe coding, I 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.

John Capobianco • 30:12

And with an approach that follows things like. You know, like I go all the way back to the Agile Manifesto. That had a big impact on me moving to Agile and CI CD 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.

John Capobianco • 30:43

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 VibeOps, but AIOps is kind of the machine learning and the generative AI, right? So ingesting lots of data, you’re 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 VibeOps portion is using natural language to use model context protocol, the protocol itself, and AI agents.

John Capobianco • 31:18

Where we introduce sort of a 3rd party into our approach, where network automation and even human, or so, even before network automation, humans write SSHing into 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 Ansible, or you had to know some Python and some PyETS or Nornier or whatever. So there was some friction there that it was still highly coupled to the network engineer.

John Capobianco • 32:03

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. 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, SDD. So if anyone listening has not heard of this, don’t feel bad. It’s only six to eight months old. The official GitHub SDK, and it’s called SpecKit on GitHub, and you should go find it. It’s about six months old.

John Capobianco • 32:50

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 a 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.

John Capobianco • 33:36

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. There are these wonderful markdown specifications. And in the last step, you do a/implement , so/spec kit.implement . And the LLM takes all of 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 really like this approach. And I think that it’s actually going to turn a lot of network engineers in particular because they’ve done specs their whole life. Network design, network architecture is nothing if not a specification, right?

John Capobianco • 34:25

They live and breathe by IEEE specifications, BGP and OSPF. So specifications are going to come very naturally to network engineers, I think. And I think it’s going to maybe lead to some breakthroughs.

Manav Gupta • 34:38

Yeah, and I think what’s ironic is what you’re describing with spec driven development. Ironically, this is how software engineers got their lives started, at least in the universities and early projects. You write the spec 1st , to your point. You write the best, most complete spec you can, then you write the minimal, optimal code, if 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.

Manav Gupta • 35:17

I 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 if you look at some of the files, like the main.tsx is almost 5,000 lines long. No human can manage it. It breaks every principle of DRY as an example, single responsibility. It’s a massive singleton itself. Anyway, we’re getting sidetracked.

Manav Gupta • 35:48

But this is so fascinating. So maybe a follow-up question on VibeOps. So I think Vibe coding, people are beginning to get comfortable. I really like where you’re going with VibeOps. So what happens today, not just network, but in general operations at any large enterprise, there is an ops team. And then to your point, with the Agile Manifesto, everybody moved to Agile, adopted DevOps, then people started moving to SRE. Of course, there is still an operations team.

Manav Gupta • 36:21

You can still say that Ops is part of SRE. I really think your take on, hey, VibeOps will eventually become ops. I think the way, to your point, Vibe coding is just becoming coding. So do you think that… Do you think that the term YbOps has a shelf life, or is it doing important work right now just as a bridge concept?

John Capobianco • 36:48

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, you know, 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.

John Capobianco • 37:20

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?

John Capobianco • 37:51

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 my Netclaw. That’s the whole idea.

John Capobianco • 38:34

I talked to Netclaw, and Netclaw can do ACI work in the data center. If you need a new bridge domain in your ACI, you can ask Netclaw to do that. You just ask it. Because ACI is REST API 1st , it’s all API-driven. And it was easy to build an MCP for ACI. 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.

John Capobianco • 39:03

That’s the drawback of SDN: you either have to drive it through the GUI, menus, 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 VIBOPS, let’s see your point, Manov. Maybe we just call it ops.

John Capobianco • 39:34

Maybe the next step is that we’ve perfected Vibe Ops 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 Glassware. Did you read the Glassware paper?

Manav Gupta • 39:53

Yep, I was actually browsing through it myself. Yeah, it is fascinating with where they’re going with that.

John Capobianco • 40:00

Yeah, that it’s finding flaws in decades-old software and languages and things. They’re tentative to release it. It’s so powerful, right?

Manav Gupta • 40:13

I think, I mean, I had one of my guests a 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 lie. Historically, this has been okay because yes, the technological changes are profound, but they’re spaced out long enough. The technology is something that humans, most of the humans, understand it, that we can build academic institutions around it. We can build practices around it.

Manav Gupta • 41:05

I think this time around, this just feels predominantly different. I mean, since because you mentioned Anthropic, with a bunch of the stuff that they’re doing, they’re now getting 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, e.g. , in 12 months, they’re able to do it in eight months. Now we’re getting into real lift. Imagine what happens when you are at 200, 300% lift, right? The whole paradigm shifts.

Manav Gupta • 41:38

So, planting all of that into your head, I want to pivot to what I call enterprise reality and governed operations. And I want to tie this from NetClaw eventually to Itential, but let’s start with NetFlaw again. So, something that is so powerful, and I really admire you for thinking about NetClaw 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 1st objection you hear from the security of the risk team, and how do you answer it?

John Capobianco • 42:33

That is so it the so I’m one, I think I need to maybe take my role in this and what I’ve created a little bit more seriously. You know, I and there’s definitely a difference now in a split between NetClaw and me. It’s become really its own entity. It’s that, you know, and I hope it doesn’t turn into a Frankenstein’s monster, you know, and that I lose control of it in some way. But I do saw, so in the Five Ops 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 the broad sweeping statement, right? So

John Capobianco • 43:16

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, trying to put myself in my own shoes, would I turn this on at the parliament? Maybe in a limited fashion in a lab, in a secured, completely isolated offline environment, if I could use a GPU and an open source model. So Netclaw does have that going for it. During your installation, you can pick a custom model, point it at Olama or LM Studio or Microsoft Foundry and run a local model offline, completely devoid of the cloud. So it does have that capability. I’m proud of that.

John Capobianco • 43:58

So there are 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 in running this on their network. The other thing is, is that I’m investigating OpenShell, which is an NVIDIA.

John Capobianco • 44:52

A shell that complements. So they have something called NemoClaw. And it’s based on the Nemotron models from NVIDIA and has this extra shim called OpenShell that is basically the way I see it, maybe I’m incorrect, is kind of like a proxy where all of your commands from OpenClaw go through 1st , and you as the human configure your OpenShell as to what it allows, what permissions your claw has access to. So I’m investigating whether an OpenShell complementary, you know, a sidecar or shim, or if I add a, you know, a new open source project product project based on OpenShell for NetClaw and give people permissions to say you can’t talk to ICE, you can’t talk to this. That might be interesting. 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.

John Capobianco • 45:55

But it’s it’s exciting to even know that people think it’s it’s it’s it’s so good that it is something they would run on their network. It’s a pretty exciting time.

Manav Gupta • 46:04

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 we’re putting in that could have an 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 Itential’s Flow AI, which I think is positioned around governed intelligence by design.

Manav Gupta • 46:49

And I think I really like the term. And you, in particular, I think are probably one of the few unique individuals. You’ve lived on sort of both sides: an open source community builder as well as an enterprise platform. I don’t want to call it vendor, but partner. So, is governance a feature you add to agentic operations? Or does it have to be, or does it have to be foundational from day one?

John Capobianco • 47:16

I absolutely, I was going to say, I think it needs to be foundational. So, Itential adds the, you know, and 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 guardrails, 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 fine-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. We want it, we at Selector or at Itential, excuse me, we have the ability to fine-grain and pick the actual tools we want to bind to the workflow.

John Capobianco • 48:15

Now, the real exciting thing is that Itential 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. 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.

John Capobianco • 49:00

And the Itential Flow agent denied access to it. So, it’s respecting even agent-to-agent calls. If it doesn’t, you know, if it’s not 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 Itentials 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 RBAC and the AAA around it.

John Capobianco • 49:35

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.

John Capobianco • 49:58

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 might 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.

John Capobianco • 50:26

Is the problem resolved? We’ve done this fixed. Can you try it now? Truly, a digital coworker 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 Itential’s GitHub, right now, we have the spec-driven development kit for Itential, and you develop through a few simple prompts, and it will build the workflow that I just described just using spec and natural language.

John Capobianco • 50:59

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 • 51:12

Oh, Don, thank you. This was fantastic. So, two other questions as we close this out. So, one, a prediction, and the 2nd is your guidance for others that are starting out. So, let’s start with your boldest prediction.

John Capobianco • 51:26

So, my boldest prediction is that by 2030, I would suggest that 70 or 80 percent of this, 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?

John Capobianco • 51:59

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. I think 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 Manav, to your point, the models in 2030, who knows what they’re going to be capable of.

John Capobianco • 52:32

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 going to change.

Manav Gupta • 52:55

I agree. Okay. So, network engineers will be building agents. We’ll have a 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.

Manav Gupta • 53:11

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? Right.

John Capobianco • 53:38

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 and you’re 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 your A, that might mean your N plus, that might mean your C CNA. Mid-career, it might be, might mean your professional level.

John Capobianco • 54:17

Later in your career, it might mean you 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. And 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?

John Capobianco • 54:58

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, Spectrum 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.

John Capobianco • 55:28

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.

John Capobianco • 56:04

I consider myself curious. I consider myself a builder, an explorer, and I want to do it together. That’s why I made the Vibe Ops 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 • 56:26

John, I 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 days a week, or to quote your NetLaw article six days at a time. So, John, I 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 NetClaw on GitHub, the YWPS forum, John’s Automate Your Network website. I’ll have it all in the show notes.

Manav Gupta • 57:03

If you’re a network or an 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 • 57:13

Please follow me on LinkedIn. I think that’s my central place and on Twitter. And suddenly, automateyournetwork.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.

John Capobianco • 57:27

So I added the WordPress MCP to my Claude 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 AI to recap our vibe coding sessions, our Vibe Ops sessions together. Now, Manav, I am sincerely grateful for this platform and for you having me and 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, I just love this. 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 • 58:11

I love it, John. Thank you so much. And I hope to bring you back sometime in the future. We have lots to discuss. All right. Thank you. I’m game anytime at all.

John Capobianco • 58:19

Thanks again. Thank you. Take care.