The Future of Computing: My Keynote at IBM Technology in Action DACH

On Thursday I gave the opening keynote at IBM Technology in Action DACH, our client and technology day at the new IBM Technology Campus in Ehningen. The title was "The Future of Computing: IBM Research and the Rise of Generative Systems." I had forty minutes and a room full of people from across the German, Austrian, and Swiss market, most of them running real systems in production and trying to work out where AI actually fits. This is the longer version of what I argued on stage: that the future of computing is not one bigger model, and that IBM Research is building the alternative across four layers at once.

The main stage at IBM Technology in Action DACH during my keynote The main stage during the opening keynote. The room was full by 09:15, which tells you something about how much appetite there is right now for a straight answer on where enterprise AI is going.

A new campus, and the real question

The venue mattered, so let me start there. The IBM Technology Campus in Ehningen opened on November 19, 2025, in front of about 450 guests from politics and industry. Karsten Wildberger, Germany's federal minister for digital and state modernization, gave the address and called it a strong signal for Germany as a place to build technology. It is now the central IBM hub in the country, with AI, quantum, and cloud work under one roof. There is a quantum data center on site, and some of the guests took the tour later in the day.

I mention the campus because it sets the tone in the room. The people in that room are not asking whether to use AI. They already are. What they want to know is quieter and harder: which of this is real, what will still be standing in two years, and what happens to the systems they have already bought and staffed. That is what they had really come to find out.

So I did not open with a model demo. I opened with a claim.

One system, four layers

The claim is that the future of computing is not a single, ever-larger model that does everything. It is a system, co-designed across four layers: the models, the way you program them, the runtimes that serve them, and the silicon underneath. IBM Research works on all four in one organization, and the runtime and integration layers are developed in the open.

Diagram of the four co-designed layers: models, programming, runtimes, and silicon The four layers, and the point that matters most: IBM Research tunes each one to the others.

That is an unusual thing to be able to say. Most companies own one layer and buy the rest. When you own all four, you can make decisions in one layer that only pay off in another, and that is where a lot of the efficiency I talked about comes from. Granite is tuned for the serving stack and the silicon. The scheduler knows what hardware it is scheduling onto. The storage layer feeds the caches the scheduler routes on. None of that coordination happens by accident.

The rest of the talk walked through those four layers.

Presenting the four-layer argument on stage Making the case that efficiency comes from co-design, not from any single component. The interesting engineering is in how the layers are tuned to each other.

Small models are the point now

I spend my days on the software stack for IBM's Spyre accelerator, so I have opinions about models that are shaped by what it actually costs to serve them. The headline I wanted the room to leave with is that small models have quietly become good enough for most enterprise work, and that this is the more interesting story than the frontier race.

If you plot open-model quality against size over the last two years, the small end of the chart keeps reaching quality that used to need a much larger model. A 32-billion-parameter model today does work that needed something several times larger eighteen months ago. For a bank or an insurer, that decides whether a workload fits on an entry-level GPU or needs a cluster.

Line chart titled "Small models are catching up": the open-model intelligence index by size tier from mid-2023 to late 2025, showing the small and tiny tiers climbing to scores that previously needed a much larger model Open-model intelligence by size tier, over time. By 2025 the small and tiny tiers reach scores that needed a much larger model a year earlier. Illustrative recreation of the trend in the Artificial Analysis Intelligence Index [11]; for Granite 4.0's published benchmarks, see IBM's model announcement [12].

Granite is IBM's answer to that [1]. Granite 4 introduced a hybrid design: mostly Mamba-2 state-space layers with a small number of transformer blocks mixed in, roughly nine to one, with a mixture-of-experts strategy on top. The state-space part is where the efficiency comes from. Traditional transformers get quadratically more expensive as the context grows. The hybrid gets close to linear, which cuts memory sharply. In practice we see around a 70 percent reduction in RAM against the previous generation, and the family drops all the way down to Nano models in the 300-million to 1-billion range that run on a laptop or at the edge [9]. Granite 4.1, released in April 2026, is the current small-model lineup [10].

Diagram of Granite 4's hybrid architecture: Mamba-2 layers, one transformer per nine, and a mixture of experts Granite 4's design. Mostly Mamba-2 state-space layers, about one transformer layer for every nine, with a mixture of experts on top. That mix is where the memory savings come from.

