Every view of the AI market begins somewhere.
There are more and more participants in the AI world. Chip makers, cloud services, advanced research labs, open-weight labs, inference providers, management layers, applications, businesses, and governments all join the same market from different angles.
Every founder or participant you talk to has a natural bias based on their role. A chip company notices growing need for computing power. A cloud provider sees the tenant relationship and the control plane around it. An advanced research lab sees limited capability. An application focuses on users, tasks, and results. Each view makes sense on its own but does not show the full picture.
The goal of this interactive essay is to make those incentives legible. 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 decisive control point shifts from owning the best model to controlling the conditions under which autonomous intelligence may act, learn, replicate, and acquire resources. Every human institution wants machine intelligence to be abundant; each wants its own objectives, authority, and claims on the resulting surplus to remain scarce.
The AI economy is a repeated game between capturing value today and building the moats to win tomorrow.
Every player is playing several games at once: it may control one bottleneck, depend on another, and lose the user somewhere else.
Future upside may come from an expanded version of today's market or from a capability discontinuity that makes current market boundaries comparatively small. Durable advantage can still determine who creates, accesses, and retains that value: workload telemetry, model feedback, routing performance, user corrections, private evaluations, or observable business outcomes.
A player's position therefore depends on control of the relevant asset, the quality of its outside options, and which game is being analyzed. The same company can be powerful in distribution, weak in inference, and dependent on another player for execution.
Capital is part of that position. Cheap financing can reserve scarce supply, subsidize adoption, fund complements, and survive longer periods of negative economics. Around Nvidia and the neocloud ecosystem, contracted demand and GPU assets can help make a data-center build financeable. Vendor investment, capacity agreements, and ecosystem support can then strengthen the buyer, which deploys more of the vendor's platform and may win capacity slots that a less financed competitor cannot.
The relevant payoff is also actor-specific. If OpenAI or Anthropic assigns a meaningful probability to an AGI-scale discontinuity, the expected value of building a beneficial system or preventing a catastrophic one can outweigh current profits. Behavior that appears financially irrational from outside can be internally rational under that payoff function.
This makes conflicts of interest part of the analysis. A lab may sincerely describe risks while benefiting from the capital or authority those risks justify. A cloud may call its marketplace neutral while selling preferred models and chips. A supplier may strengthen a customer that buys its systems. The test is not whether a claim is sincere, but whether the evidence survives the claimant's incentives.
AI isn't one game.
Treating the AI economy as one single game is the framework's biggest limitation. Intelligence, distribution, execution, inference, data, and users are separate competitions happening at the same time. Each has different players, scarce assets, and equilibrium dynamics.
Who owns intelligence?
The contest to create the most valuable model capability and decide whether it remains metered through a closed service or diffuses through deployable weights.
Persistent quality gaps let leading labs earn unusually high margins. When several models become good enough and open alternatives are easy to use, pricing power breaks up and leverage moves to products, clouds, and tools closer to the user.
- EXAMPLES
- OpenAI / Open-source ecosystems / DeepSeek
- CONTROL POINT
- Models and model rights
- DIRECT ROLES
- Frontier labs / Open weights
Who owns distribution?
The contest to become the interface, developer environment, enterprise suite, or agent surface through which demand reaches models and tools.
Distribution tends toward a few workflow-specific defaults, but multi-homing remains credible when state, identity, and evaluation are portable.
- EXAMPLES
- ChatGPT / Cursor / Microsoft Office / Claude Code
- CONTROL POINT
- The route into a workflow
- DIRECT ROLES
- Clouds / Frontier labs / Harnesses / Applications
Who owns execution?
The contest to provide the secure, stateful environment in which agents run code, use tools, access credentials, and complete long-lived work.
Commodity sandboxes compete toward infrastructure cost; durable rents require superior reliability, security, startup performance, or persistent workflow state.
- EXAMPLES
- Daytona / Modal / Cloudflare
- CONTROL POINT
- The agent runtime
- DIRECT ROLES
- Clouds / Harnesses
Who owns inference?
The contest to execute model workloads at the best combination of quality, latency, reliability, availability, and cost.
Scale and utilization favor concentration, but model and hardware plurality support multi-homing. Margins compress unless optimization, capacity, or routing data stays proprietary.
- EXAMPLES
- Together AI / Fireworks AI / Groq / Baseten
- CONTROL POINT
- Serving and routing
- DIRECT ROLES
- Chips / Clouds / Inference
Who owns data?
The contest over the internal knowledge, corrections, evaluations, and observed outcomes that make general models useful in a particular organization.
The efficient bargain shares enough context to improve the system while leaving customer-specific objectives and outcomes portable, auditable, and controlled by the enterprise.
- EXAMPLES
- Enterprise internal knowledge
- CONTROL POINT
- Enterprise context and outcomes
- DIRECT ROLES
- Applications / Enterprises
Who owns users?
The contest to convert an installed base, operating-system position, identity layer, or habitual product into the default route to AI.
Defaults and bundling favor incumbents; differentiated products preserve contestability when users can switch without losing identity, history, or workflow state.
- EXAMPLES
- Google / Apple / Microsoft
- CONTROL POINT
- Existing users and default choices
- DIRECT ROLES
- Clouds / Frontier labs / Applications
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.
At sufficient scale, the balance sheet becomes part of the product. Vendor investment, capacity purchases, anchor contracts, and an ecosystem’s ability to borrow against contracted demand or GPU assets can help new clouds and data centers win scarce deployment slots. That creates buyers, expands the installed base, and can reinforce the vendor’s standard before competitors can match the footprint.1
STRATEGIC NOTES
The financing loop is broader than a chip vendor directly making every loan. A neocloud can use contracted demand and GPU-backed assets to raise project or asset-backed debt, while a platform supplier can reinforce the loop through equity investment, purchase commitments, capacity agreements, software support, and ecosystem signaling. In CoreWeave’s case, public filings describe debt used to acquire GPU servers while NVIDIA has also been a supplier, shareholder, and strategic partner. The relevant game-theory point is that capital access can help create the demand signal from which the platform benefits.
↩
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.
Neoclouds and data-center developers need contracts, collateral, and credible sponsors that lower their cost of capital and let them reserve more capacity.
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, rather than 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, inference, and ecosystem finance, using capital and commitments to expand demand while defending 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 customer relationship.
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 customer relationship.
Clouds see which models customers choose, how much infrastructure each workload uses, and which services keep customers inside the cloud account. 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.
Some frontier labs believe a near-term capability discontinuity will create markets far larger than today’s. Under that payoff function, extreme spending, governance, and safety choices can be rational even when ordinary software economics would reject them. The belief may be correct, but it can also discourage investment in distribution and outside options if the discontinuity arrives later or diffuses quickly. It creates an epistemic conflict as well: the institution judging the stakes benefits from being financed and trusted to pursue them.12
STRATEGIC NOTES
The relevant objective may not be market share or near-term profit. OpenAI’s nonprofit-controlled public-benefit structure and Anthropic’s public-benefit corporation and Long-Term Benefit Trust explicitly encode objectives beyond ordinary shareholder value. If either lab assigns a non-trivial probability to rapid AGI takeoff, it may treat the payoff from producing beneficial AGI or avoiding catastrophic AGI as effectively enormous relative to ordinary commercial returns. Modeling that lab as a conventional profit maximizer can therefore mispredict its investments, release strategy, safety commitments, or willingness to sacrifice margin.
↩A high-stakes worldview does not remove conflicts of interest. The same lab may estimate the probability and severity of transformative AI, argue that only frontier-scale institutions can manage it, seek the capital and regulatory latitude to keep scaling, and gain status or market power when outsiders accept that argument. The belief can be sincere and the conflict can still be severe; analysis should separate the claim, the evidence, and the claimant’s payoff from the claim being believed.
↩
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.3
LEARNING NOTES
Frontier labs acquire data beyond means of leverage usage data as they also acquire 3p data. Even with zero-retention policies, they can still improve their models through aggregate usage signals, opt-in data, synthetic data, and internal evaluations. They may not retain specific enterprise prompts, but they can still identify failure patterns and recreate them for training.
↩
Open weight labs
Trade exclusive control for wider adoption.
Open weight labs trade exclusive control of a checkpoint for wider adoption, 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 customer account.
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 such as 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.
Yet AI-native applications can become powerful precisely because they are not constrained by old product categories. They can turn complex stacks of models, tools, and infrastructure into intuitive experiences, make previously expert capabilities accessible, and create entirely new markets, as Suno has done for music creation and Midjourney for image generation.
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.1
LEARNING NOTES
In practice, reinforcement learning is only as effective as the objectives, graders, and evaluation suites that define and validate success. Frontier labs have the infrastructure and engineering expertise to run reinforcement learning at scale, but enterprises often have the deeper domain knowledge required to measure what matters: which errors are tolerable, which edge cases are consequential, and what a successful outcome actually looks like. Boilerplate evals miss this nuance, producing weak reward signals, datasets, and improvements. The bottleneck is converting enterprise judgment into rigorous, repeatable evals and pairing it with the infrastructure required to train against them.
↩
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 choose one of the six simultaneous games and inspect how each bilateral relationship changes inside it. This reading version provides the underlying argument in a linear form.