Cisco President: What Makes Agentic Transformation Work?

So, thank you, Michael, for having me on the show, and it's good to see you again. And you know, we are in a profound time in history right now, and we are kind of going into the second major phase of AI. The first phase was when we had this kind of magical experience when ChatGPT came out, and you ask a question, you get this answer, and it was this amazing way to go back and forth and get natural language to be the interface that you communicate with computers and machines. We're now in the second phase with agents, and frankly, I thought the second phase would have come a little earlier with OpenClaw.

But where I think the industry had underestimated the importance of was just the frictionlessness of how people can start using agents. So, not everyone wants to go out and have brain surgery done before they can actually start using agents. And I think OpenClaw was complicated. You had to get your own, you know, Mac Mini. Mac Minis were sold out. You had to make sure you had your own secure container. So there was a fair amount of heavy lifting, which made it good for the technically savvy people, but for the folks that were not really spending all their time thinking about agents, this was not easy. We're now in this kind of era of personal agents, which I think have gotten the consumer market really excited. And what we'll start to see is a fair amount of kind of autonomous work being done by agents that we can delegate to the agent on our behalf. And there'll be these long-running tasks that'll get done, long-horizon tasks.

And I think fundamentally this will also change the behavior of the enterprises in a big way because enterprises will now start to see a demand from their user base saying, "Hey, I'm using this at home. Why can't I use it at work?" And so we need to make sure that we have it at work. And that'll actually—those agents will be ones that'll be equipped with the data from work. And so I feel like it's a very exciting time where these agents will start to do tasks and jobs for us almost fully autonomously.

You know, every workflow, every business process that you have will actually get rethought with agents. But let's just take a step back and say, what is happening in the market right now as you make this shift to agents? And I think the statistics are really important. So right now, I would say probably best case scenario, sub-2% of humans are using agents in any kind of power user capacity. And you'll know that even when you go to a talk and there's a few hundred people in a room and you ask them, "How many people use agents?" Like, you know, there's a few hands that go up. More and more are starting to go up now with, you know, Muse coming out and Instinct and Grok Bot and Dots and all of these. I think what you'll start to see though is that the pattern is—it's really worth noticing the pattern. So, for example, in February of this year, agent token consumption exceeded human token consumption according to a study done by OpenRouter. By August, that had gone up 14x.

And so now it was like five times the human consumption of tokens by agents. So agents were now 5x that of humans on token consumption. In October, they did another study, so another quarter, and now it's 7x the growth. So what you're starting to see is there's this tremendous amount of consumptive pattern of agents being able to use a lot of tokens to conduct work. And 60% by the end of this year of global compute is going to be channeled towards inference, not towards training. What does all this mean? What this means is more and more people are finding that they are delegating work to agents, and these agents are working on our behalfs, and they're actually consuming a lot of infrastructure. And inferencing is the closest proxy to is there value being generated with AI. Training is not. Training says, "I'm building great models." Inferencing says, "I'm using these models that you're building." Right? And so inferencing is the closest proxy. So that's actually a very encouraging signal.

Now, as it goes to enterprises, what we are starting to see is this tremendous need for saying, "I have to move fast, and I can't just go out and have AI kind of slapped on top of existing broken processes. That's not going to work as well." So you have to kind of rethink your processes and your business workflows within the organization to say, "What do I need to do that can fundamentally transform the workflow, that can fundamentally give me a level of clock speed in the business that historically I've not been able to enjoy?" And, you know, I personally feel like this notion of a legacy company is going to go away. You will not have—like for tech companies, for example, we will not have legacy code because you'll be able to refactor any kind of code. You know, and so you'll constantly be able to modernize code. And so the key limitations of scale go away, and the key kind of limitations of the absence of scale in startups also go away because you can actually move really fast. So I think the entire clock speed of the industry is going to be at a very different level than what we've seen ever in the past.

