Hello, everybody, and welcome to the View from the Top CEO Call Series Q&A with IBM CEO, Arvind Krishna. My name is Elliot, and I'll be your coordinator today. This call or the replay is not for media representatives. All such individuals are instructed to disconnect now. I will now hand over to Wamsi Mohan. Please go ahead.
Thank you so much. Good afternoon, everyone. Thank you again for joining us on our View from the Top CEO call series. I'm honored to welcome back Chairman, President, and CEO of IBM, Arvind Krishna, on this View from the Top series. This is actually Arvind's fourth appearance, so we're really, really grateful to have him here again. Arvind really doesn't need any introduction. Most of you have met him in the past. You know he's among really one of the top thought leaders in our time. He has had a very distinguished career. He's driven innovation. He's driven some key things within AI, Quantum, Blockchain, and so many other areas in his time as Head of IBM Research. He's also served as SVP of Cloud and Cognitive Software, where he pioneered the company's hybrid cloud business.
Arvind also led some of the transformational deals, including Red Hat and the spinoff of what is today Kyndryl. He's driven so many significant changes, including portfolio shifts, cultural shifts, and really focused investments to drive further growth. IBM's stock performance since Arvind took over is up 194% since April 6th of 2020, relative to the S&P at 158% in that timeframe. Real material outperformance over here. Frankly, we just witnessed a remarkable volatility in the stock, which has actually retraced some of the maybe unfounded fears at the time from last week. Arvind, welcome. Truly an honor to have you here today for this call. Thank you so much for doing this.
Well, Wamsi, it's a pleasure to be on with you. You've been most generous in your description. Hopefully, I live up to some of that at least. Also, thank you to the audience for wanting to listen.
Thank you so much. I f you don't know one thing about Arvind, he's extremely modest for a person who knows as much as he does. I remember back the time when I probably have had discussions with Arvind all the way about whether or not floating point operations on NVIDIA processors are the key to running the future of AI or not. The technological depth and detail that Arvind has is just truly commendable, and I'm always impressed, and I learn something from him every single time. Arvind, this is such an interesting time. There's just so much news flow. The velocity, the pace of this has been pretty intense. A lot of news focuses around agentic AI capabilities, including the ability for Anthropic and Claude to translate COBOL code, which has been created some significant volatility, all of which the stock has recovered.
The question really is, in investors' minds, why should or will customers stay on the mainframe, even if they can just click a button today and all their COBOL code can be converted to a modern language?
Let's for a moment presume that you could click a button and translate 1 million lines of code at a time, for the sake of hypothesis. Maybe it's not completely accurate, but let's for the sake argue that it is. I would argue that programs written in COBOL have very little to do with why people leverage the mainframe and use the mainframe. We would be the first to tell you that if something is not fit for purpose on the mainframe, let us help you migrate it and let us help you modernize it, and let us help you take it to the right place. Let's come back to why is the mainframe so used, whether it's in payment systems, whether it's in retail banking, whether it's in certain batch processing, whether it's in reservation systems.
It has to do with the complete architecture of the system. How do you make sure that something is resilient? We have clients who in aggregate manage to run at six, seven, and eight nines of reliability. That means you're talking about milliseconds to seconds of outage over the whole year. I think that if you try to replicate that level of resilience on alternate architectures, your price would be three, four, five times of what it would be on a mainframe architecture. That usually works n ext, when there is enough scale in what you're trying to do. Are you trying to do 1 billion transactions a day? Are you trying to do 10 billion transactions a day? Are you trying to do 450 billion inferences, let's say, to avoid fraud on credit cards a day?
For those kind of workloads, the mainframe is both cost-effective and architecturally the best fit for those kinds of workloads. Which platform do you have where everything can function encrypted, be it in memory or be it the actual transaction, without having to go through multiple systems, adding latency, et cetera? As I argue that it is that architecture that keeps those workloads on the mainframe, the next part now, let's look at the seriousness of could you actually migrate COBOL? It's not so much that you look at that and say COBOL is bad. What COBOL has done, it has captured the business logic of people over the last 10 years, 20 years, 30 years, or 40 years. If you're going to replicate it, you've got to make sure that that business logic is correctly there in an alternate language.
When your issue becomes that a single mistake in a million or a billion transactions a day gets the regulator breathing down your neck, you're going to have to be really careful that what is translated is 100% accurate, not 90% accurate, not 95% accurate. That's going to take a lot more work and a lot more checking. I would not tell you it cannot be done. The question is, are there any economics, and what is your advantage of doing it for those workloads? On a more serious note, we came out with our own product that does this, watsonx Code Assistant for Z, a Z being code for mainframe, and it actually can translate COBOL to Java. It can translate COBOL to modern, and this is what happens. Clients say, and we are not at all defensive, you want to modernize the platform?
Let us help you. This is a great tool. It really helps you do that. The first thing you need to do is what is that business logic, to my point of the 50 years. It helps you document that. It takes all kinds of spaghetti code where people have undocumented code, and you have no idea, i s this something stubbed out or is it real, and it can comment it for you. The moment people see that, they then begin to understand, oh, this is not a spaghetti ball of mess. I understand now what it's doing. Do I want to take this and move it? Do I want to modernize and rewrite this? Do I want to put another API call on this? This should stay. This should go somewhere else. That becomes a much more productive conversation that we have been having.
The last part I'll say, it's not about a stateless piece of code. If there's a stateless piece of code, you could move it around. It is also tied in to the underlying data that's on the platform. It is typically tied in to tens, if not hundreds, of other applications that touch the same data and the same variables that are on the same platform. Moving it means you've got to make sure that that entire ecosystem can go along with it. Sort of really long answer on the why, but we actually believe that we should modernize, and we want to help our clients modernize.
If in the process, they find there's some applications sitting there that don't belong, we want to help you take them to the appropriate place, be it a public cloud, be it a Linux server, be it some other platform that is close by.
Arvind, that makes a lot of sense. When you talk about watsonx Code Assistant for Z, when you think about how long that's already been out there— it's been there for a couple of years—w hen you see how clients have been using that, what are some of the lessons from that? What are the ways in which AI is changing how customers are actually using the mainframe?
Before I even come to watsonx Code Assistant for Z, I always like to first focus more on the revenue side, where people actually get a bigger business benefit, and then we'll come back to the productivity side and the efficiency side. In our prior generation mainframe, z16, we began to introduce some AI capabilities. In this latest one, we introduced the Spyre processor. That, in aggregate, lets you run, let me call it, small language models. I wouldn't call it the mega models, not the frontier models, but 10, 20, 30 billion parameter models can run on the mainframe.
We have a client, a North American bank, looking at credit cards, and previously, they used to maybe be able to parse 10%, 20% of their transactions through an off-platform system, looking for fraud alerts, and then you use those to kind of create rules on the rest. Now, they can run 100% using the Spyre on the platform, and that means you're now saving all the money. The bank saves money, tens of millions. More importantly, the 0.5%-1% of fraud that either the merchant or the customer has to then swallow also goes away. I think that's a tremendous benefit. I think there will be more and more cases. Pretty much everybody around payments is looking at how can we leverage that capability. Now, let me turn it back to the efficiency side.
Our watsonx Code Assistant for Z is deployed at about 150 clients, if I remember correctly. They've actually purchased it. They are beginning to leverage it to both understand the code base, understand what they should modernize in place, understand what does not need modernization at all, and also understand which pieces they want to take off and perhaps run somewhere else. The tool will then spit out a Java version of that complete application. I think that is tremendous. Both sides. C an I leverage AI to get a bigger business benefit, and can I leverage AI to make it much more productive on how I run and manage the platform? The last piece I got to say I have a lot of pride in.
As you know, every system has all kinds of knowledge and tribal knowledge that the experts know, but then everybody scrambles to find those experts when something happens. We're also writing a lot of AI-based tools that run on the mainframe that help you manage what might otherwise require a lot more expertise, and sort of you make the six-month system admin equal to the 10-year system admin.
That's really interesting insight. Arvind, when you think about the future of an era where these workloads are being modernized. There's been the timeframe from 2010 to 2020 where public cloud was gaining a lot of traction, and some workloads were considered to be de-platforming at that time. What has changed since then? Why is that maybe not the case anymore? What is the TCO value? You alluded to it a little bit in talking about the five, six nines of reliability, but what is the TCO truly on a comparison basis that clients are seeing that keep them on the mainframe?
Look, I think first, if I go back even older than 2010, let's go back the decade before that, and if I go now to the late 1980s and the early 1990s, the mainframe was probably the workhorse of enterprise computing in those days. Web serving, e-commerce clearly happened on what used to be called, if I remember, the LAMP stack: Linux, Apache, MySQL, et cetera. That is fit. It's a stateless application in some sense. People come in, they browse, they buy. People hadn't really touched that mainframe estate, which was the enterprise workhorse. They then began to look at it and say, okay, which applications are running here that really, as I modernize, don't belong here? They should run on a public cloud. That's the ones that moved, but I would put that much more in the 2000- 2010 timeframe.
They might have started with thinking about moving it to an internal Linux or Unix cluster, but then as cloud was coming, that became a likely destination as well. T hen, I would say 2010 - 2020 was not actually that much migration. There's a lot of new workload that went onto public cloud, but not necessarily so much mainframe migration. Now, people begin to look at it, I think a lot of our clients, at least, have become a lot more mature. To your point, if I pick 2010, I'd paraphrase it as maybe, oh, the answer is public cloud. What's the question? Now, people are saying, wait, what are the true economics of running it where? Can I understand those economics? If I include, what is my cost of having hot backups?
What is my cost of having a failover in a few milliseconds? Once you put all that in, then for some workloads— I'm not going to look at you and say for all—f or some workloads, the mainframe is the lowest unit cost as long as you have sufficient volume. If you're trying to do and move, let's make up a number, 100 million retail banking transactions, and you got to net those out in 30 minutes- 40 minutes at the end of the day, for that workload, I can look you in the eye and say the mainframe is the lowest economic cost. You turn around and look at me and say, well, can I stream movies from it? I'll tell you it's not the right economic cost for that kind of workload. I'm just painting two opposites.
That is the work now that we're doing. Approaching people with that and saying, just believe me, that's not an appropriate thing. What we have done is we have taken other tools in our portfolio, like Apptio, which does technology business management, and we put the data into that so then you can look at it yourself and say, okay, I'm transparently seeing what is the best place to do this. That is where we want to be able to prove to people that on their cost structures, what is the right answer.
That's very helpful. Arvind, just talking about Apptio, and let's talk about software a little bit. Agentic AI and vibe coding, they seem to have really elevated the perceived risk for software companies, and in particular, SaaS companies. Maybe you can address, when you look at IBM's portfolio, what is the moat around the software portfolio and why you feel comfortable with the moat that exists around it?
Let's first just maybe unpack your first statement, Wamsi, for the audience. I actually am a very strong believer in both what LLMs can do and as well as what agentic leveraging LLMs can do. We believe it's going to make software development a lot more productive. We actually believe there'll be 1 billion new applications leveraging agents and LLMs that are going to get created over the next five years. Clearly, if that 1 billion gets created, it's replacing some of what is there now. If I unpack a typical SaaS, and for a moment, let's call it it's a SaaS business application, f or those that are reasonably deep, there is a system of record at the heart of it or the database, to call it that. I actually don't think that goes away. There is often business logic on top.
If that business logic is of the nature where you're touching a tax issue, you're touching revenue recognition, you're touching topics where if you make a mistake, you could get in the really the bad side of a regulator of some type, be it a financial regulator, a national security regulator, a data regulator. There are all of them that are there. I'm being generic, so it's across all industries. That's a really bad place. I think those two values of the SaaS applications actually stay. You get to the UI and how people interact. Today, as you know, when you deploy these, there's a lot of training done to make people aware of it, aware of the interfaces. Well, I'm sorry, but an agent, an AI agent could probably take care of a lot of that for you.
I think that this is what is going to happen, that the value of those applications is strong, but it is less than if you had the UI also. The other part is that as, I think, demographics are going to point to fewer people. That is another impact on these. As always, when the value decreases a little bit, there is a bit of a race down on pricing and those things, and we are seeing, I think, kind of that play out. The second part of your question, because I think we needed to preface with what is the areas that are much easier for AI and agents to go do in an easier way.
The next part is, if I look at the actual database, there's no AI or AI agent that can replace the actual storage of data in a meaningful way. If I look at how do you move data around, that's not what AI agents do. They actually need that in order to function. I don't love the term infrastructure software, but if I look at it as the horizontal software that enables all these things, that is where we had focused by design back in 2020. We had said, we're going to focus on automation. We're going to focus on data in addition to what we do on hybrid cloud. I think that these actually get tailwinds, because as people want to deploy AI, they're going to need more of all three of these, unless they're going completely to SaaS.
As we just argued, nobody's going all the way to SaaS. Actually, to leverage all this, this is a bit of a back to the future. People are going to build a lot more custom agents. That means they're going to need all of what we provide. Where is it going to go run, in turn? That's our thesis, and some of our numbers say that. Our growth rates have accelerated over the last five years, and all these parts of the portfolio are doing reasonably well.
That's a helpful contextualization of where there is disruption versus where there is security and resilience in the ability to continue to provide maybe even accelerated value. Maybe, Arvind, just thinking through your portfolio in particular. You've got hybrid cloud, you've got transaction processing, data automation. Can you help us think through how AI is either additive or subtractive to the TAM? There's been a lot of news recently about how there could be significant subtractive disruption elements like the Citrini piece, for example. I'd love to get your take on IBM's strategy to capture the incremental TAM that you see and areas where you think there could be incremental disruption.
Let's begin first with the hybrid cloud portfolio. To a large extent, we identify this with the Red Hat set of products. You have Linux, you have OpenShift, you have Ansible, and we have other new products that we'll keep creating and/or buying in that. Albeit these are all open-source based. It doesn't matter whether the workload is custom apps or migration of apps or new AI, it still needs to run on something. Our view is that that side of it is pretty resilient to AI. Now, the question is, is it not just resilient, but can it actually get a tailwind? I think that if there's a lot of custom agents and custom AI deployed as opposed to just using it in the hyperscalers, then actually Red Hat is a beneficiary as well.
The argument I'll make is, much as we have seen play out over the last six years for non-AI applications, there is a huge amount that'll be in SaaS and public clouds. As people look at it, I think hybrid has become the answer, and that is including because of sovereignty. If sovereignty becomes a big play where people say, oh, I'm willing to use a big public cloud from one of these two countries for certain workloads, but I need to make sure that even if a fiber optic cable gets cut or if geopolitics comes in the way, I can still function in an autonomous way, then we get a tailwind on that for that part of the portfolio. Next is our automation portfolio. Let me acknowledge, the word automation doesn't really do it justice, but that's the word we have.
This part of the portfolio is all about how do you manage your hybrid infrastructure, how do you run it in a way with much less labor and much less complexity? Is it about resource management? Is it about understanding response times? Is it about how do you deploy software? I'm thinking of HashiCorp when I say that. Is it about how do I manage my secrets? Is it all about, hopefully, the regulators and antitrust authorities will soon approve Confluent. How do I do that? Or, it's about webMethods of how do you knit applications together using API calls and data movement? How about transactional way to move data and messages, including I can recover even in the face of a power outage or a natural catastrophe like MQ.
If you look at all of these all get a tailwind and get deployed against all the new needs. The only time they would not be in massive use is if your entire estate sits inside one SaaS provider, which is unlikely. At least if I parse the market down and say about half the spend is in the top 2,000, there's another 30%-35% of the spend in the next 100,000, and then there's a very long tail. I think for 85% of the enterprise tech spend, this area gets a tailwind. Our numbers show that. We've been running this at double-digit growth for the last three years. Now, you have data and AI. AI is the place where you have higher growth here, meaning how do you do agents? How do you orchestrate across applications?
I actually believe the world is going to become a multi-model world. It's not a one model wins all. If people will say, hey, I'll use small models inside, I'll use some open- source models. I want to be able to leverage these two or three big models. T hen the place where you would do that and help manage all that is through our portfolio. That becomes then a place where you'll go win in that one. The last one we touched on is mainframe, or what we call TPS for transaction processing software. That one we just talked about in the beginning. We've been seeing anywhere from 15%-30% of volume or capacity increases on the mainframe.
Some of it we give back to our client as kind of a price optimization, but some of it we can see that comes through in the volume increases there. Typically, that has a bit of a lag compared to the hardware or the capacity. Historically, about 6 months- 12 months after the hardware capacity goes in, we begin to see the increase there. There, I would look at you and say, that's not going to be double- digits. That's probably in the low to mid-single- digits growth. Sort of three parts that should be in double- digits, maybe very low double- digits to mid to high, and one part that is going to be low to mid-single- digits. It's kind of how the portfolio makeup goes across those four.
I will tell you, I think these are pretty AI-resilient, but there is one scenario in which they're not AI-resilient. If the world decides one vendor on one hyperscaler is a winner-take-all and all the workload gravitates there, you would turn around and say, I don't need a hybrid orchestration. I don't have multiple models. I don't have a multi-infrastructure. It's only one. I think that's very low likelihood. Each time we see more skirmishes in the world or more geopolitics, I think that becomes even less likely.
That's a good point. I think maybe underappreciated in the sense of how long it takes enterprises to actually work through all the friction associated with business disruption potential, with the lack of maybe resiliency, the exposed risk from compliance and governance standpoint, all of those things play a role in. You've done this longer than I have, and you've seen, I think, some of these transitions where people have projected these transitions to happen during very short windows of time. Frankly, it's not happened in 20 years, so it could take a very long period of time for a winner-take-all. Frankly, we have not seen a winner-take-all in almost any technological scenario to think of. Even if there is one very dominant player, it's not been a winner-take-all. Arvind, just would love to get your perspective on agentic pricing.
You do think that agents have a significant role in the future. How do you think these pricing capabilities will be embedded within core software? Is it going to be on a per seat? Is it per agent, per transaction, per outcome? It's interesting, we've heard in instances where people are running some of these agentic workloads at some scale, where the cost starts to mimic one of a human employee. How do you prevent sort of agentic sprawl from happening? Would love to get some insight and your thoughts on this.
Look, part of the questions have been faced in software for the last 40 years. Do I want to price it per employee? Well, as long as employees were growing and everybody was increasing, that works. What happens if half your employees are not humans, but other agents talking to agents? I actually think that the per-seat pricing model begins to show its fallacies as you go down that road. Some people say, let's price per outcome. It sounds great. I've found very few clients who really want to do that unless it's a lot of human work, and so there is actually shared risk of some type. If you're pretty sure of the outcome, I think it's very hard to get pricing for the outcome, because in some sense, if you're living in a capitalist system, you're motivated, you want to keep the outcome for yourself.
You don't really want to share the outcome with somebody else. You then get to capacity pricing. If you look at our portfolio, I would look at you and say 80% of our portfolio is priced per capacity. If I look at our hybrid cloud, it's priced by VPCs or virtual processor cores, and that seems a logical way. That way if you consume a lot more, we are motivated to help you to consume more. If you're not consuming it, you're going to turn the price down. A lot of our portfolio is priced by capacity or usage more than either blindly per seat or any other way. I really do think that this is going to turn out to be how it's used.
By the way, I would turn around and tell you, I think the people who do token pricing, in some sense, it's a capacity pricing. A fixed per person works in the consumer world, but the enterprise probably doesn't really want to see that. As I said, if a lot of your employees become "digital employees," what happens to pricing? Do you want to charge for it? There is also this danger that if you let agents or AI models run amok and you're consuming millions or tens of millions of tokens a day, I think if you do the pricing on a per year basis, that's way more expensive than a human employee.
This is going to be a very interesting evolution to monitor. Arvind, where do you think the durable profit pools will be in the agentic stack? Is it in the models? Is it in orchestration, domain agents, observability? Where is IBM choosing to play or not play within that?
Look, since at the end of the day, the intelligence comes from a model other than sort of the consuming application, let's call that an agent. The model will always get a share of revenue. This is what we're going to see play out. If very large models are roughly equivalent, that means you can switch between them, then that says that, yes, they certainly derive value, but it's very hard for them to command the premium. You then go, they'll certainly get a big share of the revenue, but it's going to be coming down to sort of more of a commodity-like pricing. You then say, if the knowledge of sort of the domain, the application, the actual usage is in what we'll call the agent, but it's really a full-blown application.
The agent is just sort of a name for that, and that has got a lot of intelligence now and routing between models, figuring out what to do, when to do, when do I need to do a second iteration or a third or a fourth. Then that is certainly going to command the price, w here the model price is kind of built into that price, to some extent. If I look at every technology cycle, if I go back to the mainframe in the 1960s and 1970s, originally the hardware drove the pricing. Over time, the software which made it easy to use became the pricing. Over time, the applications became. I think the mobile phone revolution is the easiest probably for the audience to understand.
Back in 2007, if I pick that as the era of the smartphone start, for the first couple of years, it was all about whether it was an iPhone or an Android. Very quickly, the App Store came along, all of the enabling software came along. You would then turn around and say, hey, actually iOS and Android are the lock-in. The hardware is important, but the apps is what enables the hardware. Now, what are there, 6 million applications or more on the iPhone? That ecosystem is much bigger than just the hardware or software. I think it always goes in order. The infrastructure or the silicon gets it first. The enabling software and tools get it second. Then, for the value to hold, it has to be the multitude of applications, and that dwarfs everything else, but it's because it's also in the millions.
Every cycle, I think, has seen the same. The PC is identical to that. The internet is identical to that. All of these, I think, kind of play out along the same arc. It takes 10-15 years to get from beginning to end.
I was just going to ask you, where do you think we are in that cycle for AI and agents?
I used to say till end of last year that if I think of it like a baseball game, we are still in the first innings. Maybe we are just transitioning from the first to the early second innings at this stage. You kind of know who's on the field. You kind of know who's playing. It's hard to know who's hot today, who's not hot. You kind of need to get to the fourth or fifth innings before you can kind of say, okay, I have some sense of who might win this game today.
That's a good analogy. Arvind, look, if agents start doing maybe half the work of what people do today, what happens to the consulting business model? What happens to pricing, margin structure? How do you measure productivity in those cases? What happens when the unit of delivery becomes a digital worker?
I think first I would look at you and say, we can debate is it two years, three years, or five years, I think half of all repetitive work will be done by agents. I actually see no reason why that would not be true. That is assuming AI makes no more strides. That is assuming today's level of AI capability. Now, you turn around and say, well, if half of it is done by digital workers, then your revenue gets halved. Of course not, because it takes experts and people and technology to deploy those. The other half, we still need people. If that's the case, I think in some sense, you are going to get 10%-20% price compression. You are going to need, if the amount of work stays constant, you're going to need fewer people. I turn around and say, if you are the early ones who embrace that, your unit pricing comes down, you become a share winner.
I can't tell you whether the number of people is exactly the same, but in terms of revenue, you can be a share winner and keep better margins and better revenue by being embracing of this trend as opposed to fighting it. That's where we lean in very heavily with our Consulting Advantage platform. I think over 350, if I go to a course level, kind of agents that can be deployed against workflows. To just make it very real for the audience, a tangible, previously, when we did an SAP project for a client, you would spend six months and 30 people kind of combing through requirements, capturing documents, making sure you've captured the client's process correctly. That can now be done with agents and a half dozen people over a few weeks. You've shortened six months to a few weeks.
You've taken 30 people down to five or six, and you can be much more complete. What's the gotcha? There's got to be some written documentation on the process side from the client. If that's not there, you still have to go do the discovery work to go document it. If you have something written down, that's a great starting point on those. That's one extreme example where people don't even think that agents would be useful there. Agents to do software development . We see anywhere from 30%-70% productivity depending on the kind of work for software development across the life cycle, and I think that's going to be a given. If I think about answering customer queries or customer experience, anywhere from 50% of the low end to 80% of the high end of the work can be replaced by agents.
In all these cases, these are at a fraction of the cost of a human employee.
If I was to paraphrase that, maybe it sounds like there is significant amount of work that will be done by agents. There is going to be some pricing compression, but people who embrace it early will be the share winners of the future. That's kind of IBM's strategy, to make sure that they are embracing some of this change early.
Correct. With one exception where I think it is sheer disruption. Not yet seen it, but I think it will happen. If I look at the kind where basically pure clerical work has largely moved offshore, people call it the BPO industry, but that's a very wide term, but more so call centers, document processing, transcription, all those things. I think there it may not be some, it could be pretty massive disruption, but it'll take three to five years to play out.
That's helpful. What's the competitive threat that you take most seriously in agentic AI? You've got hyperscalers who are investing hundreds of billions in their CapEx plans. They're embedding agents everywhere, potentially. Is it going to be more pure play AI vendors or other consulting firms that are turning themselves into software companies? Where do you see the biggest competitive threat?
Look, we tend to partner with a lot of these players. If I look at the CapEx spend, we'll be a beneficiary of that. If Amazon or Azure or Google have more capacity, that's great, because we partner with all of them, and we could leverage that capacity for the benefit of our clients, including the capabilities that they have on their clouds. Now, it's always been competitive, like if you want to use a database, but then there's a wide variety of providers. Are you going to use the database that's native to the cloud, or are you going to use something from my friends at MongoDB, or are we going to use one of IBM's capabilities? I think it gets down to fit for purpose. You've got to engineer well, you've got to be consumable, you've got to be easier to run.
We tend to be more at the places where there is more enterprise need, meaning it's more scalable, it's more resilient, it's easier to monitor, becomes the cases where we'll win. We also leverage all our partner capabilities. Ditto for the pure AI model providers, we tend to partner with all of them. That's very much been our strategy. I actually think that our differentiation is that we want to remain hybrid, meaning we'll not be tying ourself to one particular public cloud. Certainly, it's too hard to use all of them, but we certainly will use the three majors that I mentioned for sure. We also want to help you run things in your own data center. That's your need. I actually think we might be not quite, but almost unique on that lens.
The only other one, I think, who plays into that theme is probably Broadcom, who also takes a hybrid approach. I think that if I look at the breadth, we are perhaps unique in that. That may not be the whole market, but I will tell you it's probably half the market. Two years ago, I'd have told you it's 40% of the market. Today, I'm going to look at you and say it's probably 50% of the market has a need for being able to straddle multiple public and sovereign.
Maybe, Arvind, since we're talking a lot about agentic AI and the cost implication of how much these agents will cost is going to be important. Over time, and we've already seen it in the last few years, the cost per token is going down at a pretty rapid pace, and it's kind of Moore's Law-ish in some ways, maybe even stronger than that in some ways, where you're seeing this significant decline in cost per token. As you think about that, from your experience, if you are lowering this cost of the barrier to entry, probably in some ways, to adoption of incremental agents for workloads, do you think that spurs up incremental demand? Just sort of how should one think about a future where you're really cutting down this cost of delivery? What happens to productivity and what happens to usage, from what you've seen?
Look, I think it's going to be very hard to make a 90% accuracy prediction in this space. Let me just acknowledge it. I also want to be a little bit provocative, maybe, Wamsi, by saying the price per token is coming down dramatically. It's not clear to me that the cost per token is decreasing that dramatically. I think the next few years will tell us whether these things are being run in a way that is profitable for those who run them or not. Right now, it's kind of a land grab where people want to make sure they can get the workload, they can get the clients, they can get the population using it, as opposed to is it being run in a way that is economical for the end investor. I'll just sort of caution with that.
It's also moving really fast, it's hard to tell where it's going to end up. All the capital being spent needs to get a return. That's my point on the difference between price and cost. There hasn't been a technology evolution ever of any size or scale where unit cost doesn't come down. Back to your point on Moore's Law, the effective cost for compute on the x86 architecture came down by about 2 times, let's say for a multiplication or whatever you want to call it, every two years. That means you could do more and more, and by the way, if it's every two years, that means after 20 years, it's at one-hundredth the cost. One-thousandth, to be more precise, but it's actually about one-hundredth in practice, because Moore's Law had some approximations built into it. That's dramatic.
But, you've got to now get careful, which is not what is being done today. If instead of a human doing the work, who says, I'll look at those three things, and that's what I'm being paid to do. If you let agents say, well, I want to explore the entire universe and go do tokens and do it for 1 million just because I can, because I'm running in the background, suddenly your costs may not be that good. You've got to then say, what am I asking these agents to do? And is there an actual business benefit for every single thing I'm asking them to do or there isn't? I think we are so immature today, we have no idea. I kind of jokingly say it this way. If I ask you that if I throw a ball up, does it come down?
You know the answer. But, if you ask a LLM, it actually has to go back and recompute it based on its internal weights. That's a lot more work than knowing the answer. We have to arrive at this mix of what is the value of doing something, and do I want to let it go off and ask itself 1 million iterative queries, or can it get there quickly? And if it's doing 1 million, do I know that the return is worth that cost? No one has built out that infrastructure and that level of sophistication at this point. I'm sorry to give you such a long answer.
That was great.
What I want you to understand that these things are nowhere near the point of maturity that you're pointing at. We can intuit the value, but now we have to sit down and prove. I do think that 2026, 2027 is going to be the years when people are going to turn around and say, at least the serious clients, okay, I need to know what the ROI is. Experimentation is done. I got it, that experiments can work, but is there an actual return now on doing it this way?
ROI is going to be a big question to sort of the spend point that you made earlier on the CapEx levels that are being put in. Maybe shifting gears a little bit. You've done so many deals. To change the portfolio, you've kind of crafted Red Hat to begin with. That's been very instrumental in turning the company's software growth around. You've done a lot others, Apptio, Turbonomic, Instana, I mean to mention a few, and Hashi and Confluent as well. What is IBM's broader aspiration in software as you sit here with all this agentic uncertainty in some ways? What do you think is the best use of capital given where some of the valuations are today?
First, it's clear to me that we want IBM to grow, and I want it to grow maximum in software. Just to put some numbers, when I started, software was about 20% of the total revenue. I think as we finished 2025, it was about 45%. That just paints a stock picture of where we are investing, where we are putting our dollar, and we're kind of putting our money where our mouth is. If that's where the growth is, that's where we're going to invest, but i n a very focused way. Without even mentioning which capabilities, number one, it's got to lie in our strategic priorities. That today is the four areas we talked about. Is it hybrid cloud? Is it automation? Is it data and AI? Or is it mainframe? In mainframe, it's very unlikely we'll do a sizable acquisition.
It's really in the first three. If you look at the last four years, there's been a couple of data in hybrid cloud, but the majority has actually been in automation. All the examples you reeled off, Turbonomic, Instana, Apptio, Hashi, are actually in automation. Now, with Confluent and with DataStax, we've done a couple in data and AI. We've done a couple in hybrid cloud, but because that is very much tied to open-source, there haven't been that many there. We did a couple, Neural Magic, which was how to do LLMs inside Linux really well, and a couple around container security. Number one, it's got to fit in my strategic priorities. Number two, we can use the word synergy. That's a very generic word. I'll be more sort of direct. Can we make the thing grow faster than it will grow on its own?
If all you get is the growth it was doing, that's priced in. I'm not getting any benefit from my investor by using our capital then. I look at, i s that synergy from the fact that I can leverage our global go-to-market by taking it to countries where they're not? Can I take it to clients where they can't go? Can I get a much more effective go-to-market structure by leveraging the footprint we already have? Can we leverage the partnerships we have to make the acquired entity grow faster? Or is it making something else in IBM grow faster? Effectively, then that is synergy. In the best cases like Red Hat, you get all of those.
In smaller ones, like let's say, Apptio, the biggest use is the expanded go-to-market, where we can take it to places where they would have gone, but what they were going to do in 10 years, we can do in two. Why I mention all those is that's very important. Third, we are putting money at risk. We wanted accretive to free cash flow within two years. That's the discipline we follow. Just to put numbers on one, maybe the largest of these, let's take Red Hat. $3.4 billion of revenue when we closed the deal in 2019. Our run rate is almost $2 billion a quarter now. That tells you. The OpenShift portfolio was like $130 million a year in 2019. It's now close to $2 billion.
That's a massive growth when it went from a contender to being the leading product in its space for a container and virtualization platform. That's a great exemplar of what we did. We can see it play out, whether it's in Turbonomic, whether it's in Hashi. In all of these, we begin to see an expansion of the market, and it's accretive to free cash flow, because we do all. We get the added revenue, but we're also very good at making the entity far more productive by leveraging all of the shared services and the go-to-market structures we already have. We very rarely touch engineering. Engineering tends to actually be increased spend from where it was, so we can give even more innovation to the clients.
Hopefully, that gave you both the three vectors that is our discipline, but also, we actually have a very tight methodology on how we do these.
What about software valuations, where they are? Does that make it a better, more attractive maybe time for IBM to consider public company deals?
Actually, I would say public and maybe even PE. In the end, maybe it'll take a few months, maybe a year, but even the PEs have to reconcile to where the valuations are in the public markets, because that's hard. That's evidence in front of you. It's all based on, if the multiples are well over 10 for something of size. By multiple, I mean valuation or EV to revenue. That's very hard for me to make our accretive in two years work. It can if the growth rate is incredibly high, but that's unusual to get that for a sustained period of time. At the current coming down, where now the multiples are often five, six, seven, eight, that's a very attractive place compared to what the last 10, 15 years have been.
I'll just sort of smile and say, hey, it's a great opportunity for those of us who have the cash flow and the financial flexibility. Maybe, it's got to stay in place for some time, but if it stays in place, maybe it gives us a chance to accelerate what we might have done over a few years into a shorter period of time. But, it's got to be the right target. I'm not going to get deal heat. I don't want to just run after everything. It's got to be number one in its category. It's got to have something which we believe is sustainable. It's got to have a great culture, and it's got to have innovation which has a moat around it.
That's helpful, Arvind. We're sitting in a time of, again, unfortunately, a lot of global macro uncertainty. IBM generally has done quite well in turbulent times. It's actually been a flight to quality from a stock perspective, I think business resiliency, too. Any thoughts on quick takes on that? I know we don't have a ton more time, I do want to ask you about Quantum, too. Would love to get some quick thoughts around this.
I'll try to keep it brief. Look, we have faced a bunch of this macro uncertainty based on geopolitics now for the last many years. We often ignore China. China is buying less and less American technology. That's the first one. The Russia-Ukraine, we only got hurt, not so much from the footprint in Ukraine. We did have to give out our business in Russia, which was a few hundred million dollars. That went out. I wouldn't call it the highest growth business, but an absolute amount went out. I'll have to give a lot of credit to how Israel functions. They've been remarkably resilient, despite all of the issues going on there. In some sense, they almost made a decision, a willful decision, that they were going to carry business on as much as possible.
The Middle East one is harder to predict just because it's very young. It's like a week old, I think, tomorrow. Now, my view is that we find that these things don't impact us as much, maybe because we're in the more critical parts of the infrastructure and the more critical workloads. I think a big reason, it's partly it's a flight to quality, partly it's also when clients are trying to understand who they can trust and who they can't trust, who will stick with them, who will give them great service, who will give them what they need to run their business. We tend to come high on that list. Often when I go to people and say, look, we are never going to look at your data. They look at me and say, we don't even have that question where you're concerned.
We actually know this, given your history. Like when a client has an issue, they don't even ask us, hey, will you look after our data correctly if I'm giving you a dump and a log that it has all kinds of sensitive information? They say, we know that you will destroy it, and we know that you will not misuse it. That also helps in that perspective, that we are a safe harbor when times are uncertain. But, w e've got to prove it. We've got to prove that our performance is there. We've got to prove that we can produce the revenue and the cash flow that we have committed. As long as we keep proving it, we should be able to attract investors even in this time.
I have to say that you definitely have surprised to the upside on free cash flows ever since you were doing closer to low double-digit billions to now 50% higher than that. It has actually been a very significant progress in your cash flows. Maybe to wrap it up, Arvind, I know we're coming up on the top of the hour. What is the biggest opportunity that you see for IBM in the next 5- 10 years? I'm sure Quantum is maybe at least part of that, if not it. Would love to get your thoughts around that, how you think about it. When does commercialization of this start, and how disruptive could this be as a technology?
Quantum is the single largest opportunity for us over the next 5- 10 year horizon. I look at it as it's disruptive, because it will solve problems which you actually cannot solve using alternate techniques. How do you make new molecules without doing an actual experiment? How do you do fertilizers? How do you do portfolio management? How maybe do you price in a risk environment? In all of these, if you can get a few basis points of improvement on one, but a few months of advancement on materials, that's a pretty big advantage for our clients. The timing, I would put it as 2029 if I had to pick a time. You can give it a plus/ minus some, but I would actually pick 2029, given that I said that a year and a half ago, and I'm saying the same today.
As every six months goes by, that gives you a lot more certainty on that date. It'll begin as usual. It'll be national labs. It'll be scientific workloads. It'll be people like that who will consume it initially. Very quickly, usually, capital markets will follow. But this time around, I think the industrials will come next, who historically have not been the big beneficiary of new forms of computation. We did work with some third-party consultants. We worked with both BCG and McKinsey. Both had the same number. They think the value impact or the disruption is of the order of half a trillion by 2035. You can then back up from there and say, what's the rate and pace? Probably that's the value disruption. Usually, about 30%-40% will accrue to the vendors in the space, which is not just us.
It'll be the software providers, the implementers, the consultants. About 30%-40% of that half trillion is going to accrue back to the ecosystem of people who provide that. I'm very excited by our progress. I'm very pleased with where we stand in this ecosystem right now. I would turn around and look you in the eye and I say, of course, you have to keep doing it because you're still a few years away from the prize. I feel very good about our competitive positioning in this space.
That's amazing. I know we are at the top of the hour. We are actually one minute past. Arvind, thank you so much for being so generous with your time and your insights. We worked back the COBOL disruption on the stock. I guess hopefully this will give people a way to think about the misunderstood, maybe software disruption risk to IBM's portfolio as well. Thank you for all your time. We really appreciate it. As usual, I feel like I am walking away with a ton more than the start of the call. Arvind Krishna, everyone, thank you so much for joining us today.
Good to be here with you, Wamsi.
Thank you so much. Thanks, Arvind.
This concludes today's webinar. You are now disconnected from the call. Thank you.