The part I care about most is not the benchmark score. It is that Granite ships under an Apache 2.0 license, with published training documentation, and ranks at the top of Stanford's transparency work. For a regulated enterprise, that combination (you can see how it was built, you can run it anywhere, and you can adapt it on your own data) matters more than a point or two on a leaderboard.

A 32B model on a single entry-level GPU, doing work that needed a cluster last year. That is the shift that actually changes budgets, and almost nobody is talking about it.

I was careful not to oversell this. Frontier models are still better at the hardest reasoning, and there are tasks where you want them. The point is that you should not pay frontier prices for tasks a small model handles, and most enterprise traffic is those tasks: extraction, routing, tool calls, summarization.

Small and large models, working together

That leads to routing. You do not have to choose one model for everything. A system that routes each request to the smallest model that can handle it, and escalates to a frontier model only when it needs to, can beat the frontier model on cost while matching it on quality for the traffic that matters.

IBM's new AI development environment, Bob [3], does exactly this. It orchestrates between small and frontier models depending on what the task needs, and it does code review and pipeline work inside the enterprise environment rather than as a generic assistant. I showed a bit of it because it makes the abstract argument concrete: the routing is the product.

With Thomas Harrer and the IBM Bob mascot after the keynote With Thomas Harrer, IBM Distinguished Engineer for the Storage Platform in EMEA, on the main stage next to the Bob mascot. Bob routes between small and frontier models as the task demands, which is the clearest working example of the argument I was making.

Treating a model like software

This was the part of the talk I was most excited to give, because it is the part that gets the least attention and, I think, matters the most over the next few years.

Generative AI today is missing almost everything software engineers take for granted. Our programming model is one giant prompt, where changing a few words can swing the output wildly. Our development lifecycle is hand-crafted prompts and trace-reading, with no reproducible builds. Our security model does not separate instructions from data, so every token is potentially an injection. And every agent framework is separate, so connecting them means writing custom integration code. We have spent fifty years building encapsulation, version control, type systems, and isolation into software, and then we threw most of it out the moment we started programming with language models.

IBM Research's answer to the programming part is Mellea [5], an open-source library for what we call generative programming. You use it anywhere you use Python. The idea is to write a function, define its contract, and test its output before you pass it to the next function. It brings the discipline of a systems programming language to model calls. Mellea is not an agent framework, though you can build agents with it, and it is not tied to any one inference engine.

Underneath that sits an idea I really like: a "model" is no longer just a file of weights. It is a software-defined composition. You have the base instruct model, its core behaviors, a retrieval pipeline, your domain-specific tuning, the reasoning steps, the interface you expose, and the controller that routes between them. Instead of one enormous model that does everything a little badly, you assemble a capable system from small parts, each good at its job. That is how software has worked for decades. Mellea brings it to AI.

Diagram contrasting one giant prompt with a Mellea model composed from parts With Mellea, a model is a composition of parts rather than one prompt. Each part has a contract you can test before the next call.

One piece of technology makes this cheap enough to be practical. We call it activated LoRA, or aLoRA. It lets you change a model's effective weights partway through inference, with very little overhead, to give it a new capability for one step. So you can run generation, an uncertainty score, and a guardrail check on a single device, without paying for three separate model calls. We have built up small libraries of these generative intrinsic functions: query rewriting, answerability checks, hallucination detection, citation writing, prompt-injection screening.

On several retrieval tasks, a 3-billion-parameter Granite model with the right intrinsic adapters matched or beat a roughly 200-billion-parameter frontier model. A small model with the right structure around it can outperform a much larger one that has none. Structure often matters more than raw scale.

Bar chart comparing a 3B Granite model with intrinsics against a 200B prompted model across retrieval tasks A 3B Granite model with aLoRA intrinsics reaching or passing a roughly 200B model that is only prompted. The bars show the pattern from the keynote, not exact benchmark values.

Agents need a shared protocol

The agent interoperability problem is the same fragmentation, in a different place. Every framework talks its own language, so connecting two agents means writing custom integration code, and that does not scale past a handful of systems.

IBM Research built an open answer here too. The Agent Communication Protocol was our open standard for agents to message each other, hand off tasks, and manage their lifecycle, with BeeAI [7] as the open platform built on top of it. That work has since merged with Google's Agent2Agent effort and now lives under the Linux Foundation [6], alongside Anthropic's MCP, which handles the model-to-tool and model-to-data side. The stack that is emerging is A2A for agent-to-agent, MCP for agent-to-tool, and platforms like BeeAI to discover and run agents from any framework.

