Every view of the AI market begins somewhere.
There are increasingly more players in the AI ecosystem. Chip companies, clouds, frontier labs, open-weight labs, inference providers, orchestration layers, applications, enterprises, and states all enter the same market from different positions.
Every founder or participant you talk to has an intrinsic bias shaped by that position. A chip company sees growing demand for computation. A cloud sees the enterprise tenant. A frontier lab sees scarce capability. An application sees users, workflows, and outcomes. Each view can be internally rational without describing the whole system.
The goal of this interactive essay and research project is to make those incentives visible. It maps what each player wants to keep scarce, what it wants to turn into a commodity, which dependencies constrain it, and what it can do to gain leverage over time.
The AI economy is a repeated bargaining game.
Each player is trying to control one scarce bottleneck, make its suppliers interchangeable, and keep the proprietary learning generated by real use.
The prize is not just current margin. It is also the information that makes the player stronger in the next round: workload telemetry, model feedback, routing performance, user corrections, private evaluations, or observable business outcomes.
A player's position therefore depends on two things: control of the asset that is scarce now, and the quality of its outside options. When either changes, bargaining power moves—even if the companies and products remain the same.
The game changes when scarcity moves.
The analysis uses five regimes. They are not a fixed timeline. They are conditions that can coexist, overlap, or differ by market and workload.
Frontier capability
A market regime in which the best models are meaningfully more capable than the available alternatives.
- WHEN
- A clear model-quality gap
- TYPICAL HOLDERS
- Frontier labs
Compute capacity
A market regime in which demand for advanced chips, power, networking, and data-center capacity exceeds reliable supply.
- WHEN
- Demand exceeds available capacity
- TYPICAL HOLDERS
- Chips / Clouds
Execution & routing
A market regime in which several models are good enough to substitute for one another on a meaningful share of tasks.
- WHEN
- Many models meet the quality threshold
- TYPICAL HOLDERS
- Inference / Harnesses
Customer access & distribution
A market regime in which reaching users, owning the enterprise tenant, or controlling workflow defaults matters more than incremental model quality.
- WHEN
- Demand is concentrated behind a few channels
- TYPICAL HOLDERS
- Clouds / Applications
Proprietary learning
A market regime in which exclusive feedback, private evaluations, corrections, and outcomes matter more than access to generic capability.
- WHEN
- Generic capability is widely available
- TYPICAL HOLDERS
- Applications / Enterprises
Nine positions in the game.
These are strategic archetypes, not clean company categories. A single company can occupy several positions at once—and often integrates precisely to improve its bargaining position across them.
Chips & systems
Commoditize intelligence; preserve computation.
The chip company’s ideal world contains thousands of capable models, millions of applications, and no model provider powerful enough to dictate infrastructure economics.
Models are complements to compute. More models create more training; cheaper models create more deployment. The objective is not openness in the abstract, but abundant demand for a scarce computing platform.
Efficient compute and the software ecosystem around it
Models and applications
What they want
Many independent model builders broaden the market for compute and prevent one customer from dictating infrastructure economics.
Usage must expand faster than efficiency reduces compute per task, or cheaper intelligence will compress hardware demand.
Rapid architectural change preserves the value of flexible, programmable accelerators over workload-specific custom silicon.
Customers should build around the chip company’s software, networking, and systems so switching hardware remains costly.
No frontier lab or cloud should become large enough to act as a dominant buyer and negotiate away the supplier’s margin.
What they fear
At sufficient scale, a hyperscaler can optimize an accelerator around recurring workload shapes and reduce its exposure to general-purpose GPU economics. Google TPUs and AWS Trainium show this is already a deployed strategy; the constraints are workload fit, software maturity, and utilization—not whether custom silicon exists.
More value per unit of computation does not automatically increase chip demand. Consumption must expand quickly enough to offset falling compute per task.
A few large labs and clouds create a monopsony problem. They can negotiate aggressively, fund substitutes, and determine the shape of advanced demand.
Move beyond the chip into networking, systems, software, models, and inference—defense against the possibility that the accelerator itself becomes the replaceable layer.
Chip companies see which model operations slow down, which parts of their systems are fully used, and which workloads are growing. They use that evidence to decide what the next chips, networks, and software should improve.
Hyperscalers & clouds
Make every component interchangeable—except the tenant.
The cloud’s scarce asset is not merely compute. It is the combination of balance sheet, data-center capacity, enterprise contracts, identity, security, data gravity, and the control plane through which workloads operate.
Its ideal customer can choose among chips, frontier APIs, and open-weight models—but makes every choice without leaving the cloud.
Enterprise relationship, capital, data gravity, and control plane
Chips and models
What they want
Several credible model suppliers keep frontier labs from owning the customer or capturing the full value of cloud distribution.
Deployed custom accelerators, competing merchant vendors, and workload portability reduce dependence on any one infrastructure platform and improve procurement leverage.
Data, identity, policy, and orchestration should remain inside the cloud even when the customer changes models.
Switching should be easy among services within the cloud and meaningfully harder across cloud control planes.
Persistent memory and enterprise integration turn temporary model calls into durable, difficult-to-move infrastructure demand.
What they fear
A frontier lab with its own distribution and compute can reduce the cloud to wholesale infrastructure.
Nvidia can capture more of the system through chips, networking, software, model tooling, and inference.
A customer able to move data, memory, evals, traces, and orchestration has a much stronger outside option than one choosing models inside a single cloud.
Build custom chips, finance multiple labs, offer a multi-model platform, and bundle identity, data, security, and orchestration around the tenant relationship.
Clouds see which models customers choose, how much infrastructure each workload uses, and which services keep customers inside the tenant. They use this information to plan capacity, price bundles, and design their own hardware.
Frontier labs
Convert a temporary capability lead into durable control.
Frontier labs possess an unusually valuable but depreciating asset: a capability lead. Research diffuses, employees move, competitors distill behavior, hardware improves, and open models catch up.
Their central problem is converting temporary intelligence scarcity into a durable customer relationship.
Capability gap, proprietary weights, and model behavior
Compute, distribution, and tools
What they want
Competitive capacity suppliers prevent infrastructure scarcity from absorbing the economics of a temporary capability lead.
Applications, clouds, and enterprise channels should deliver the model to users without owning the resulting relationship.
Customers must supply enough workflow and task information for general capability to become economically useful.
Weights, training methods, and outputs should remain difficult to reproduce through open competition or distillation.
Memory, tools, workflows, and user habit should accumulate around the model before its raw quality advantage converges.
What they fear
When several models perform similarly, price and distribution become more important than frontier quality.
The application can own the user and workflow while the lab becomes a replaceable supplier.
A cloud or chip provider can capture the economics of a lab without credible capacity alternatives.
Enterprises can retain traces, corrections, and outputs to build systems that reduce future dependence.
Integrate upward into infrastructure and downward into agents and applications. Vertical integration functions as bargaining insurance before it becomes an operating strategy.
Frontier labs learn from prompts, failed answers, user corrections, and repeated patterns of use. This shows them where the model needs improvement and which capabilities customers value enough to keep using.
Open weight labs
Exchange serving monopoly for global distribution.
Open weight labs surrender the exclusive right to monetize inference for a checkpoint in exchange for global distribution, optimization, integration, and validation funded by other actors.
The release is irreversible for existing weights but says nothing binding about future checkpoints: open now does not mean open forever.
Model relevance, installed base, and ecosystem position
Global inference and distribution
What they want
External hosts and developers should improve serving, quantization, integrations, and hardware support at their own expense.
Global adoption should expand without requiring the developer to finance every region, data center, and customer relationship.
Benchmarks and integrations must keep the model salient enough that providers and applications continue to support it.
Multiple inference providers should compete to serve the weights rather than letting one platform capture distribution.
A large installed base can make future releases, tools, and compatibility decisions strategically important even without an inference monopoly.
What they fear
The provider owns the serving relationship, can switch models, and may retain the more durable customer relationship.
Restricted hardware access and policy shocks can limit development, distribution, or enterprise adoption.
Ecosystem partners may underinvest if they believe future frontier checkpoints will return to a proprietary API.
Use irreversible weight releases as a distribution strategy while preserving flexibility over future models, licenses, APIs, and monetization.
Open-weight labs learn from public benchmarks, community feedback, reported fine-tunes, and third-party integrations. Most private usage stays with hosts and applications, so the learning they retain is broad but less exclusive.
Inference providers
Turn abundant weights into scarce execution.
Inference providers want what frontier labs do not: many capable models whose weights are broadly available. Open weights remove the developer’s serving monopoly, but identical hosting pushes the market toward commodity pricing.
The durable metric is not cost per token. It is cost per accepted outcome.
Serving efficiency, capacity, and routing intelligence
Model weights and hardware
What they want
Many capable weights prevent one developer from taxing execution or bypassing the provider with a closed API.
Diverse accelerators and available capacity keep the physical input from absorbing the provider’s serving margin.
Optimization must remain difficult enough that systems expertise creates a durable performance and cost advantage.
Customers must prefer independent routing and execution over the convenience of a vertically integrated model or cloud bundle.
Workload-level records of cost, latency, quality, and failure should improve routing faster than competitors can copy it.
What they fear
If many providers serve the same model at the same quality, margin collapses toward hardware, power, and capital cost.
Hyperscalers can offer generic inference below cost to sell infrastructure and retain the tenant.
Model developers and large customers can remove the independent provider from the transaction.
Become an exchange rather than a cheap host: route each workload across models, hardware, prices, latency, and availability using proprietary outcome data.
Inference providers compare what each model costs to run, how quickly it responds, where it fails, and which hardware works best. That private comparison helps them route requests and improve utilization.
Harnesses & orchestration
Own the decision about which model gets called.
The harness sits between models and applications. It manages state, memory, tools, permissions, routing, evaluation, and execution.
Its ambition is to make individual models interchangeable while making orchestration persistent.
State, memory, tools, policy, evaluation, and routing
Individual models
What they want
Several viable providers make model selection a recurring decision rather than a fixed dependency.
Common tool protocols and APIs lower integration costs while allowing the harness to span suppliers and infrastructure.
Memory, permissions, and workflow history should persist outside any single model so substitution remains practical.
Applications should outsource routing and execution decisions instead of absorbing them into proprietary product logic.
Comparative quality and tool-performance data should compound inside the harness and improve every future routing decision.
What they fear
Clouds and labs can offer generic orchestration below cost to sell models or infrastructure.
Open connectors expand the market but weaken the layer if state, policy, and evaluation remain portable.
A wrapper over model APIs has no more defensibility than a thin application wrapper.
Accumulate a stateful asset—memory, workflow definitions, observability, policy, or routing intelligence—and embed it deeply in production.
Harnesses see which models, tools, and workflow steps succeed under each policy. If they keep the evaluation history and workflow state, they can improve routing without depending on any one model.
Applications
Turn distribution into a proprietary learning environment.
An application usually begins with little leverage: it rents intelligence, pays variable inference costs, and competes through interface and execution speed.
Distribution matters only when it produces exclusive learning from real tasks, corrections, private evals, and observable outcomes.
User distribution, workflow depth, and outcome data
Models, inference, and generic harnesses
What they want
Models, inference providers, and generic harnesses should compete for traffic rather than dictate the application’s economics.
User distribution must generate exclusive knowledge about real tasks, corrections, and successful outcomes.
The application should own the evals and outcome data that define what good performance means in its domain.
Each job should move to the best supplier for quality and cost instead of inheriting one model for the entire product.
High-volume tasks should migrate to owned or tuned models that create a credible outside option against frontier suppliers.
What they fear
Subsidized inference can buy growth, but eventually the application must reduce cost or find a more durable source of value.
A successful workflow becomes attractive for the frontier lab to enter directly.
Interfaces can be copied and generic features can move into foundation models.
Use multi-model routing and a task-specific internal model as credible outside options—even when frontier models remain part of the product.
Applications see what users are trying to accomplish, where a model fails, what users correct, and whether the task succeeds. This outcome-linked data helps them improve the product and reduce dependence on any one model supplier.
Enterprise buyers
Rent general intelligence; own particular intelligence.
Enterprise buyers want capability without transferring the knowledge that makes the firm distinct. They supply both money and the context required to make rented intelligence useful.
The resulting corrections, traces, evals, preferences, and outcomes are a jointly produced learning asset.
Proprietary context, objectives, and the organizational learning loop
Every external supplier
What they want
Internal evals should define acceptable quality so supplier substitution becomes measurable rather than theoretical.
Memory, orchestration, policy, and workflow history must remain portable instead of becoming part of the rented model.
Traces, corrections, preferences, and outcomes should strengthen the enterprise’s future system rather than only the vendor’s.
Contracts should preserve the ability to use outputs and feedback for tuning, training, and internal improvement.
The enterprise needs the technical and contractual ability to route work elsewhere and remove a provider without losing accumulated capability.
Rented general models should become an input to systems specialized around the organization’s proprietary knowledge and objectives.
What they fear
Without private evals the buyer cannot know whether switching models is safe, so theoretical choice creates little bargaining power.
Context and feedback can strengthen a supplier’s system while the buyer pays for the transaction.
Model portability is incomplete if memory, traces, policy, and adapted systems cannot leave the infrastructure provider.
Own the objective function, memory, feedback, adaptations, and substitution capability. Rent the frontier base model rather than attempting to own it.
Enterprises know which answers employees accept, which mistakes matter, and which workflows produce real business value. Keeping those evaluations, corrections, and outcomes lets them compare suppliers and build systems around their own needs.
States & regulators
Preserve national capacity and jurisdictional control.
States shape the game through jurisdiction, national capacity, market access, procurement, subsidies, and export controls. They are cross-cutting actors rather than one technical layer.
Their interventions can create resilience or become extractive when security rules protect incumbents and force firms into inferior domestic options.
Domestic capacity, market access, and legal authority
Foreign strategic dependence
What they want
Critical chips, models, infrastructure, and talent should remain available even when foreign supply or policy changes.
Sensitive data and deployed systems should remain subject to enforceable national law and oversight.
No foreign firm or government should hold an irreplaceable chokepoint over essential economic or security functions.
Domestic firms should remain capable of shaping technical progress rather than permanently purchasing capability from abroad.
Standards, subsidies, and procurement should direct private investment toward security, resilience, and national priorities.
What they fear
Critical chips, models, data, or infrastructure can create strategic dependency and policy exposure.
Export controls can constrain hardware access while accelerating efficiency, alternative supply chains, and open-weight distribution.
Rules can entrench incumbents, reduce competition, and impose inferior infrastructure on domestic users.
Combine restrictions with subsidies, procurement, localization, and coalition-building—but continually test whether intervention creates capacity or merely protects incumbents.
States learn where critical supply chains are concentrated, which foreign dependencies are difficult to replace, and how AI systems are used in practice. That evidence shapes procurement, subsidies, export controls, and regulation.
The stack is not a chain. It is a set of bargains.
Two players can be complements and adversaries at the same time. Clouds finance chip demand while developing custom accelerators. Applications create model demand while retaining the user relationship that lets them switch models. Enterprises supply the context that makes AI useful while trying to prevent that context from becoming a supplier's advantage.
Order matters. Selecting chips and then clouds asks how clouds affect the chip company's position. Reversing the order asks how chip suppliers affect the cloud. The relationship is shared; the strategic question is not.
The interactive version lets you change the scarce control point and inspect how each bilateral game changes. This reading version provides the underlying argument in a linear form.