ML/AI, CV
The AI War Is Moving Down the Stack
For the last few years, the AI industry has been obsessed with one question: who has the best model?
GPT vs Claude. Gemini vs Llama. Closed vs open. Bigger context windows, better reasoning scores, lower hallucination rates, more parameters. Every few months another benchmark chart appears and the leaderboard changes again.
But something interesting is happening underneath all of this. The model is slowly becoming one component inside a much larger system - and that changes where the real competition happens.
The next AI war may not be fought primarily at the model layer. It will be fought down the stack.
Models are becoming easier to swap
This does not mean models are becoming identical. They aren't. Different models still have meaningful advantages in reasoning, coding, latency, multimodality, cost and specialised workloads.
But the direction of travel is becoming difficult to ignore. There are more capable models, more open-weight models, more inference providers, more specialised models - and much lower inference costs.
Research published in the Journal of Economic Perspectives in 2026 found that the price of AI intelligence had fallen roughly a thousandfold, while the number of commercially available models, model creators and inference providers had expanded rapidly. The researchers also found substantial differentiation between workloads rather than one model universally dominating everything.
That changes the architecture. Instead of an application wired to one model, we are increasingly building an application that talks to a runtime, which routes each request to whichever model suits the task.
A coding task might go to one model. Document extraction to another. A cheap classification request to a small local model. A difficult reasoning problem to an expensive frontier model. Sensitive information might never leave the organisation at all - which is the same argument as deciding where each AI workload should run, applied one level up.
The application doesn't necessarily care which model answered. It cares whether the job was completed correctly, securely, quickly and economically. That is a major shift.
The model is becoming the CPU
Think about what happened with traditional computing. Most companies don't differentiate themselves because they use a better CPU. They differentiate through the systems built around it: operating systems, databases, networking, applications, developer platforms, security, workflows and data.
AI may be moving toward something similar. The model provides intelligence - but intelligence by itself doesn't create a production system. You still need to answer:
- What context should the model receive, and what tools can it access?
- What is it allowed to do, and who approved the action?
- Which model should handle this request, and what happens when it fails?
- What state should survive between sessions?
- How do we verify its output, and how do we know what it actually did?
- How much did the workflow cost?
Those questions don't belong to the model. They belong to the infrastructure around it.
The CPU analogy has a limit
CPUs are interchangeable because the instruction set is stable and standardised. Models are not there yet - prompts, tool-calling formats and failure modes still differ enough that swapping is real work. The point is the direction, not that we have arrived.
The emerging AI stack
A production AI application is starting to look much less like Prompt → LLM → Response.
Every one of those layers can become strategically important. And most of them survive a model replacement.
Swap Claude for GPT? Your permission model still matters. Swap GPT for Gemini? Your memory architecture still matters. Use an open model locally? Your tool integrations still matter. A dramatically better model arrives next month? Your workflows, customer data, evaluation framework, audit trails and integrations don't disappear.
That's where the moat begins to form.
Model routing may become normal infrastructure
We are already seeing organisations stop thinking in terms of choosing the model and start thinking in terms of allocating intelligence. The question changes from which model should our company use? to which model should handle this specific task?
Cisco is a useful worked example. In 2026 it rolled out a personal AI agent to all 90,000 of its employees, backed by hundreds of subagents on a deliberately model-agnostic internal platform, with much of the infrastructure running on-premises for cost and data control.
The routing split is the interesting part. Roughly 50-60% of requests go to open-weight models, 20-30% are handled by ordinary software automation rather than a model at all, and only a small remainder reaches a frontier model.
That architecture makes sense. You probably don't want your most expensive reasoning model deciding whether an email contains an invoice. You also don't want a tiny local model making a complex legal interpretation.
Suddenly, routing becomes more valuable than allegiance to a single model provider.
MCP is an infrastructure story, not just a tool story
The evolution of the Model Context Protocol is another clue. MCP originally attracted attention because it gave models a standard way to connect to tools and data. But look at where the protocol is heading.
The July 2026 MCP specification introduced a stateless core, header-based routing, caching, stronger authorization and support for long-running tasks. Its latest roadmap focuses further on agent messaging, HTTP-native infrastructure, agent identity and enterprise security. Google described the stateless changes specifically in terms of scaling agent infrastructure across cloud-native environments and ordinary load-balanced HTTP systems.
That sounds increasingly less like here's a cool way to connect a chatbot to something, and increasingly like distributed systems infrastructure for AI agents. It is the same trajectory traced in MCP gave agents tools, A2A gives agents colleagues.
This is what happens when a technology moves from demos to production. The interesting problems move downward - authentication, authorization, routing, state, retries, caching, isolation, identity, observability, governance.
The boring infrastructure eventually becomes the valuable infrastructure.
Memory may matter more than model intelligence
Consider a customer-support agent. Imagine replacing its underlying model tomorrow. How much knowledge disappears?
If the architecture is designed correctly, almost none. The company's customer history remains. Its product knowledge, policies, previous conversations, workflow state, permissions, integrations, evaluation history and business rules all remain. The new model simply plugs into that accumulated organisational context.
That means something important:
The line to remember
Models provide intelligence. Infrastructure provides continuity. Continuity compounds - and compounding assets create moats.
Tool access becomes more important than raw intelligence
A brilliant model trapped inside a chat box is useful. A slightly less brilliant model that can safely read your CRM, query your databases, create a support ticket, inspect production logs, update your project tracker, run code, deploy software and coordinate with other agents may be dramatically more valuable.
But the moment you give AI those capabilities, the architecture becomes serious. Now you need least-privilege access, workload identity, approval gates, sandboxing, network policies, credential isolation, tool authorization, audit trails and revocation - which is a whole engineering discipline of its own, and the reason you should assume the agent can escape.
The competitive advantage is no longer simply our AI is smarter. It may become our AI can safely do more. That's a very different engineering problem.
Observability becomes part of the product
Traditional applications execute deterministic code. Agents make decisions. That makes debugging fundamentally different.
When something goes wrong, teams need to reconstruct what the agent knew, what it retrieved, which model was used, what prompt was generated, what tool it called, what permissions it had, what the tool returned, why it chose the next action, and what the whole workflow cost.
Eventually, agent traces may become as fundamental as application logs and distributed traces are today. The companies that build strong evaluation and observability systems will accumulate something extremely valuable: knowledge about how AI behaves inside real workflows.
That dataset improves routing. It improves prompts, policies, tool design and model selection. And it makes changing the underlying model easier. Another moat moves down the stack.
The winners may be model-agnostic
There's an uncomfortable implication here for anyone building AI products. If your entire product advantage is we wrapped Model X really nicely, you may have a problem. Because Model X will improve, Model Y will catch it, Model Z will become cheaper - and some open model may eventually do the same task locally for a fraction of the price.
A stronger architecture assumes this will happen. Build the system so the model can be replaced, and own the things that cannot easily be replaced.
Then every improvement in foundation models becomes an upgrade to your platform rather than a threat to it.
We are watching the stack form in real time
A few years ago, building an AI product meant call an API. Now we're talking about agents, tool protocols, model routers, context engineering, memory systems, agent identity, sandboxes, policy engines, evaluation pipelines, observability, inference optimisation, agent-to-agent communication and dedicated AI infrastructure.
That isn't unnecessary complexity. It is what happens when a primitive becomes a platform.
The model isn't disappearing. Models will continue improving enormously, and the companies capable of building frontier models still possess formidable technical and economic advantages. But for everyone building on top of them, the strategic question is changing.
Don't ask only which model are we using? Ask: what remains valuable when we replace it? Because that is probably where your moat lives.
The next phase is operationalising intelligence
The first phase was about building intelligence. The next phase is about operationalising it.
The winners may not be the companies permanently attached to the smartest model. They may be the companies that can plug in any sufficiently capable model and instantly give it context, memory, tools, permissions, identity, workflows, security and the ability to actually get work done.
The model is becoming replaceable. The infrastructure around the model is becoming the moat.