In Dune, spice is not merely a valuable commodity. It is the condition that makes civilization possible: it extends life, enables interstellar travel, and comes from one planet. Whoever controls Arrakis controls more than a product. They control the routes, the economy, and the political order built on top of it.
The analogy to AI is useful—but only if we are careful with it.
Tokens are not literally spice. They are not a single-source natural resource, and the supply of models is not fixed on one desert planet. Models compete. Prices fall. Open-weight alternatives appear. A token is a unit of usage, not an asset your company can possess in the same way it possesses a customer relationship or a codebase.
The useful parallel is dependency.
When a system depends on an input it does not control, power accumulates at the boundary: in the API, the billing relationship, the data policy, the runtime, and the rules that decide what happens when the supplier changes its terms. The question is not whether you own the model. The question is whether your product can change models without losing its memory, behavior, quality bar, and operating knowledge.
The model is the spice. Your product is the power built around it.
That is the more precise version of “own your tokens.”
Dune gets us to the question, not the answer
It is tempting to say that every company should own its own inference. That would be the wrong conclusion.
Most companies should not train a frontier model, build a global GPU fleet, or operate every layer of the serving stack. Owning everything is not the same as having leverage. It can simply mean taking on a large amount of undifferentiated work.
The better question is: which parts of the system compound?
For an agent, those parts are usually:
- the private context and data it can access;
- the prompts, tools, and workflows that express how the work gets done;
- the memory and state that accumulate across tasks;
- the evals that define what “good” means;
- the policies that govern risk, privacy, and spend;
- and the routing decisions that choose a model for a particular job.
Those are the parts that teach the system about your company. They are also the parts that become expensive to reconstruct after a provider switch.
The model is important. It is not the whole product.
“Own your tokens” means own the boundary
A direct provider call looks simple:
application → model provider
But as an application grows, provider decisions spread across the codebase. One service owns one API key. Another has its own retry behavior. A third uses a different prompt format. Spend is split across dashboards. The team cannot easily answer which provider saw a sensitive request, or what happens when the primary model is slow.
A control plane makes those decisions explicit:
agent → policy + routing boundary → models and providers
That boundary might be a managed AI Gateway, an open-source gateway you operate, or a small abstraction layer in your own code. The important property is not the product name. It is that the application has one place to express policy.
Vercel’s AI Gateway is one example of this pattern. Its documentation describes a unified endpoint for hundreds of models, provider routing, retries, fallbacks, spend monitoring, and no markup on tokens. It lets application code select a model through a common interface while provider-specific work happens behind it.
That is valuable for three reasons:
- Reliability: a provider outage does not automatically become your outage.
- Visibility: token usage, latency, and spend can be measured across providers.
- Optionality: changing the model can become a bounded configuration and evaluation exercise instead of a rewrite.
A gateway is not magic, and it is not sovereignty. It is a place to put the decisions that would otherwise be scattered across your application.
Be model-agnostic where it matters
Model agnosticism is sometimes presented as if all models were interchangeable. They are not.
Models differ in reasoning, context handling, tool use, latency, price, safety behavior, and failure modes. A fast model may be ideal for extraction and wrong for planning. A frontier model may be worth its cost for one decision and wasteful for the next thousand. An open-weight model may be attractive for volume or data residency and still need a different prompt or evaluation harness.
So the goal is not to pretend models are the same. The goal is to make the differences an explicit choice rather than an accidental dependency.
Vercel’s Gateway supports model fallbacks, allowing a request to try a primary model and then backup models or providers. That makes it possible to build a portfolio:
- a cheap model for routine work;
- a fast model for interactive moments;
- a frontier model for difficult reasoning;
- an open-weight model for selected high-volume or sensitive tasks;
- and a direct or self-hosted path for emergencies.
This is not abstraction for its own sake. It is an operational form of freedom.
The right standard is simple: a model change should be an engineering project with a known scope, not an existential threat to the product.
The historical lesson is interoperability
The strongest historical parallel is not that everyone should build their own servers. It is that open systems create leverage at the boundaries.
The Internet did not win because every company built its own telephone network. It won because common protocols separated applications from the underlying network providers. The IETF’s OpenStand principles make the broader case: interoperability leaves room for multiple implementations, vendors, and business models.
That is the AI lesson:
You do not need to own every layer. You need to prevent one vendor from owning every layer that matters.
A company can rent compute. It can rent inference. It can use a managed gateway. But its application layer should remain legible and portable:
Your agent
prompts · tools · memory · policies · evals · workflows
↓
portable model interface / gateway
↓
hosted model · open-weight model · self-hosted model
The goal is not to eliminate dependencies. That is impossible. The goal is to put dependencies behind replaceable boundaries and keep accumulated knowledge on your side of them.
Open source is a means of ownership
“Build your own agent” does not mean writing every primitive from scratch. It means owning the agent’s behavior and keeping the architecture inspectable.
Open-source frameworks matter because they make the state, tool calls, retries, and orchestration visible. They give a team something it can inspect, fork, test, and move. Vercel’s Open Agents is an example of this direction: an open-source cloud agent template that combines AI SDK, Gateway, Sandbox, and Workflow SDK. The infrastructure can be managed; the shape of the agent remains available to understand and extend.
Use open tools for the parts that encode your product’s judgment. Use managed infrastructure for the parts that are expensive, boring, or operationally specialized.
A better rule than “own everything” is:
Buy the commodity. Own the compounding decisions.
The commodity may be inference. The compounding decisions are the workflows, feedback loops, safeguards, and understanding of what good looks like in your domain.
Do not replace one lock-in with another
A managed gateway can reduce model-provider lock-in while creating gateway lock-in if you use proprietary features everywhere. That is not an argument against gateways. It is an argument for keeping them at the thin waist of the system.
Keep the agent logic in your repository. Keep prompts and evals in version control. Use standard request and response shapes where possible. Keep tool schemas portable. Export traces and usage data. Maintain a direct-provider path for emergencies. Test at least one open-weight or self-hostable fallback. Treat gateway-specific routing rules as configuration, not business logic.
Ask yourself:
If this gateway disappeared tomorrow, could we run the agent directly against a provider with a focused engineering sprint—or would we need to rebuild the company?
If the answer is the second one, you have not created optionality. You have moved the dependency.
A portability test for your next agent
You probably have healthy model independence if:
- changing providers mostly changes configuration;
- prompts are stored in your repository;
- evals run against more than one model;
- tool schemas are portable;
- agent memory can be exported independently of the vendor;
- usage, latency, and quality data are available outside one provider dashboard;
- you can route different tasks to different models;
- you have a fallback for provider outages;
- you know which providers receive each category of data;
- and a model-swap exercise produces a migration plan, not a crisis meeting.
You are probably locked in if your prompts, traces, evals, and memory live only in a provider dashboard; if a proprietary runtime owns your workflow state; if tool calls use vendor-specific schemas everywhere; or if moving models means rewriting the agent rather than changing a model identifier and rerunning your evals.
The test is not whether you can switch providers in five minutes. The test is whether switching providers is a bounded engineering project instead of an existential one.
The machine is the moat
The next generation of AI products will not be defined only by who has access to the most capable model. Models will continue to change, multiply, and become easier to access.
The durable advantage will sit around them:
- proprietary context;
- reliable workflows;
- useful tools;
- well-designed memory;
- task-specific evals;
- feedback loops;
- security policies;
- and a routing system that knows when to spend, when to save, and when to say no.
Guillermo Rauch’s formulation is the cleanest summary: make the model a cog in a machine you own.
In Dune, control of spice creates leverage because the entire civilization depends on a narrow supply chain. AI is different: the supply is competitive, the models are substitutable to different degrees, and the resource itself is not your moat.
The lesson that survives is this: do not let a changing supplier own the accumulated system that makes your product valuable.
Use the best model available. Change it when the economics or quality changes. Route sensitive work according to policy. Keep your provider relationships portable. Build on open interfaces. Maintain an escape hatch.
The model may be rented.
The machine that turns it into a product should be yours.