Yeah, I think what will happen is tokens are going to be a constrained resource for a while because we're going to be in a supply-constrained world. And the reason I say that is, you know, if sub-2% of the people use agents today and we are completely, fully kind of out of infrastructure available, any kind of infrastructure that comes online gets instantly consumed. Imagine what happens when 15, 20, 30% of humans start using agents on a regular basis as power users. Boy, you're going to start to have a whole lot more consumption of tokens. And so we will be supply constrained in land, power, shell, compute, networking, memory for the foreseeable future. It's going to take a while for us to not be supply constrained. So then you say, so okay, so in this kind of supply-constrained world, how do you dole out tokens to people? And what should be the way that you think about everyone using it? My formula on this is very simple, which is this is like riding a bicycle. You first have to get familiar with riding a bicycle before you get good at it, before you get efficient with it. So when we started using AI for coding, for example, initially, for the first, you know, four to six months, I told the teams, "You have unlimited use of tokens. Just get fluent with AI. And start using this and make sure that you don't have to be efficient. You just need to learn how to get good at it. And you just have to get familiar with it first before you can get good at it. So just use it. Don't worry about token costs." I was a little nervous, Michael, because we didn't know how much this would actually consume in tokens. But we actually did that. Then, what you started to see was the token cost started rising. People started using it a lot. And then we wanted to make sure that we actually gave them some kind of contained guardrails.

And now, by the end of the month or middle of next month, we're kind of ironing out some of the kinks for, you know, 32,000 employees in my team. But every manager on my team is going to have a token budget. And we have a tokenomics application. That tokenomics application tells you what agents are using, what level of tokens, are the agents starting to show anomalies and excessive use of tokens. If so, can you actually pull the kill switch on that agent so that that agent doesn't actually continue to keep consuming tokens at an exorbitant rate when they're not showing the returns? And we are now starting to get into this kind of, you know, everyone will have a—every manager will have a budget for what they're going to be spending for people. And they'll have a budget for what they're going to be spending for tokens. And those will be constrained resources. They're not going to be abundant resources—we have unlimited amounts. But what you have to do is show outcomes with those constrained resources. But everyone will be assumed that they're going to have the use of tokens. And everyone's—you know—you have to assume that they will use those tokens effectively and efficiently with their team. And your ability to efficiently and effectively and securely consume tokens will be directly proportionate to not just your company's economic prosperity, but also the security posture. And I would say at the end, who owns this? I think every company will go out and start to think about this differently, but you want to make sure that your business leaders and the team leaders are given the tooling to be able to go out and budget and regulate themselves rather than just being done at the top, so that everyone's managing the budgets, because that's how you build—that's how you create leaders in the organization.

We're way past pilot at this point. We're way into production because we will have—the goal that we had was we're going to have half a dozen apps or products that are going to be 100% written with AI by the end of the year. No human lines of code. We will exceed that number by the end of the calendar year. Next year, by the end of next year, the goal that we had was 70% of our products will be 100% written with AI. And then I'd say within a two-year period, 95% of the legacy code will be eliminated and refactored is the stretch goal that we've actually set for ourselves. What we had said was 100%. I think like the more we think about this, is 100% going to be possible? Like we're going to try to push forward, but I think 95% is kind of the area that we're starting to see that we will—we just want to eliminate as much legacy code as possible.

Oh, good.

Yeah. By the way, I'm not suggesting that agents using more tokens is a positive metric. What I'm suggesting is that is just a fact. By the way, agents are more consumptive than humans also in how they consume infrastructure. So, for example, an agent for conducting the same task as a human consumes 500x or 4,500% more network bandwidth than a human does. Why is that? Because eventually an agent has a skills file, a markdown file, some kind of cron job, you know, and a skills markdown file, a memory markdown file, some kind of cron job, and tools access. And so when you as an agent have to keep sharing context, you know, on a model, and if the model is not running locally, there is a fair amount of kind of upload of the model and kind of the memory and skills context that you have to make sure that you keep, you know, surfacing up to the agent. So I'm not suggesting that the simple use of tokens is a metric of success. In fact, you want to make sure that you get very efficient with the use of tokens so that you don't have excessive use of tokens for an underwhelming level of return. I completely agree with that.

