The Networking for AI Summit | Anil Varanasi, Meter

Clips
More from The Networking for AI Summit

Anil Varanasi

Founder & CEO

Meter

play_circle_outline Introduction of Anil Varanasi and Meter Command at Networking for AI Summit.

play_circle_outline Navigating Trust: The Need for Specialized Networking Models Over General-Purpose AI in Driving Application Performance

play_circle_outline Command supports team-based operations and collaboration among network engineers.

play_circle_outline Early adoption stories highlighting customer and partner experiences with Meter Command.

play_circle_outline Internal use of Command for support and operations to improve customer service.

Info
Transcript

Anil Varanasi, Meter

Anil Varanasi

Founder & CEO Meter

Purpose-built AI for networks takes center stage in this round of the Networking for AI Summit interviews. Anil Varanasi, co-founder and CEO, Meter, joins theCube’s Bob Laliberte to unpack why Meter Command uses networking-specific models instead of general-purpose LLMs. Varanasi explains how Command interprets natural language, retrieves precise network context, takes validated actions and even writes software on the fly. He details the human-in-the-loop safeguards that confirm intent, preview repercussions and keep production environments safe. The discussi... Read more

explore Keep Exploring

What are the reasons for developing Meter Command specifically for networking, and what limitations do general-purpose models have for this use case? add

What concerns might arise from using a language model in contexts it wasn't specifically designed for, such as driving a car or managing a network? add

What is the role of collaboration and knowledge sharing in team-based operations within IT, and how does Command facilitate this process? add

What are the key use cases observed for networking teams and partners using a specific tool or platform? add

What are some internal use cases of the Command model since its launch? add

bolt Powered by CUBE AI

Anil Varanasi, Meter

search

Bob Laliberte

>> Welcome back to the Networking for AI Summit. In this session, we're joined by Anil Varanasi, the co-founder and CEO of Meter to discuss Meter Command. Welcome, Anil.

Anil Varanasi

>> Hey, Bob. Thanks for having me.

Bob Laliberte

>> Yeah. Great to have you back on. Just like Meter's hardware and operating system, Command's also built from the ground up to address a lot of the unique needs of networking teams. So I'm hoping in this video, we can discuss why the general purpose models aren't completely sufficient and how Command and really enables that natural language queries, enables complex actions across the whole stack, and explore some of the implications for the future of network operations. So Anil, you've built Meter Command, as I mentioned, from the ground up, rather than relying on the APIs from any of the existing AI providers. Why did you believe that networking required its own dedicated models? What limitations did you think existed in some of those general purpose LLMs for this use case and what were some of the results that you're seeing as a result of building it yourself?

Anil Varanasi

>> Maybe building the case through analogy. I'm curious how much of the audience, either listening to this or watching this video, would be comfortable if we took a chat LLM and put it in one of their cars and said, "Drive it." I don't think... Not that many people would be comfortable getting behind the wheel of a Tesla or a Waymo if it was driven by a language model that's not built for it. Similarly, none of us in networking should trust models that are not built for networking to be able to actually take action on a network, drive a network to the outcomes that are needed, and have precision and accuracy for the actions that need to be taken. So we really believe that is important, not just for Meter, for our industry as well, to be able to have models that we can really rely on. So that they actually help augment network engineers as much as possible. One of the greatest pitches of all time in computing is Douglas Engelbart and, I think, his great essay on augmenting human intellect. It's sort of the right approach. Can we build great models to augment what network engineers do? But we should also have models that they can trust and rely on. And yeah, like I was mentioning, we wouldn't take a chatbot and let it drive us. So why would we let them drive our networks?

Bob Laliberte

>> Yeah. No, I think that makes a lot of sense. And no, I don't want a large language model driving my car, me. And certainly don't... I don't think I'd also want it driving my network. I guess the other question might be, here, is do you see a future where the network-specific models will be integrating with broader LLMs for hybrid use cases or do you think that they need to still remain fully independent?

Anil Varanasi

