A year ago, building an AI product often started with a simple question:
Which model should I use?
GPT or Claude?
OpenAI or Anthropic?
A local model or an API?
Today, that question is becoming less interesting.
New models are appearing constantly. Open-weight models are becoming more capable. Inference is getting cheaper. Developers can access models from companies like Qwen, DeepSeek, Meta, NVIDIA, and others without necessarily building everything from scratch.
So a more important question is emerging:
If the model becomes easier to access, where does the real value move?
I think the answer is:
The workflow.
The AI Stack Is Changing
The old mental model was simple:
User
↓
AI Model
↓
Answer
Then applications started adding RAG, tools, memory, and APIs:
User
↓
Model
↓
RAG + Tools
↓
Answer
Now we're moving toward something more like:
User Goal
↓
Agent / Orchestrator
↓
Model Selection
↓
Tools + APIs + Data
↓
Multiple Agents
↓
Verification
↓
Workflow
↓
Real Result
The model is still important.
But it is no longer necessarily the whole product.
What Happens When Models Become Interchangeable?
Imagine that tomorrow a new open model becomes significantly better at coding.
And two weeks later, another model becomes better at reasoning.
Then another becomes much better at image generation.
Would you rebuild your entire application every time?
Probably not.
A good AI application should be able to change the model without changing the entire product.
That means the architecture starts looking like this:
AI WORKFLOW
↓
Model Router
↙ ↓ ↘
Model A Model B Model C
↓ ↓ ↓
Tools / APIs
↓
Result
The application doesn't need to be married to one model.
It needs to know which model is useful for which job.
This is already becoming a real infrastructure problem. NVIDIA's NeMo Switchyard, for example, is designed to route AI workloads across different models based on factors such as capability, cost, and latency.
But Aren't Open Models Free?
This is where things get interesting.
When people hear:
“This model is open.”
they sometimes interpret it as:
“AI is now free.”
That's not really how the economics work.
The model weights may be available.
But running the model still requires:
- GPUs
- electricity
- memory
- networking
- storage
- inference infrastructure
- monitoring
- scaling
- engineering
- reliability
So there are several ways an open-model company can build a business.
1. Cloud
Give developers access to the model without requiring them to buy GPUs.
Open Model
↓
Cloud Infrastructure
↓
Developer
↓
Usage
↓
Revenue
2. API
The developer doesn't want to manage infrastructure.
So they pay for inference.
Your Application
↓
API
↓
Model
The model may be open, but convenient access isn't necessarily free.
3. Enterprise
Large companies often need more than a model.
They need:
- private deployment
- security
- compliance
- monitoring
- support
- customisation
- predictable performance
That's another layer where companies can charge money.
4. Infrastructure
Sometimes the biggest opportunity isn't the model itself.
It is everything required to run thousands or millions of model requests reliably.
Free Access Can Also Be a Business Strategy
There's another interesting idea here.
Suppose a company gives developers free access to a model or a limited amount of compute.
Why?
Because the goal may not be to make money from the first request.
The goal can be:
Free access
↓
Developer tries it
↓
Developer builds something
↓
Users arrive
↓
Usage grows
↓
Developer needs more compute
↓
Paid infrastructure / API / enterprise
So:
Free can be customer acquisition.
The company gets developers into its ecosystem first.
Developers build products on top of the technology.
When those products grow, their requirements grow too.
More inference.
More GPUs.
More storage.
More reliability.
More enterprise features.
That's where monetization can begin.
But Here's the Bigger Opportunity
If models are becoming easier to access, developers don't necessarily need another application that says:
“Here is our AI model.”
They need applications that say:
“Tell me what you want done.”
That's a very different product.
Consider two systems.
System A — Chatbot
You:
“Write a marketing campaign.”
AI:
“Sure. Here's a marketing campaign.”
Useful.
But you're still doing most of the work.
System B — Agent Workflow
You:
“Launch a marketing campaign for my new SaaS.”
The system could potentially:
Understand the product
↓
Research the audience
↓
Create campaign strategy
↓
Generate copy
↓
Create visual assets
↓
Review the content
↓
Prepare channel-specific posts
↓
Schedule them
↓
Track results
Now the AI isn't just generating text.
It's participating in a workflow.
That's the important shift.
One Model Doesn't Need to Do Everything
This is where multi-model systems become interesting.
Imagine a workflow with five steps:
Research
↓
Reasoning
↓
Coding
↓
Image Generation
↓
Review
Why force one model to handle all five?
Maybe:
- Model A is excellent at research.
- Model B is better at reasoning.
- Model C is better at coding.
- Model D is better at images.
- Model E is cheap and fast enough for verification.
So the workflow can become:
USER
↓
ORCHESTRATOR
↓
┌───────────┼───────────┐
↓ ↓ ↓
Research Reasoning Coding
Model A Model B Model C
↓ ↓ ↓
└───────────┼───────────┘
↓
Image Model D
↓
Review Model E
↓
RESULT
The user doesn't need to know all of that.
They simply need the result.
This Changes the Developer's Job
A few years ago, developers spent a lot of time asking:
Which framework should I use?
Then:
Which database?
Then:
Which model?
Now we're increasingly asking:
How should these models, tools and agents work together?
That's a much more interesting engineering problem.
You need to think about:
Routing
Which model should handle this task?
Context
What information should the model receive?
Tools
What can the agent actually do?
Memory
What does it need to remember?
Reliability
What happens when a model fails?
Verification
How do we know the result is correct?
Cost
Why use an expensive model when a cheaper one is sufficient?
Execution
Can the system actually complete the task instead of just explaining how to do it?
These problems don't disappear when models become better.
In some ways, they become more important.
The Real Product May Be Above the Model
This is the part I find most interesting.
Imagine two companies.
Company A
“We have the smartest model.”
Company B
“Give us the goal. We'll figure out which models, agents and tools are needed to accomplish it.”
If models continue improving and becoming more interchangeable, Company B has an interesting advantage.
Because its product isn't dependent on one particular model.
It owns the workflow.
Model = Engine
Agent = Worker
Tools = Capabilities
Workflow = Process
Product = Outcome
The engine can change.
The workers can change.
The tools can change.
But the workflow can remain.
This Is Where Multi-Agent Systems Become Useful
A multi-agent system doesn't necessarily mean:
“Let's add 20 AI agents because agents are cool.”
That's not useful.
The better question is:
What different responsibilities exist inside this task?
For example:
Planner
↓
Researcher
↓
Builder
↓
Reviewer
↓
Executor
Each agent has a job.
And each job can potentially use the model that makes the most sense for it.
That's much closer to how software systems have always been designed.
We don't use one database for every possible problem.
We don't use one programming language for every task.
Why should we assume one AI model will always be optimal for everything?
What We're Exploring With Xenition
While working on this problem ourselves, we started asking a different question:
What if the user never had to care which model was being used at all?
That's one of the ideas behind what we're building with Xenition.
Xenition is an all-in-one AI workspace where multiple agents, models, tools, and workflows can work together.
Instead of asking users to manually decide:
“Which model should I use for this step?”
the goal is to let the workflow handle more of that complexity.
For example, one part of a workflow might need strong reasoning.
Another might need code generation.
Another might need image generation.
Another might simply need a fast, inexpensive model for a small task.
The interesting part isn't simply that Xenition uses multiple models.
The interesting part is hiding that complexity from the user.
The user shouldn't have to think:
Should I use Qwen, Claude, GPT, DeepSeek, or another model for this step?
They should be able to say:
“Here's what I want to accomplish.”
And the system should handle the rest.
The Biggest Opportunity for Developers
This doesn't mean developers should stop building models.
Models will remain extremely important.
But there is a huge opportunity in building the layers around them.
Things like:
- agent orchestration
- model routing
- memory
- tool calling
- workflow engines
- evaluation
- verification
- observability
- permissions
- data integration
- automation
- human approval
- execution
These are the things that turn:
“AI generated something.”
into:
“The work actually got done.”
And that's a much more valuable outcome.
So What Should Developers Build?
I don't think the answer is:
“Build another chatbot.”
And I don't think it's always:
“Train another bigger model.”
A more interesting question is:
What job can AI actually complete from beginning to end?
Don't start with:
“Which model should I use?”
Start with:
“What outcome should the user get?”
Then work backwards.
Desired Outcome
↓
Required Workflow
↓
Required Tools
↓
Required Agents
↓
Best Model for Each Task
↓
Verification
↓
Execution
That changes how we build AI products.
The Model May Not Be the Moat
This is probably the biggest lesson.
If your entire product depends on:
“We use Model X.”
then what happens when Model Y becomes better?
Your advantage can disappear overnight.
But if your product has:
- excellent workflows
- useful integrations
- proprietary context
- strong execution
- reliable automation
- great user experience
- accumulated workflow knowledge
then changing the underlying model doesn't destroy the entire product.
It can actually make your product better.
The Future May Not Be Model vs. Model
It may be:
Workflow vs. Workflow.
The model is becoming easier to access.
Agents are becoming more capable.
Tools are becoming easier to connect.
Open models are expanding the number of choices developers have.
And model-routing infrastructure is making it increasingly practical to use different models for different jobs.
So perhaps the most important question for the next generation of AI applications isn't:
“Who has the best model?”
It's:
“Who can turn all these models into the best experience for getting real work done?”
The model is the engine.
The agent is the worker.
The workflow is the product.
And ultimately:
Don't build around a model. Build around a job.
Top comments (0)