Diagram of the open agent stack: A2A, MCP, and the BeeAI platform The open agent stack: A2A for agent to agent, MCP for agent to tools and data, and BeeAI to discover and run agents from any framework.

The reason I dwell on standards in front of a client audience is simple. If you build your agent estate on a proprietary integration layer this year, you will be rebuilding it in two. Open protocols under neutral governance are the closest thing to insurance you can buy right now. 2026 is the year multi-agent systems come out of the lab, and the ones built on open standards are the ones that will still be maintainable when they get there.

Spyre, and hardware as a scheduling decision

This is the layer I know best. All of this has to run somewhere, and where it runs is changing.

IBM Spyre is our AI inference accelerator, and we built first-class PyTorch and vLLM support for it. It runs on IBM Z17, on Power11, and on LinuxONE [2], which means enterprises can bring generative AI to the systems their core transactions already live on, instead of shipping sensitive data out to a separate GPU cluster. Spyre uses a dataflow execution model, which is a different way of running a neural network than the control-flow model a GPU uses, and it is the thing I work on day to day.

The strategic decision that I think is underrated is that we did this in the open. Spyre is being enabled through the main PyTorch and vLLM projects, working with the community, alongside other dataflow accelerators like Google's TPU and Meta's MTIA. That lowers the barrier: a developer uses the familiar PyTorch workflow, and Spyre shows up as a first-class serving option next to a GPU rather than a special case with its own toolchain.

The consequence for the people in that room is what I put on the slide as the takeaway. If you standardize your serving on vLLM [4] and the distributed inference layer around it [8], then hardware becomes a scheduling decision. A GPU, a Spyre card, or whatever accelerator comes next all plug into the same serving layer, and your application does not change when the hardware does. That is a very different procurement position than being locked to one vendor's stack.

Diagram showing vLLM and llm-d as a serving layer with GPU, Spyre, and future accelerators plugging in Standardize serving on vLLM and llm-d, and the accelerator becomes a scheduling choice. The same application runs on a GPU, on Spyre, or on whatever comes next.

There is a storage story too, which I touched on briefly. Once you are serving agents at scale, storage stops being a passive data layer and becomes an active part of the system: managing KV caches across a lifecycle, holding agent memory, serving vector search with low latency. The caches the scheduler routes on have to come from somewhere, and co-designing storage with inference is where a lot of the next round of cost savings will come from.

What it looks like in production

I closed the technical part with client outcomes, because architecture arguments are easy to wave away without them. These are anonymized, but they are real deployments. One contact center cut transcript handling time by about 70 percent and costs by half. One organization brought average time-to-fill for open roles down from around 21 days to under three. A consumer product doubled its daily active users. A sports application went from partial to full match-report coverage, a jump of more than 200 percent.

None of those came from the biggest available model. They came from the right-sized model, wired into a real workflow, running where the data already was.

With Dr. Heike Riel, IBM Fellow and head of science and technology for IBM Research Quantum in Europe. Her keynote later in the day carried the same thread into quantum: the future of computing is CPUs, GPUs, QPUs, and accelerators like Spyre working as one system.

Four layers, one organization

If there is one thing I hope stuck, it is that these four layers are not four separate product bets. They are one design. Granite is tuned for the serving stack and for Spyre. The distributed inference scheduler places work across the silicon. The storage layer feeds the caches the scheduler depends on. Mellea and aLoRA get more capability out of small models than parameter count alone would give you. And it is one research organization working on all of it, with the runtime and integration pieces built in public where you can see them.

Heike Riel's quantum keynote in the afternoon made the same point one layer deeper, out toward QPUs and fault tolerance. Standing next to her by the giant IBM letters at the end of the day, holding a bouquet I did not expect, I thought about how rare it is to work somewhere that spans small edge models and quantum error correction and treats them as the same problem at different scales.

I flew home with the same conviction I opened with, only firmer. The teams that win the next few years will not be the ones with the single largest model. They will be the ones who treat AI as a system to engineer, choose small models on purpose, put real structure around them, and refuse to lock their infrastructure to any one vendor. That is a harder story to tell than "our model is bigger." It is also the true one.

After the keynote at the IBM Technology Campus in Ehningen The end of a good day in Ehningen. Grateful to the IBM DACH team for the invitation, and for the conversations that carried on through the networking sessions afterward.