>> Yeah. I think it'll be fully independent. There might be some odd job use cases on... Whether it's summarization or text or something like that, that you can use the generic models for. But again, we should require our industry to have great models that we can rely and trust on for the long-term. Most crucial pieces in entire infrastructure, everything in the world is packets, and it's our responsibility as practitioners, operators ,and vendors in networking to provide great outcomes for the rest of the world. And so, I think there will be some there. But really, great foundation and frontier models for networking is the future, I think.

Bob Laliberte

>> Got it. Got it. When we've been talking earlier, you had mentioned about the network engineering resources and how so many are starting to age out and retiring from that. And as this happens, obviously, it's a big transformational aspect that's occurring right now. And it's really going to change the way IT teams manage and interact with their networks, right? You're not going to have those CLIs and things like that and those traditional dashboards. Can you talk about how Command is going to enable more natural language queries, more... The ability to handle complex actions across the whole stack?

Anil Varanasi

>> Yeah. I do think what language models are phenomenal at is the language part is understanding human intent on what they are trying to say and being able to synthesize that properly. And you're absolutely right. If you look at the last 40 years, we had CLI dominate the industry predominantly until Meraki came along maybe 15, 20 years ago, and said, "Hey, this should actually be a web app that I should be able to access from anywhere in the world, without having to go and type in commands into CLI to even have a view of my network." Sort of if I'm having my morning coffee, I just go to a dashboard and understand whether I have one location or a thousand locations, what's actually happening with these. But what dashboards are really good at is being able to supply specific information that you believed was important ahead of time or you believed to set up some alerts and thresholds ahead of time. But with the way networking is changing in a few different vectors, one is complexity of networking is increasing. Two, the number of people and data and application on a network is increasing. And overall, the... On all networks it's increasing dramatically. And then, three, like I was mentioning separately in a different conversation that we're having, is that the number of network engineers in the world is going down, not up. So what we've done with Command is really think about is if we had CLI, we had dashboards, what's the next iteration of that after? So Command has the ability to take in natural language to then be able to do three important things. First, it can get information. Users can say, "Hey, the switches that I have all the way out of New York, I'm living in California, in my location in New York, what's happening with these switches that have to do with STP? Give me some information." You can get information back. Second is Command enables to take action. You can put in something as complex as saying, "Create a new SSID called Bob. Make it have it so that the password auto rotates every day at 2:00 AM. Make sure it's in all APs and broadcast is only on 5 gigahertz. And guess what? I want the password to be WPA2 and the password is this, this, this." Usually, if you want to do that across, let's say, 1,000 APs or something like that across 100 locations, either you're doing that manually across each of these parts of the dashboard or you're writing some scripts or something like that. Command is as easy as putting in a ticket. What I just said, if I had typed it and just typed it in, it can go take that action. And the last thing that Command can do is actually just write software entirely on the fly. We believe software should be soft and that it should be delivered to end customers the way they want it at the moment they want it. So our models are trained on not just our hardware architecture, our data pipelines and software, but also how we design and write software as well. To then be able to say, for example, if you're like, "Hey, I really care about this one particular client right now, I want TX charts, RX charts, I want to know what's happening with SNR," as fast as a Google search, Command will write that software and just show it to you. And you can build the dashboard the way you want it to be. So it's getting information, taking action, and writing software all from natural language with models that are built, eval-ed, and trained on our data, our architecture, our design.

Bob Laliberte

>> Got it. Got it. Okay. So that sounds pretty cool. One of the things I wanted to talk about though or maybe think of is that... Obviously, when you're making changes to a system, especially network that's supporting a production environment, any error is going to have pretty major consequences for that business. So I'm wondering if you can share how you're making sure that there's safeguards or any kind of validation mechanisms that are built in to Command to make sure they catch any mistake. Like, "Hey, are you sure you want to do that?", or, "Are you really sure you want to do that?", before anything happens so that organizations don't very quickly create a problem for themselves.

Anil Varanasi

>> Yeah. That's precisely how we have it which is something goes in, Command reviews it, confirms it, then writes the software on the fly for the form that's needed. Fills out the form, presents it to the user to be able to confirm it, then even on execution, summarizes the repercussions of it, of that action, before actually taking it. So that's precisely the flow that we have.

Bob Laliberte

