This article was originally published on MIT Technology Review Italia.
A few instants after the AI “Big Bang,” the supply market is still in a phase resembling a quark-gluon plasma: the fundamental components and control points have not yet settled into durable combinations. The engineered enterprise should not bet on which configuration will prevail. It should preserve enough granularity to separate the control points that matter, and enough modularity to recombine them as the market takes shape.
In May, I argued that “AI adoption” is the wrong frame for describing the transformation under way. The object of strategy is not upgrading the digital toolkit, but the organization of the enterprise itself: how knowledge is produced, work is coordinated, decisions are made, and judgment is preserved once AI enters the organization’s operating architecture.
Four months later, the environment in which the enterprise is being engineered is still taking shape: the AI supply ecosystem, regulation, geopolitics, and competitive structure are evolving together. What looked like a single strategic choice — which model or platform to place at the center of the AI architecture — already comprises at least six partly interdependent decisions: model selection, control over adapted models, post-training infrastructure, the location of inference, routing, and rights over the information and meta-information generated during operation. These control points are already separating and recombining. Analysts distinguish revenue from applications, foundation models, and inference hosting; for the engineered enterprise, the segmentation is finer. Today there are at least six interconnected macro-categories of strategic decisions.
Six decisions hidden inside a single choice
| Decision macro-category | What is actually being chosen |
|---|---|
| Which models and capabilities? | Proprietary APIs, open-weight models, specialized models, or a portfolio of models |
| Who controls the adapted model? | Whether weights and checkpoints from fine-tuning or post-training remain locked to the provider, or can be controlled and moved by the customer |
| Who provides the post-training infrastructure? | In-house infrastructure, hyperscaler services, or specialized platforms used to adapt an existing model after its initial training |
| Where is inference executed? | Provider API, hyperscaler, specialized inference provider, private cloud, on-premises, or self-hosted |
| Who decides the routing of each request? | In-house router, third-party routing service, or the provider’s native routing |
| Who can use the information and meta-information generated during operation, and for what purpose? | Who can observe, retain, and use prompts, outputs, corrections, outcomes, telemetry, and the intermediate state generated by the model and carried from one sequential call to the next, for continuity or improvement |
Table 1. Six decisions in the enterprise’s AI architecture.
This map is provisional: the boundaries will shift as providers specialize and recombine functions. Treating the six decisions as a single vendor choice can unknowingly transfer control over model availability, inference, fallback, data flows, and learning. A design shortcut can become an architectural weakness.
Model selection, infrastructure, and serving extend familiar cloud-sourcing questions; custody of adapted weights, live routing, and rights over the information and meta-information generated during operation are less familiar control points that are increasingly contractable separately. The enterprise can rent post-training while retaining checkpoints or weights, and separate serving from routing: the former determines where computation happens, the latter which model or approved endpoint receives the call. Model choice affects capability, licensing, and switching; serving affects cost, latency, and data residency; routing affects fallback and comparative performance; post-training and checkpoints affect adaptation and portability. A single agreement can still bundle all six decisions.
From ranking models to a mixture of models
A single global ranking is not enough: models differ in capability, cost, latency, and failure modes. A mixture-of-models approach can route different tasks to different backends instead of electing one model as a universal default.
Light Society does this between full LLMs and distilled surrogates; Cursor’s router reports that no single model dominates every category of coding work. At the INSEAD AI Forum Europe, Theos Evgeniou framed the same problem: different models for different tasks, with token cost managed dynamically. The question becomes: which model should perform this task, under these constraints?
Routing also creates an informational position: whoever manages it observes successes, failures, fallbacks, and comparative corrections across real workflows — knowledge that a single provider may not see, and which ages as models or interfaces change. On August 19, Stripe announced an agreement to acquire OpenRouter, a gateway that routes and optimizes token usage across more than 400 models from more than 80 providers.
Figure 1. Ranking models, or composing them. In an enterprise workflow, a mixture-of-models approach can route calls to different backends. Performance depends on the portfolio and the routing policy as well as on individual models; data-use terms can also vary across backends. Source: Marcello Vena, 2026.
The strategic rights that few enterprises hold
The sixth decision concerns the information and meta-information generated during operation: who can observe, retain, and use it.
An interaction with AI produces both an immediate output and information about what happens afterward — whether it is accepted, corrected, rejected, repeated, escalated, executed, or followed by a different human decision. Hagiu and Wright call the more general mechanism data-enabled learning: products can improve thanks to data generated by customers, across different users or through repeated use by the same customer. Generative and agentic workflows enrich this trail by showing what failed and how it was corrected.
The contractual boundary is more granular than a generic “right to learn”: observation, retention, and use for improving models or services are distinct permissions. Agentic systems also generate intermediate state carried between sequential calls, part of which may remain opaque or locked to the provider.
Most of the first five decisions can, at some cost, be revisited by substituting or re-creating the necessary capabilities elsewhere. Information already absorbed by another organization cannot be recalled in the same way. In stateful workflows, routing freedom can also narrow before a task is complete: whoever controls the intermediate state partly determines who can route the next call.
What Cursor and Windsurf show
Cursor and Windsurf show just how unstable the supply market still is. Both began as AI coding environments that organized the developer’s workflow around frontier models supplied by others. Cursor later moved up the stack: by 2026 it had developed Composer models, co-developed Grok models with SpaceXAI, and built a router. It also stated that it used trillions of tokens of Cursor data to train one of those models, while the router infers performance from what the user does immediately afterward — recombining functions that the market was separating.
This expansion did not eliminate upstream dependency. After SpaceX’s acquisition of Cursor, at an implied equity value of $60 billion, OpenAI chose to end its supply agreement. Windsurf had run into the problem earlier: while OpenAI was pursuing its acquisition, Anthropic sharply cut first-party access to Claude; the deal then fell through, followed by an acqui-hire by Google and the acquisition of the remaining business by Cognition. When OpenAI released GPT-6 Astra on September 3, it did not make it available through its supply relationship with Cursor, while Cognition integrated it into Devin the same day it launched.
In both cases, the providers’ decisions followed their own strategic positioning more than customer demand; Anthropic’s decision, in the same week, to keep supplying Cursor after the SpaceX acquisition shows the same mechanism with the opposite sign. Access to models is still treated as a competitive lever, not simply as a product to be sold wherever demand exists.
The stack is still taking shape
As these decisions become separately contractable, new supply positions are emerging along the AI stack. Some companies specialize; others expand across multiple functions and recombine them.
Thinking Machines entered through managed post-training with Tinker; River launched an API for the training layer; Project Tapestry is developing distributed consortium training to preserve local control over data and derived models. Thinking Machines later released Inkling, a customizable open-weight multimodal model built on Tinker, moving from post-training infrastructure into model supply.
Some positions can become infrastructure for a broader market. On September 3, Nvidia announced an agreement to acquire Hugging Face for $12.93 billion, gaining a platform that already combines model distribution, inference-provider selection, routing, and centralized billing. Nvidia states that Hugging Face will remain open to different models, frameworks, clouds, inference providers, and compute platforms, without requiring Nvidia capacity — a position within the open-model ecosystem without formally tying it to its own hardware. This is not an isolated move: Nvidia has been an investor in Thinking Machines since 2025 and, since March, the company’s gigawatt-scale compute partner; Thinking Machines’ Tinker platform monetizes the post-training of open-weight models on customers’ proprietary data, and according to The Information, Nvidia is also in talks to join the new funding round. The strategy gives Nvidia benefits both from the compute demand of frontier labs and hyperscalers and from the spread of open-weight models, private cloud, and local deployment, diversifying a customer base concentrated among a relatively small number of frontier labs and hyperscalers, some of which — including OpenAI and Anthropic — are beginning to develop proprietary silicon.
What all this asks of the engineered enterprise
The instability of supply makes deliberate bundling central. Maximum unbundling shifts the cost of coordination onto the enterprise. Integration has value, especially for smaller companies that may prefer a provider able to absorb integration and operational complexity. What matters is knowing which decisions are bundled, who controls them, and which option is being given up. A practical test is checking whether changing model requires renegotiating data-use rights, redoing post-training, or restarting work in progress.
Orchestration operates at a different level from routing. Routing chooses the engine. Orchestration executes the work. State management determines what passes between calls. Orchestration sequences tasks, tools and systems, retries, handoffs, and human intervention. State management belongs to workflow architecture; it is not a seventh supply-side decision.
Elements of this design are already visible. At the INSEAD AI Forum Europe, Nicolai Tangen described Norges Bank Investment Management as a combination of a small central AI team, distributed use, and open-source backup models; Hyunjin Kim framed implementation through the production function. Devigili and colleagues similarly find selective shifts in demand for organizational skills as exposure to GenAI increases.
Figure 2. Who serves, who learns. Corporate policies constrain what the workflow can use and disclose; orchestration executes the work across models, tools, systems, and people; state management carries continuity; routing selects the approved backends. The information and meta-information generated during operation can emerge throughout the workflow, while observation, retention, portability, and use depend on architecture, contract, and law. Source: Marcello Vena, 2026.
The engineered enterprise is not designed for one particular supply ecosystem. It is designed, with strategic intent, to adapt as external conditions change, abstracting away the complexity of its external supply architecture for the people and workflows that do not need to manage it directly.
Modularity — the ability to change components without rebuilding the entire system — takes on a sharper strategic purpose here. Strategically useful modularity depends on granularity: the architecture must separate decisions at the level at which the enterprise may need to change them. Replacing a model while remaining locked into control over adapted weights, post-training, inference, routing, or information rights is only apparent modularity. Strategic flexibility requires that those control points can be recombined separately, allowing the enterprise to revisit what it integrates or retains as conditions change, without giving up what makes it distinct.
The value of information depends on architecture
The ability to reconfigure matters for another reason too: the information the enterprise retains has no value independent of architecture. Today’s LLM-centered systems place great value on text, code, preference signals, and corrections. Other trajectories emphasize state, action, trajectories, physical interaction, and simulation. At the INSEAD AI Forum Europe, Yann LeCun presented world models as a distinct path toward systems that represent and predict consequences in ways different from today’s LLMs.
An information stock can therefore remain accurate, proprietary, and legally usable, yet become less — or more — valuable if the architecture able to exploit it changes. The same applies to the knowledge the enterprise accumulates about its providers: evaluations, routing rules, and error profiles can become obsolete even faster when providers change models or interfaces.
We are still in the first instants after the “Big Bang” of transformer-based LLMs. Strategy cannot be a one-off exercise of mapping today’s supply ecosystem and rigidly building the enterprise around it. The enterprise must preserve the ability to change models, serving modes, routers, workflows, and data-use choices whenever there is a reason to do so — whether the supply ecosystem keeps changing rapidly or eventually settles down.
Marcello Vena – Chief Strategy and Growth Officer @ Datrix Group
