Based on Arvind Krishna’s October 5, 2026, AMA at the IBM Analyst Meeting
The AI infrastructure boom presents IBM with an uncomfortable question: What happens when customers spend more money on the ingredients that produce intelligence before they spend money with IBM to put that intelligence to work?
That was the premise of our opening question to Arvind Krishna at IBM’s October 5 analyst event. Our point was that accelerated computing seems to be changing some familiar rules and patterns of technology economics. To wit:
- CapEx is the new moat;
- Hardware technology is now inflationary, as prices driven by memory shortages are rising, not falling;
- The marginal economics and recurring revenue of software are less favorable to investors;
- Specialized market software can be developed quickly and at scale across multiple verticals;
- Valuation multiples are significantly lower for clear leaders like Nvidia than historical norms;
- PC unit volume is under pressure because of data center demand – one market falls because of demand from another.
Constrained infrastructure and rising component prices can accelerate purchases for certain products, while other projects move back in the queue. This was a theme of IBM’s Q2 earnings call and cited as a headwind for the company.
Our direct questions to Krishna were: 1/ Is this trend transitory; and 2/ If not, how can IBM turn what was a headwind, into a tailwind?
Krishna said this was not a passing disruption. He sees infrastructure inflation and supply constraints persisting, even as he characterizes the impact on IBM as delayed demand rather than demand destruction.
We believe the more important takeaway emerged across the rest of the discussion. IBM is positioning itself around a value proposition that is different from winning the race to build the biggest AI factory. Specifically, as intelligence becomes more widely available, enterprises will need a better way to connect it to their data, operate the underlying technology and control what AI agents can do.
Krishna identified those areas as potential control points. He also acknowledged that assembling IBM’s portfolio into coherent platforms remains a work in progress.
In our view, this is the central tension in IBM’s strategy. The company does not need to own every model, accelerator or cloud to become more valuable in enterprise AI. IBM has earned the reputation for trust. But what is the TAM for ‘trust’ and how does IBM get its arms around it? We believe the opportunity is there to market AI trust as a top level message, and make the combination of software, infrastructure and services more valuable than the individual pieces. That means delivering an operating model customers can adopt, not a portfolio they must integrate or pay IBM services to do so.
IBM’s opportunity is to convert increasingly expensive computing capacity into accountable business outcomes. Its risk is that the industry captures the infrastructure spending while IBM remains an optional layer of software and services.
Infrastructure inflation is not transitory – and delayed demand is not a guarantee
Krishna’s response to our question separated two issues that are often conflated: 1/ The duration of the infrastructure pricing cycle; and 2/ The effect of that cycle on IBM’s business.
On the first, his assessment was that he does not expect the pressures to disappear within a quarter or two. On the second, he argued that deferred purchases eventually return. He described the effect this way: it was not demand destruction, it was delay. He of course would not elaborate on Q3 results because IBM was in a blackout period.
The figures he cited underscore the scale of the pressure management sees:
| Indicator | Krishna’s statement | Our take |
|---|---|---|
| Memory prices | Up 400% over three years | Buyers have a strong incentive to secure scarce supply before further increases; artificially inflating near-term demand and negatively affecting IBM |
| CPU prices | Up 100% over two years | The pressure, in his account, extends beyond GPUs |
| Networking prices | Up 40–50%; | AI infrastructure economics must be assessed at the system level |
| Timing | He does not see the pressures going away over the next two to three years | IBM cannot build its strategy around a rapid return to cheaper infrastructure. IBM’s DNA is value-add, not reselling the IP of others |
Source: Arvind Krishna’s remarks in the AMA
We believe his distinction between delay and destruction is more than plausible. The question is sufficient to settle the investment priority shift in the near-term. Infrastructure purchases can create follow-on demand for the infrastructure incumbent meaning IBM will have to execute well to re-capture its momentum.
The question is therefore not simply whether deferred spending returns. It is whether IBM can attach its software and services to the capacity customers are buying – and whether that attachment produces sustainable growth rather than a temporary catch-up in purchasing.
Indeed, in our conversations with IBM customers, the positives are trust, breadth, technical depth and relationships. The negatives are complexity, cost and often confusion over what’s in the ELA bundle. Our sources indicate that Rob Thomas, IBM’s Chief Commercial Officer and head of software, fiercely warns against “ELA stuffing.” But years of the practice from jamming acquired assets into a renewal create long memories.
That said, there is a potential tailwind embedded in the inflation argument. More expensive infrastructure raises the value of using it well. Krishna described a need to automate technology deployment and operations so enterprises can support more compute without a corresponding increase in human effort. He framed the constraint as a shortage of capable people as well as a cost problem. IBM’s ability to help its clients scale with less labor is an advantage in our view.
This all gives IBM a relevant problem to solve. IBM must prove that through a new and improved AI operating model it can help customers lower operating effort, deploy faster and achieve better business results on any infrastructure – whether IBM’s, its partners or even its competitors.
The open-model forecast tells us where IBM expects value to move
One of Krishna’s strongest predictions was that, by 2030, 80% of tokens would run on open-weight models, with 20% or less on frontier LLMs. This is a safe bet as we’re probably over 70% open today. Importantly, token share doesn’t necessarily translate into revenue or profit. But Krisha is pointing out that frontier model vendors won’t have the market to themselves and there’s plenty of opportunity for firms like IBM to add value on top of open source/open weight models.
Our point is the direction of the statement matters more than the exact split. Krishna expects a world in which enterprises use multiple types of models, rather than relying exclusively on a small number of frontier providers. He described IBM’s focus as using external LLMs, open models and its own models to produce intelligence in the situational context of customer workloads.
In our view, that is the right strategic bet for IBM. The company does not have to own the best general-purpose model if it can become an essential part of applying the right model to a business problem. Therein lies the operating model opportunity.
That said, widespread model choice does not automatically create an IBM advantage. It creates an opportunity for whoever can make that choice valuable. IBM must demonstrate that it reduces the effort required to connect models to enterprise data, embed them in workflows and operate them under appropriate controls.
In our view, its ace in the deck is AI trust.
One thing we’ve observed about Arvind Krishna over the years is that we see a consistent principle in his positions. In this case he’s arguing to preserve customer choice at the model layer, but impose discipline when models are allowed to act on behalf of a business.
IBM has earned the right to talk about trust and is in a unique position to capitalize on that posture. But more work needs to be done.
Three control points and the integration work still ahead
Near the end of the AMA, Krishna provided an explanation of where IBM wants to concentrate its platform strategy.
Data, he said, will remain a control point. So will the operation of infrastructure – not the actual infrastructure itself, but how you run it (operating model again). He then identified control of AI, including agent permissions, data movement, logging and governance, as an emerging control point. He also reaffirmed the importance of container platforms and OpenShift, with a tip of the Red Hat, essentially the platform play for IBM.
We see three areas of strategic control that IBM can pursue, supported by a deployment model:
| Focus area | What Krishna described | What IBM must prove, in our view |
|---|---|---|
| Enterprise data | Make data usable across environments without requiring everything to move into one location | Agents and applications can access the right data with less integration effort and clear access rules |
| Infrastructure operations | Improve how technology is deployed, managed and operated | Automation delivers measurable operating benefits across customer environments |
| AI control | Define permissions, limit access and actions, and preserve logs of what agents did | Controls work across products and providers, rather than only within isolated IBM tools |
| Red Hat foundation | Retain OpenShift’s role as a platform for running software | The deployment foundation makes the higher-level experience simpler, not just standardized |
On data, he rejects the idea that every enterprise can move everything into a single warehouse or repository. He pointed to Confluent as a starting point for moving data, while arguing that IBM needs to do more to make the required subsets usable without moving all the data. Generally, the industry has accepted this premise. Even Snowflake, which thrives on having all the data inside of its platform, has recognized and made moves in this direction (embracing Iceberg, Polaris contributions, etc.).
This is a prudent argument against universal centralization – move as much data as necessary, but no more (to paraphrase Einstein’s rule of simplicity). The opportunity therefore is to make distributed enterprise information usable where necessary, while moving what a workload actually requires.
Just as important was his explanation of how customers should buy the platform. IBM intends to support customers who choose other vendors for most of the architecture and use IBM for only one part. Buying more IBM should improve the experience, but it should not be mandatory. As Krishna put it, We’re not going to be a monolith, so we’re not forcing you to swallow them all.
This is the right direction, in our opinion. However, openness in and of itself has limited practical value if the customer has to do all the integration. Modular purchases should not require fragmented operations and integration nightmares.
Krishna’s admission that the portfolio is a work in progress is both honest and significant in our view. He described acquired and existing products as pieces that can fit together, while acknowledging that IBM still has work to do to align them.
The next proof point is customer workflows showing that the pieces share the necessary context, controls and operating experience – leading to incremental and measurable business value.
NVIDIA can win without making IBM irrelevant – but partnership is not differentiation
John Furrier asked the following question: If NVIDIA continues to win massively, how does IBM become more valuable rather than less valuable?
Krishna’s answer was to position NVIDIA and AMD as partners. IBM will use their capabilities, its own infrastructure where appropriate, and external cloud capacity to produce intelligence in the context of enterprise workloads. He also described IBM as a substantial consumer of other providers’ cloud services
That explains why the businesses can coexist. It does not, by itself, explain why IBM becomes indispensable.
We believe the difference comes down to the scope of control. Infrastructure execution and enterprise authorization are related, but they are not the same problem. A system can execute an agent’s instruction successfully while the instruction itself remains inappropriate for the business. This again is IBM’s opportunity to position itself as the trusted AI partner to help customers implement a new and improved AI operating model, appropriate for the times.
In our view, IBM’s opportunity is to connect business authority to technical execution across a hybrid environment. It does not need to perform every enforcement function or action itself. It does need to show that enterprise policy reaches the systems where actions occur and that the resulting evidence can be trusted. A good example of this is AI governance. ServiceNow can be the system of action with AI Control Tower. IBM can be the system of trust with watsonx.governance.
This is also where the distinction between governance and enforcement comes into play. A log can help explain an unauthorized action after it happens. It does not prevent that action. The AMA shows that Krishna understands the accountability issue; it does not, yet, demonstrate a complete cross-platform enforcement architecture or allocate accountability among all the participants.
Our conclusion is that IBM is not inherently subservient to NVIDIA in this model. But neutrality alone is not enough. IBM will become more valuable only if customers rely on its layer to authorize, coordinate and account for activity that spans the underlying technology providers. Indeed our survey work with our partner Qualitate shows that customers recognize IBM’s strength in cross-platform, vendor-neutral governance across heterogenous environments.
Source: theCUBE Research proprietary study with Qualitate of 15 governance practitioners.
IBM Cloud has a role, but Krishna is not proposing IBM as a hyperscaler
Krishna was clear about what IBM is not trying to build. It is not seeking to compete broadly with Amazon, Microsoft or Google as a hyperscaler, and it is not trying to become a neo-cloud provider.
He described IBM Cloud in terms of particular customer requirements, support for IBM’s own products, selected large-enterprise workloads and software delivered as a service. His explanation started with the needs of existing and prospective IBM customers – that’s IBM’s focus.
We believe that is a more defensible role within the strategy he outlined and better positioning than the IBM of last decade, which acquired SoftLayer and had to transform what essentially was a bare metal hosting service into a specialized cloud. IBM Cloud can provide a deployment option where it strengthens an IBM offering or meets a specific customer requirement. It doesn’t need to win the general-purpose computing race to be valuable.
The key is consistency. IBM cannot argue that its enterprise platform supports customer choice and then make its most important capabilities dependent on moving into IBM Cloud. Krishna is clearly not taking that posture. The ultimate test is whether customers adopt the new operating model across their chosen environments, not whether IBM owns the platform in which every workload runs.
The last mile is IBM’s opportunity – and a possible services trap
Krishna’s defense of services was one of the more interesting parts of the discussion. Asked about forward-deployed engineers (FDEs), he traced the model back through IBM systems engineers, software lab services and customer-success functions. The terminology changes; the need for technical expertise close to the customer lives on.
He does not see that need disappearing for at least a decade and expressed skepticism that it disappears even then. His explanation was that enterprise value resides in the final 20–30% that is not common across customers. We believe this is another new dynamic in the AI era. Previously, the most successful software was that which could serve large markets horizontally. While vertical software served specific niches, today, vertical software can be spun up quickly and multiple markets can be addressed by the same company at scale.
This captures the core enterprise problem – i.e. general capabilities have to be adapted to specific processes and operating conditions before they become useful at scale. But doing so is far less expensive than previously.
This supports IBM’s combination of software and consulting industry depth. It also exposes the business-model question that the company must continuously address. Does each deployment generate reusable capability that makes the next deployment faster and less labor-intensive? Or does every IBM customer require another large body of bespoke work?
We see the first path as technology arbitrage – i.e. using software, automation and domain knowledge to deliver more value per unit of human effort. The second is a familiar services model with AI added to the tool kit, which is likely less durable.
Krishna’s discussion of IBM’s own transformation pointed toward the first path. He said automating an existing process did not realize the full opportunity. The more meaningful business value came when IBM looked at processes end to end and broke down internal organizational silos.
In our opinion, IBM’s differentiation should be the ability to combine process redesign with technology that makes the redesigned process repeatable and controllable. The proof should include implementation effort, time to value, reuse across customers and measurable customer benefit.
Enterprise AI’s bottleneck is becoming organizational
Krishna described a progression in executive priorities along the following sequence: Initial experimentation driven by fear of missing out (FOMO), frustration at the inability to put projects into production, and a growing focus on scaling AI into the business. He estimated that roughly 30% had moved into that scaling-oriented mindset.
Elsewhere, he estimated that only about 10% were actually realizing the operational changes under consideration, and he suggested broader transformation adoption could move toward roughly 25% over the following year.
The more useful commentary was between productivity and revenue. He described much stronger agreement about AI’s ability to improve efficiency than about its ability to produce substantial new revenue. He also discussed uncertainty over what happens when agents, rather than people, become the interface to consumer businesses.
We believe that calls for a disciplined near-term approach. Krishna advised enterprises to concentrate on two or three substantial use cases rather than scatter scarce skills and safeguards across 100 experiments. He specifically discussed customer service and enterprise operations, including procurement, accounting, HR and payroll.
Concentration alone is not sufficient. The chosen use cases must have an executive sponsor who can change the process across organizational boundaries. Krishna’s used a hotel-chain example to make that point: Selling more rooms around a customer’s need can require operating across a structure organized by geography and brand. The obstacle is not necessarily the model. It is who has permission to redesign the business.
IBM faces a related challenge internally. Krishna described culture as the most impactful of his priorities and said the company was only partway through changing it. He emphasized informed risk-taking, more proactive client engagement and greater automation of internal processes.
That is relevant to the IBM platform story. IBM cannot ask customers to break down silos while leaving its own products, commercial incentives and delivery teams organized as disconnected parts. The AMA identifies the cultural requirement; evidence at the execution layer must show that it is taking hold.
Quantum: Long term investments still matter – but near-term risks remain
The discussion was not exclusively about enterprise AI software. Krishna identified quantum as an area for increased capital investment, based on his expectation that machines IBM could build would support a broader set of use cases around late 2028 or 2029. He emphasized the challenge of producing many machines with consistent quality and an acceptable price, not merely demonstrating one in a lab setting.
He also described a mainframe roadmap extending to approximately 2045, with multiple generations of development proceeding in parallel.
There’s a common theme here: IBM wants to maintain durable platforms whose relevance extends beyond the current model cycle. But neither a long-term roadmap nor a use-case forecast guarantees future commercial returns.
Physical AI provided another example of both the opportunity and the risk. Krishna emphasized domain knowledge, physical models and the consequences of errors in the real world. He cited IBM work with Dallara that he said accelerated an engineering task by about 100 times, while acknowledging that a complete framework for the broader field had not yet emerged.
That is a potentially important example but not visibility that IBM has figured out a physical AI play. These investments require their own milestones and they’re not a substitute for proving that the enterprise AI platform works today.
What we would watch next
We believe Krishna articulated a coherent vision. The unresolved issue is whether IBM can turn that vision into a repeatable product and economic model in AI that creates the type of momentum investors will reward.
The following is a set of tests that observers should consider:
| Catalyst | Evidence that would strengthen the thesis | Evidence that would weaken it |
|---|---|---|
| Delayed demand converts | IBM Q3 results show Deferred projects have come back with meaningful IBM software and services participation. | The Q2 disappointment bleeds into Q3. Industry infrastructure spending grows but IBM-related projects remain postponed or shrink. |
| The platform becomes operational | Customers implement cross-product workflows with less integration effort and shared controls. | Common branding and cosmetic veneers hide separate administration and custom integration costs. |
| AI control works across providers | IBM leads in providing Permissions and action controls that operate across mixed environments, with defensible audit evidence. | Competitor platforms expand their governance offerings into IBM’s technical swim lane and confine IBM offerings to regulated industries, mainframe customers and niche markets. |
| Consulting creates reusable value | Deployment effort and costs decline materially while customer outcomes improve across successive implementations. | Each engagement depends on a new layer of bespoke work and comparable labor. |
| Openness survives commercial pressure | Customers rely on IBM to retain meaningful model, infrastructure and cloud choice without losing essential controls. | The strongest capabilities require adopting the whole IBM stack; or other B-o-B players gain share at the expense of IBM. |
| The AI operating model ecosystem expands delivery | IBM direct efforts extend to partners who can deploy and support repeatable AI solutions beyond IBM’s largest direct accounts. | Scaling the business continues to depend on scarce IBM specialists. Customers look elsewhere to implement their AI operating models. |
The ecosystem test is particularly important. Krishna distinguished IBM’s strength among the largest enterprises from the broader market, where he sees partners as necessary to extend reach. That is more than a reseller statement. In our view, a platform becomes more scalable when others can reliably implement it without recreating the architecture each time.
The same discipline applies to acquisitions. Krishna argued that the value of an acquisition extends beyond accelerating the acquired product’s growth; it should create additional value elsewhere in IBM’s portfolio. That is the right strategic posture. The customer version of it is simpler – i.e. does the combination make the solution work better and reduce the effort required to use it?
The bottom line
We believe IBM’s AI strategy is becoming clearer. Krishna is not proposing that IBM outspend the infrastructure leaders or own every layer of the model stack. He is arguing that enterprises will need control over their data, their technology operations and the actions of AI systems – across heterogenous environments – and that IBM can assemble a business around those needs and be the go to partner to implement a new AI operating model.
The logic is sound. The challenge, as always, is execution.
Infrastructure inflation can increase the value of operational efficiency, but it can also crowd out IBM spending. Model choice can increase the need for integration and control, but it does not guarantee IBM wins that role. Consulting can unlock enterprise-specific or industry-specific value, but it must produce reusable capability rather than perpetuate custom work.
Krishna’s most important admission was that the integration is still a work in progress. Investors and customers should take both parts of the message seriously in that IBM has identified places where it could capture durable value, and it has not yet established in this discussion that the portfolio operates as the platform it intends to become.
The opportunity is not simply to participate in the production of intelligence. It is to make intelligence usable, accountable and economically valuable and trusted inside the enterprise. That is the standard against which IBM’s next phase should be judged.
Action item
Enterprise leaders should resist both infrastructure-first purchasing without a business plan and governance-first programs that are disconnected from operational decisions. Select two or three material workflows, establish the baseline economics, identify who can authorize changes across departments and define what agents may do before scaling deployment. Require IBM – and every participating supplier – to demonstrate those controls across the actual environment, including auditable proof of what happens when an agent attempts an unauthorized action.
For IBM, the priority should be to make the integrated experience visible. Show a production workflow spanning enterprise data, infrastructure operations, model choice and agent accountability. Quantify deployment effort, ongoing operating cost and business impact. Then show how a customer or partner can repeat the implementation at scale, without rebuilding another one-off “snowflake.”.
That would do more to establish IBM’s enterprise AI position than any acquisition or expansion of the portfolio narrative.