What we are saying though is that when agents start getting more consumptive in their patterns of usage, you know that there's actually more usage happening of agents, and that that is the early indicator of, oh, people are starting to use agents. And that's just—that's just the kind of facts of like what's happening. And so the thing to keep in mind is there is going to be a certain amount of consumption, and that amount of consumption is causing a fair amount of, you know, kind of scarcity of infrastructure. And so what you will start to see is not just with the hyperscalers, but there'll be multitude of different kind of creative solves for reducing the cost of tokens, because the cost of tokens is going down every year, but not quite to the rate that the demand is going up for the consumption of tokens. So if you have the cost of tokens going down 1,000x a year, but your consumption is going up 10,000x or 100,000x, you're still behind, and you still are going to go out and spend more money on this. And so that's the area that we have to make sure that we actually reduce the cost of tokens sufficiently.

So what are people doing? Well, these open weights models tend to be a very, you know, kind of additive component, because I think the more open weights models that you have that actually push to even if not frontier class, even near frontier class, not every single query and not every single action that an agent conducts needs to have a frontier class model. And so having an intelligent routing technology directing a lot of the kind of agent tasks to an open weights model, and having those open weights models sometimes run locally rather than even running in a hyperscaler in the cloud, will just allow you to balance the cost. So I think the economics management of how many models, how you route, what specifically are the models going to be used for, where are you going to go out and run inference in? Is it going to be at your desk-side computer? Is it going to be local at the edge? Are you going to run it on a hyperscaler? What kind of class of GPUs are you going to run those on? All of those things actually play part—the part of the calculus on how you can effectively manage token costs and still have the right level of outcome that you're looking to get from the use of the tokens. But absolutely, I completely agree with you. Lower the cost with the greatest outcome wins. You know, and each one of us have to get superbly efficient because we don't have an unlimited amount of tokens. So when I mean my managers get a certain amount of budget for tokens, and they can get more done with a million tokens than someone else can get done with a million tokens, they end up being the better, more productive unit than someone else.

Yes.

That's a really good question. And one of the things that we will find if you simulate this thing out, because right now, for example, coding as a problem is largely solved. And most code over the course of the next two, three years will largely be written with agents and not by humans. However, where I tend to have a slightly contrarian opinion to most is I actually think you're going to need more engineers, not less. And every single time there's a step function improvement in something, you know, you will have a human bottleneck that emerges. If coding becomes automated, code review becomes a bottleneck. Code review becomes automated, you're going to have human judgment or whatnot to build, and which becomes so critical and so important that becomes a bottleneck. So at the highest level, assume that coding as a problem is solved, which means over time it's going to be hard for people—with the amount of code that gets generated, it's going to be hard for people to kind of know every line of code that's written within your products.

But you're still going to need to have human provenance where every agent that writes code directed by human needs to map back to that human to say, "Okay, that human is eventually accountable for that piece of code." So how do you do that? Well, one way to do it is ensure that—so assume that your code becomes a black box where you don't know what you're writing. This is not the case today, but eventually that's where it'll get to, where you know, you will have code that's being written to a point that it's going to be very hard for humans to inspect it. So what you will have to do is you will have to make sure that your e-evals are actually trying to ensure that every corner case of that code execution is happening in a way that can be tested for. And so your e-evals will get stronger and stronger. And so the way that you would do it is rather than going out and looking at what the code is, what you will do is you will actually stress test that code in every condition that there is to test, and that'll actually be determined based on the quality of the e-evals that you generate. And so a lot of times organizations will be measured not just on the quality of code they write, but the quality of e-evals that they've actually gotten in place that can test the code that's being written, so that you know what the outcomes are and not get surprised by it.

Yeah. I think having e-evals, everything that you do moving forward will have to be thought about at machine scale, not at human scale. Because the rate of compounding is going to be so fast that humans by themselves will not be able to do. So, for example, in cybersecurity, if your adversaries are creating attacks at machine scale, and they're trying to, you know, find the exploit paths and vulnerabilities at machine scale, you're going to need to make sure that protecting those exploit paths and vulnerabilities getting patched is also happening at machine scale. If you do it at human scale, it doesn't work. So, you know, e-evals will actually need to be—and this is why the recursive self-improvement evasions and constantly making sure that the models are keeping on getting better and better, and the outcomes are keeping on learning from itself and getting better and better are going to be so important as time goes on. But the—