>> Got it. Yeah. So that human in the loop, I think, is what's so important for so many of the operators today. And I think it's also critical for the vendors like yourself to get those highly experienced operators looking over these and providing feedback on it as well. And I think, like I said, a lot of these big transformations, the technology part sometimes is the easier part and the harder part is the cultural one for someone who has been doing CLIs for 20, 30 years to now have to switch over. Again, it all comes down to that, "What's the time to trust and the time to validate?" I'm wondering if you can comment on what you're seeing with these network engineers when they first get their hands on this and they start going through it.

Anil Varanasi

>> I think you're absolutely right. It's usually skepticism to start.

Bob Laliberte

>> Yeah.

Anil Varanasi

>> And by the way, I totally get it. We are in an industry where everything is AI and people are just pushing out buzzwords and vaporware and demoware. As an engineer, of course, people are skeptic to start. I think I would be too. But what we've seen is as they try things out, they're like, oh, I gave it a simple thing. It did it. Let me try an even more complex thing. And Command being able to handle that at a degree that is not just unique in networking, but unique in general to be able to take action on production systems like this in the entire technology, I think that part has been how people get comfortable but definitely skeptical to start and I totally understand why.

Bob Laliberte

>> Yeah. And like I said, it's going to take time but it is going to be critical. And I think... Again, those senior engineers, I believe, have a vital role to play in the validation of the technology and helping to improve the models by finding them... If there is a problem, to be able to report back and say, "Hey, I've seen this before. Here's what's happening." I also think that from that cultural standpoint, there's going to be certain mundane routine tasks that they'll be more accommodating to letting automate and go through while they're still handling the more complex issues on their own, until they're fully validated and trusted.

Anil Varanasi

>> Yeah. I mean, it's how we do any system, right? If you think about how humans know how to ride a bike, you start off with training wheels, then a parent or an older brother or older sister is holding your bike. Then you finally are like, "Okay. I can ride on my own." I think in any system that we all use, any system we all trust, it's levels to it. And as you gain confidence, how you build trust.

Bob Laliberte

>> Yeah. No, I think that makes a lot of sense. I mean, one of the things in IT, certainly, it takes a village, right? IT takes a village. And so, there's a lot of collaboration that takes place within all the operations teams. How does Command support the team-based operations and knowledge sharing across an organization?

Anil Varanasi

>> Yeah. This is something that we think is the future of where software is going in general and I think, certainly, networking. Command, along with having this natural language interface, has a canvas right next to it where the software it writes can be pulled over but that canvas is actually an entirely multiplayer environment. So multiple people can come in, put in their own software that they generated with Command, build dashboards together, debug together. And a lot of it actually came from is how we all learned in labs together. When you learn networking, even though, yes, networking is not taught in universities anymore. But even when I learned networking, you're sort of in a lab, it's try to do something, and maybe you have a colleague peer over your shoulder, try to help you or debug together. We wanted that same experience to be there in Command where the environment is entirely multiplayer. And you might be sitting in California, somebody might be sitting in New York, or somewhere else, but being able to collaborate together to debug and also have software written for you at the speed of a Google search to be able to build dashboards the way you want, actions the way you want, we think that's critical in not just networking and Command but where software is going overall.

Bob Laliberte

>> Yep. Yeah. So under that, it's more than just a collaboration tool, it also ends up becoming a knowledge base, right? As people come and go, you've still got all that IP, that intellectual property, that's been developed for your company in there.

Anil Varanasi

>> Right.

Bob Laliberte

>> Yeah. Absolutely. You've talked a lot about the difference between having a product and having vaporware, slideware, et cetera, other... I forget all the terms that you used for it. But if I remember correctly, Command was launched a while ago. It's out in the field. It's being used. I'm wondering if you can share some of the early adoption stories, provide some feedback that illustrates the impact it's having on network operations.

Anil Varanasi

