AI Is Becoming A Stack

We keep talking about "AI" as though it's one industry. I don't think it is.

What we currently lump together as AI is separating into at least three distinct layers, each involving different engineering problems, products and potentially different winners.

There's also an assumption hiding in a lot of AI products today: that you should buy all three layers from the same company. I don't think you should feel obliged to.

The Three Layers

The easiest mental model is something like the OSI model, except much simpler. At the moment, I see three broad layers:

  1. Models — creating the intelligence.
  2. Infrastructure — running the models.
  3. Applications — turning models into useful workflows.

The boundaries aren't perfect. Companies will operate across multiple layers, and you could certainly divide each layer further. The point isn't to create a definitive taxonomy of AI; it's to recognise that these are meaningfully different problems that can increasingly be solved independently.

Layer 1: Models

This is the layer getting most of the attention.

OpenAI builds GPT. Anthropic builds Claude. Google builds Gemini. Moonshot AI builds Kimi. DeepSeek builds its models. Meta builds Llama. xAI builds Grok.

Within each provider, you're increasingly choosing between models optimised for different things: capability, latency, cost, context length, modality and so on. Anthropic has Opus, Sonnet and Haiku; other providers have similar families and tiers.

This is an insanely technical field involving mathematics, distributed computing, data engineering, optimisation, research and enormous amounts of compute. I won't attempt to rank its difficulty against the other layers, but the engineering problem is clearly different.

Microsoft and Apple are interesting cases. Microsoft builds its Phi models, although much of its frontier AI strategy has also involved its relationship with OpenAI. Apple has its own foundation models, particularly around on-device intelligence, while also working with external model providers.

So neither company is absent from the model layer. They're just approaching it differently from companies whose identities are more directly tied to winning the frontier-model race.

Layer 2: Infrastructure

Once you've got a model, you need somewhere to run it. That's a different problem.

You might use AWS Bedrock, Azure, Google Cloud or a specialised inference provider. You might run an open-weight model on your own GPU server, a private VM, Kubernetes, or the ridiculous machine sitting under your desk.

The engineering problems here are things like deployment, GPU scheduling, scaling, networking, latency, security, reliability and cost. Being exceptional at training models doesn't automatically make you exceptional at operating inference infrastructure, and vice versa.

This layer also creates another choice that often gets bundled together with the model itself. "I want to use model X" doesn't necessarily need to mean "I want to buy inference from company X."

That's already true for plenty of models, and I expect it to become increasingly normal.

Layer 3: Applications

Then there's the part you actually interact with.

For developers, that's becoming a large ecosystem in its own right. You have IDEs such as Cursor and Windsurf; coding tools such as Claude Code, Codex and GitHub Copilot; agent harnesses such as Devin; review tools such as CodeRabbit; and CLI or editor-based projects such as Aider.

These products aren't identical, and lumping them together hides plenty of interesting differences. But broadly they're solving the application problem: how do you take model capability and turn it into a useful workflow?

Doing that well requires another set of skills: UX, context management, tool use, agent orchestration, integrations and developer experience. Training the world's smartest model doesn't automatically make you the world's best IDE designer, just as building a great IDE doesn't mean you should start training a frontier model.

Why Should One Company Win All Three?

This is the assumption I find strange.

If OpenAI has the best model for what you're doing, why must OpenAI also provide the infrastructure and the application? If Anthropic builds your favourite coding harness, why must Claude always be the model underneath it? If AWS is great at operating GPU infrastructure, why should that dictate which IDE you use?

We're already comfortable composing vendors everywhere else in computing. You might run PostgreSQL on AWS, deploy with GitHub Actions, put Cloudflare in front of it, monitor it with Datadog and write the application in VS Code on a Mac.

Nobody looks at that architecture and asks why Amazon didn't make your laptop.

They're different layers of the stack. AI is becoming a stack too.

The Interfaces Are What Make This Interesting

For this to work well, the boundaries between the layers need to become boring. We're starting to see signs of that happening.

OpenAI-compatible APIs have become a de facto interface for talking to many models and inference providers. MCP is pushing towards a common way for AI applications to connect to tools and context. A2A and other efforts are exploring interoperability between agents, while common model formats and inference tooling make it easier to move some models between infrastructure providers.

None of these standards should be treated as settled. Some will win, some will disappear, and some will probably turn out to have drawn the abstraction in the wrong place.

The direction is what matters. As the interfaces become more standardised, your choice at one layer becomes less dependent on your choice at another.

And that's when composition becomes much more interesting.

Compose Your Own Stack

You don't necessarily need to wait for that future.

Take an open-weight model that works for you and run it on infrastructure you control. Put an OpenAI-compatible API in front of it, then connect an application that supports that interface. You've now separated the model, infrastructure and application decisions.

Maybe the best model for your workload changes next month. Swap it. Maybe running GPUs yourself turns out to be a terrible use of your time. Move the infrastructure. Maybe you love your coding environment but hate its default model. Keep the application and change what's underneath it.

The point isn't that everyone should self-host everything. Quite the opposite: the point is that these decisions don't necessarily need to be coupled.

You should feel comfortable composing the stack.

Yolo.

But What About Vertical Integration?

There is an obvious counterargument: vertical integration can be really good.

Apple has spent decades demonstrating that controlling multiple layers can produce a better overall experience. AI companies have similar incentives. If you control the model, infrastructure and application, you can optimise across all three, introduce features without waiting for standards, and make the whole thing much easier for customers to understand.

That's a real advantage, particularly for consumers.

So I'm not arguing that vertically integrated AI companies will disappear, or even that vertical integration is bad. I'm arguing that vertical integration shouldn't be mandatory.

That's an important distinction.

Developers in particular have spent decades assembling technology stacks from different vendors. I don't see an obvious reason they'll suddenly stop doing that for AI.

Interoperability Becomes A Competitive Advantage

This leads to an interesting competitive question: what happens when two products at one layer are roughly comparable, but one is dramatically easier to integrate?

Imagine two models with similar capabilities. One runs on several clouds, works with common APIs, plugs into the tools you already use and can replace your existing model with a configuration change. The other requires you to adopt the vendor's infrastructure and applications as well.

That interoperability has value.

The same applies in the other direction. The best infrastructure provider might not have the best model; it might be the provider that can efficiently run whatever model you want. The best coding application might not have its own model at all; it might win because it works brilliantly with everyone else's.

In that world, "works well with others" stops being an implementation detail and becomes a product feature.

The Future Is A Stack

None of this is particularly novel from a computing-history perspective, and that's almost the point.

We don't expect one company to provide our CPU, operating system, cloud, database, CDN, source control, observability platform and IDE. Those markets developed their own layers, and useful interfaces emerged between them. Sometimes vertically integrated products won; elsewhere, interoperable components did.

AI looks like it's heading in the same direction.

That means you don't necessarily need to choose an AI company. Choose the model that works for you, choose where you want it to run, and choose the application that gives you the best experience. Those might all come from one vendor, and sometimes that will be the best option.

But they don't have to.

The future of AI isn't necessarily one vendor. It's a stack.