A product team within an organization will be measured just as much on the idea of the product as they are on the quality of the e-evals that they actually direct the agent to write for them. And then, how much of the code coverage do they have, and what kind of corner case testing can you do? One of the things that we never were able to do quite right in, you know, pre-AI and pre-agents is even if you said there's X percentage code coverage with automation, you didn't quite have all the corner cases that you were able to cover. There was automation for a certain level of functional unit tests, but not all the corner cases. And now, what you're going to need to have is you're going to need to keep expanding the surface area of the corner cases that you can cover because any one corner case can become a massive security vulnerability as well. And so it becomes a security posture issue, not just a code quality issue.

Yeah, are you going to just look at my watch and tell me the time, or are you going to actually have original insights? Look, I probably shouldn't say this, but we tend to have almost zero use of consultants in the product org within my product org because the way I think about this is if you have to ask a consultant what product to build, then I just need a different product manager. You know, because I shouldn't be asking a consultant to do that. So I do agree that there tends to be a lot of, you know, show me your watch and I'll tell you the time. I think with agents, you have to make sure that the right level of harness is built where you can make sure that the agent is giving you not perfunctory feedback, but actually truly substantive feedback. And that also is largely dependent on how you go out and train and develop the agent and how you make sure that that actually gives you the kind of input that you're looking for to make you better rather than just to make you feel good. And so I do think that that's an area that I think has a lot to do with the human psychology than the agent psychology. Here's what I would say.

For hundreds of years, for as long as companies have been around, but it's gotten worse and worse over time, we as humans have started to create our own versions of the truth rather than seeking the truth when we go manage a business. You know, if you have ever encountered a time when you're looking at dashboards and everything is green but your business is not growing at a fast enough pace, well, everything—all that tells you is you might be short on ambition if everything you think is green and you're not growing the business to go out and capture share. And so I do feel like we have to be extremely, you know, kind of intentional about getting the right level of feedback from our system around us, which includes agents, which includes humans. Like, for example, I always surround myself with people that are going to tell me what I'm not doing well 80% of the times and 20% of times tell me what I'm doing well—not because I want to feel good about it, but I want to know what's working so that I can continue to keep doing that more. But you have to take away the vanity from that dimension, and if you actually start to seek popularity in running and growing a business, I think that can become, you know—a lot of people have said like the desire to be liked at the expense of truth becomes a very dangerous fatal flaw of a leader. I agree with you that we need to make sure if you're pushing our agents to give us original insights that are not like, you know, unsatisfactory on the true alpha that's needed. Like you need to have high alpha insight.

Yeah. You know what? One of the—there's this notion I have that as a company gets large, you get very good at the math of the business. Everyone knows what your gross margin is. Everyone knows what your operating income is. Everyone knows all of the statistics about the business. But what you tend to lose touch with sometimes, especially as companies get large and you have more layering, is the soul of the business, which is what is the—what is the front line and the customer's view on your value? And how are you working backwards from there? And that tends to get diluted a lot because what happens is, you know, when you're a startup and you're a CEO, the CEO is the product person and is the salesperson. And they're talking to the customer and there's no asymmetry between what the customer wants and the CEO is interpreting. They just talk directly to them and they say, "This is what the customer needs. I got this feedback, and here's what I'm going to go out and build. I'm going to take it back to them." And there's a very fast closed loop.

When it gets to a larger organization, someone talks to someone that talks to someone that talks to someone that talks to the customer. And before you know it, what you've gotten is a very—it's the telephone game where you—and then there's also perverse incentives that people have where they don't want to actually surface up the bad news. They only want to surface up the good news. And before you know it, you've lost complete touch with reality and what the customers actually want. So it's extremely important for every leader—I don't care if you're a first-line manager or you're someone who's a senior executive at a large company—to spend some amount of time in the front lines and truly get the direct source of truth feeding you information rather than actually being fed that information via other people. Because there's a lossiness over there that cannot be—the only way you can compensate for the lossiness is by going direct for some percentage of your time. You can't do that for every customer. Like we have close to a million customers. I can't talk to a million customers. But I want to talk to as many of them as possible directly so I can get enough of a pulse of what they think about, so I can then use that feedback in a way to direct the team in the right way. Otherwise, you're now too removed from the true problem.