>> Yeah. And I think it's, actually, three different use cases that have been really interesting. On the customer side, it's been really helpful for customers to leverage that no matter which organization you're in, the networking team is asked to do way more than the resources that they have. This might be anything from complex things to understanding client issues, to getting stats that the rest of the business wants, helping engineer things on security to configuring VLANs to firewall rules, et cetera. I think being able to be that sort of Archimedes lever and leverage for networking teams, that's been really interesting. So that's on the networking team specifically that we're seeing. Then, the second use case that we're seeing a lot is for our partners. Partners being able to manage many different customers and different customer types and being able to use Command to build dashboards entirely on the fly that they can put in this collaborative environment where they have different people on their team helping a customer maintain their network at different times of day to hit the SLAs they have with customers. That's been really interesting as well for partners to be able to use Command to do it. And I think, lastly, an underrated use case is... And we'll be talking more about this in coming months. But in the ensuing years, a year and a half since we launched Command, we've actually been using it internally for support and operations ourselves. So we took the Command model and made it an API that our support resources and operations resources consume to help with network design, network management, and network deployments. And it's been really interesting to see how having a great model that knows networking can help, even us, then in turn help our customers better. So across customers, partners, and even our internal support and operation, it's been tremendous to see the impact great models can have. And especially models that are built from the ground up for networking like Command can have for us.

Bob Laliberte

>> Yeah. I think that those are great examples of how organizations are using it, the partners, the customers themselves. And more importantly, the fact that you're using it yourself because that way... I've always felt that was really a powerful statement when you're trying to sell something to somebody and you're able to say, "Yes, we use it. This is how we use it."

Anil Varanasi

>> Right.

Bob Laliberte

>> These were the first use cases that we started looking at fully automating and things of that nature, right? And being able to progress them through to the more complex situation. So it's always great to be able to hear from the actual vendor who's using it and what are the lessons they learned. So it enables them to have the users get over those early obstacles that you might've encountered and get to value much quicker.

Anil Varanasi

>> Yeah. That's right.

Bob Laliberte

>> All right. So we're getting towards the end here. I just want to give the option again, looking forward, where do you see Command going? Any additional capabilities you might want to hint towards that what organizations can expect moving forward?

Anil Varanasi

>> Yeah. I mean, I think as Command evolves today, it's about small model. We're training it now to be a very large model over the course of the next year or two. I think after Tesla's FSD, it's probably going to be the second-largest model on real-time data as we build it. What we really hope it to be is that it's another network engineer on your team entirely.

Bob Laliberte

>> Got it. I think that's great, right? I mean, that's ultimately what we've always talked about and having AI and the impact of AI on operations is that it's not going to cost you your job. It's going to... You're going to lose it to the person who's using it. So this is really a great call to arms for organizations to really adopt and embrace this technology as it's made available to them. So that they can be able to actually deliver more value to the businesses. In research that I've done, just so you know, the organizations that had AI technologies deployed in their networking environments for longer periods of time were more likely to say, "It frees me up to work on those strategic initiatives for the business." So when you think about that, the initial ones are always, "Hey, it helps me solve problems fast, find them, and fix them faster." But when those who've had it longer, they recognize the true value is really about enabling the business. And I think that's what we're all trying to figure out now is that as environments become more distributed, as AI becomes more prevalent, that organizations really need to leverage that network and see that network as a true enabler for this AI era.

Anil Varanasi

>> Yeah. Yeah. I think it's an important thing. But like I mentioned earlier, there's just not enough resources for the network usage and the network growth that's happening. So it's the right time to have tools. And again, whether it's a model, whether it's a software, whether it's a script, it's tools to help engineers do great work and manage critical infrastructure.

Bob Laliberte

>> Yeah. Absolutely. Anil, thank you so much for sharing all your insights.

Anil Varanasi

>> Thanks, Bob, for having me. Really appreciate it.

Bob Laliberte

>> Yeah. Absolutely. Great to have you here. Clearly, what we've learned is that Meter Command is transforming how IT teams are managing and automating their networks from faster more accurate actions to collaborative workflows to make knowledge sharing easier. So it's also exciting to see that purpose-built approach to networking for AI move from concept to real-world deployments. And so, we look forward to seeing how organizations continue to adopt these capabilities and the new possibilities that they unlock. So, great to have you here. Thank you, everyone, for watching. Stay tuned for more Networking for AI Summit.