That's a very good kind of question because oftentimes most customers might not want to offend you either. And the higher up you go in rank, the more they want to make sure that they maintain a good relationship, so they might not come out and tell you exactly how you feel. And so what I do is I usually ask some very blunt questions. One of the things that I do is I ask the customer for a letter grade. And then I ask them, let's say if someone says, 'Okay, so you got a letter grade of a C. Like, okay, so what would make it an A?'

And then what I will do is I will typically give that customer — if there's a customer that had an escalation, they weren't happy — I immediately give that CIO or whoever we're talking to my cell phone number and I'm like, 'Can you just do me a favor? This will take you less than two seconds once a week. Just send me a one-character text message which just gives me a letter grade. And I just want to see the progression. Is it actually getting better or is it actually getting worse?'

I think that kind of completes it, because otherwise what ends up happening with words sometimes is people interpret words whatever way they want to interpret words. And so even internally we have a customer zero program. The customer zero program is every product that we build, we want to make sure that Cisco is using it at scale. And if our own team is not willing to use it, why would a customer use it? And so oftentimes when we take that to our IT teams, our IT teams stress test it, and our CIO will typically or head of IT will typically send me a note at the end of every week that said this week the letter grade for this as we're doing the deployment was X, and then here are the things that are missing, and then I forward that note to my product team. And I'm like, what do we need to do to get to an A, and by what time are we going to get to an A, and until you get to an A, you stay relentless on that.

I feel like that's a — whatever way works for you to seek the truth, make sure that you don't reward, don't penalize bad news being surfaced to you in any way, shape, or form. There should be a fully safe space for people being able to surface bad news to you. And if they surface good news but something is wrong, that's actually not a good thing. That means that they didn't surface the bad news to you fast enough. And that's something that you have to make sure that you correct right away, because there's nothing worse than you not knowing there's a problem when there's a catastrophic problem within the organization. You have to seek those out.

And you have to fix them. By the way, every company has problems. So the fact that you have problems doesn't make you unique, doesn't make you bad, but the fact that you don't know how to fix the problems makes you less competitive. And so you just have to make sure that you find the problems and fix them, and then you find the next one and then fix them, and keep doing that. And now with agents, it becomes a whole lot easier to do that.

Okay, I'll try to keep it more succinct.

I think so far, judgment, taste, intuition, deciding what not to do — those tend to all be very, very strong human characteristics and not agent characteristics. You might use an agent to help you with that, but I don't think you can actually completely delegate that to an agent. So I think there is this thing such as over-delegation to agents. One of the things that I hate is when people actually ask Claude to put together a PowerPoint deck and they don't even read it, and then they give it to me, and I'm like, 'Why, if you don't then think it was worth you reading it, why would you think that it's worth my time reading it?'

I want you to internalize by agents giving you data so that you can internalize, so that you can apply your judgment to it. In the absence of human judgment applied, then I really don't know how valuable that is. So the way that I think about this is always look at things not getting to regress to a mean of very generic stuff. Like one of the things right now that I'm seeing is a lot of PowerPoint decks get created by agents, and then they all start looking the same, and all the messaging sounds the same, and all the stories sound the same, and I like...

It's all the AI slop, and it's like, you know, or just building too many products that I'm like, no one's going to use that product because that's not really a problem.

I think those things you have to have enough kind of, enough, you know, brutal judgment applied to it from a human perspective that you don't just have unnecessary levels of genericness that gets pumped out. Like, it's more important what you choose not to do in a world where you can do everything. Because what you choose not to do allows you to focus on doing a few things really, really well. And, you know, surface area is not always an indicator of success. In fact, it's the other way around.