The Model Is the Engine. The Race Is Won in the Pit.

On 25 May 2026, the Dutch government blocked Kyndryl’s proposed acquisition of Solvinity. The Investment Screening Bureau published the decision the following day. Solvinity supplies infrastructure connected to DigiD, the Netherlands’ national digital identity system. The official notice named the parties, said the transaction could threaten the public interest, and described the prohibition as final and legally binding.

The decision was about a cloud company, a foreign buyer, and a critical national dependency. It also captured the central fact of the current AI buildout. Capability can be rented. Dependency accumulates underneath it.

Most enterprise discussion still begins with the model. Which model is smartest. Which benchmark moved. Which licence is safest. Which provider is cheapest this quarter. Those questions matter, but they cover one layer of a much larger system.

For this analysis, the AI infrastructure stack has ten layers:

• Compute and energy: Physical capacity sets the ceiling on what can be trained, served and afforded.
• Foundation models: The model supplies general capability, but also creates a central technical and commercial dependency.
• Memory and context: This layer decides what the system can retrieve, retain and carry between interactions.
• Orchestration: It turns model outputs into workflows, tool calls and multi-step action.
• Protocols: Shared interfaces determine whether components can connect without one vendor owning every seam.
• Identity and trust: The system needs to know which actor is present, whom it represents and what authority it holds.
• Governance and audit: Explicit policy and evidence make consequential actions reviewable and enforceable.
• Observability: Operators need to see cost, latency, failure, drift and action paths while the system is running.
• AI financial operations: Metering and allocation reveal who pays for intelligence and where its economics break.
• Domain integration: Capability produces value only when it fits real data, systems, responsibilities and work.

This is my map, not an external standard. It separates supply-chain layers that enterprises buy and operate, while keeping identity, runtime authority and evidence visible instead of hiding them inside security or orchestration. Alternative maps combine some of these categories or add data and developer tooling as separate layers. Ten is useful here because each row can carry a distinct owner, dependency, exit condition and evidence requirement. I return to each layer later in the article.

The internet is a useful clock for this buildout because it did not arrive as one finished architecture. Networks, protocols, browsers, cloud platforms, identity and payment rails accumulated in layers, and control shifted as each layer matured. AI capability is moving faster, but data centres, procurement, regulation and enterprise migration still move on physical and institutional clocks. Model leadership can change in months. Enterprise architecture changes over years. Infrastructure power can take longer to settle.

This is a map of those layers, the evidence behind their current state, and the consequences for dependency and reversibility. It is current to 27 September 2026. Where the evidence is incomplete, the uncertainty stays visible.

A product became an operating system

The modern stack formed in a compressed sequence. The transformer paper appeared in June 2017. Large language models then made general-purpose language interfaces commercially useful. Chat systems gave millions of people a direct way to use them. Tool calling connected those models to software. Retrieval systems gave them access to private context. Agent runtimes added plans, memory, and loops.

Each step solved one visible problem and exposed quieter ones. Tool use brought identity and authority into the design. Planning created budget questions. Memory required retention rules. External side effects made recovery and audit evidence part of the system rather than operational polish.

The industry built much of this in reverse order. Models arrived first because capability was legible. The control system followed because production forced it to.

The pattern is familiar from earlier computing cycles. A new capability appears as a product. Adoption reveals that the product needs protocols, identity, operations, security, and governance. Those surrounding layers look secondary until a failure reaches money, data, or a person. Then they become the system.

AI has moved through that cycle unusually quickly. The speed creates an illusion of maturity. A polished interface can sit on top of a stack whose identity, failure semantics, and evidence model are still improvised.

Capability outran reliability

Capability kept improving. Reliability improved more slowly and unevenly.

In Towards a Science of AI Agent Reliability, researchers evaluated 15 models on two agent benchmarks. They examined consistency, robustness, predictability, and a narrowly defined form of operational safety across model releases. Reliability gains were moderate on a structured customer-service benchmark and barely present on the more open-ended GAIA benchmark. Outcome consistency remained low, prompt rephrasing still caused failures, and models did not reliably distinguish when they were likely to be wrong.

That paper does not prove that scaling has stopped working. It does not cover adversarial attacks, value alignment, or the full social risk of deployment. It shows something narrower and more useful: higher task accuracy does not automatically produce a dependable operating system.

The distinction changes architecture. If a model can produce a better answer but still behave inconsistently across equivalent prompts, the surrounding system has to absorb that variance. Inputs and tool permissions need explicit structure. A repeated request must not accidentally repeat an external side effect. Recovery rules and decision evidence have to survive the model session.

The model remains the engine. More of the race is now decided by everything around it.

What are the ten layers of the AI infrastructure stack?

This map follows an operating AI system from electricity to the application that changes a business process. It is a way to examine dependencies, not a claim that every architecture must use these ten categories.

This is an infrastructure taxonomy, not a maturity score. A company can be advanced in orchestration and weak in identity. It can run a capable model with no defensible evidence trail. It can operate every layer and still have no useful product.

The Solvinity decision gives the table a consequence. Once infrastructure is connected to a national identity service, a change of ownership is no longer a generic vendor event. The dependency reaches public access, institutional authority and the state’s ability to intervene.

The state labels in the table are provisional author assessments, not rankings or measured market shares. Other public maps combine security, identity, governance, and observability, while some separate data and developer tooling. This version keeps identity and governance visible because they create distinct ownership and evidence questions. A reproducible public census that consistently groups the field differently would be a reason to revise it.

Capital concentrates at the foundation

My current assessment is that compute, frontier-model development, and large-scale distribution are the most concentrated parts of the stack. The comparison is structural rather than a market-share ranking: it looks at capital requirements, supplier substitutability, and whether credible alternatives exist. A dated ownership census or a material increase in viable suppliers would change that assessment.

Compute begins with a small set of semiconductor and equipment firms, then narrows again through hyperscale infrastructure and access to energy. The capital requirement is enormous. A single adopter cannot change that structure. Application architecture can still limit how much of the resulting dependency becomes irreversible.

Foundation models have more visible contenders, including open-weight alternatives, but frontier training remains expensive and organisationally concentrated. The practical enterprise market is broader because a workload often does not require the frontier. Smaller models, specialised models, and local execution can be enough. That creates bargaining room without dissolving concentration at the top.

The distinction matters for dependency analysis. A firm can use a frontier model while keeping the application interface, substitution measurements, and data contracts separate from that provider. How much leverage this preserves depends on the workload and the cost of migration.

Concentration is not automatically a defect. It often buys reliability, distribution, and operational scale. It becomes a strategic problem when an organisation cannot identify the dependency, cannot price an exit, or cannot reconstruct what happened without the provider.

Identity, governance, and evidence

An agent can act only when a system can answer four questions: who is acting, for whom, under what authority, and with what record.

Human identity systems were designed around people, service accounts, and applications. Agents blur those categories. An agent may be instantiated for one task, delegate to another agent, call several tools, and operate with authority derived from a human, a role, a policy, or all three. A conventional API key proves possession of a credential. It does not explain the chain of authority behind a particular action.

Governance covers several different jobs. ISO/IEC 42001 is a management-system standard. The EU AI Act creates legal obligations. Deployment reviews decide whether a system is eligible to operate. Action-level runtime controls evaluate a specific proposed action at the moment of execution. Technical evidence records what each control saw and did. These layers should connect, and none substitutes for the others.

The public open-source 5D project I maintain is one small example in the runtime-policy layer, alongside commercial platforms and public frameworks working at other levels. The deeper argument for action-level controls belongs in the related runtime-governance pieces. Here the architectural point is narrower: identity, authority, policy, and evidence need portable interfaces because every connected tool inherits them.

Open protocols create a seam

MCP and A2A reduce the cost of connecting systems, but they do not supply the missing authority model by themselves.

The Model Context Protocol standardises how an AI application discovers and calls tools and data sources. Agent2Agent addresses communication between agents. MCP moved into the Linux Foundation’s Agentic AI Foundation in December 2025. A2A joined the same foundation in August 2026. The coordination matters because it shifts protocol stewardship away from a single originating company.

Open protocols can widen a market while concentrating implementation elsewhere. HTTP did not prevent cloud concentration. A common agent protocol will not prevent one identity provider, gateway, or marketplace from becoming dominant. It gives the market a shared seam where alternatives can connect.

That seam needs policy. A tool description says what can be called. It does not establish whether this agent may call it for this purpose, with this data, at this cost, on behalf of this principal. Protocol adoption makes the authority problem more visible because it makes connection easier.

Europe’s leverage and dependency

Europe has regulatory leverage and a visible set of technical firms. The available evidence does not support a precise claim about its ownership share across the full stack.

Available public directories show a large and fast-changing AI-security category, but they do not provide a stable, independently maintained ownership census. This article therefore makes no comparative claim about the American, Israeli, or European share of the market. A public dataset with disclosed inclusion rules, dates, denominators, and source trails could support one later.

The Dutch Solvinity decision shows a second form of European leverage. A state can block a transaction when a dependency reaches critical infrastructure. That is a defensive instrument. It does not create an alternative supplier, fund a later-stage company, or make migration cheap.

The unresolved question sits in identity, governance, and evidence. Europe is writing consequential AI obligations while many of the infrastructure options used to implement them are supplied across jurisdictions. The degree of dependency varies by layer and is not measured here. Regulation can create demand for local governance capability. It cannot guarantee that the resulting firms remain locally financed, scaled, or owned.

Dependency becomes visible through three facts: which components cross a jurisdiction, what replacement would require, and which records remain available when a supplier changes. Those are properties of the deployed architecture, not of a sovereignty slogan.

Regulatory schedules should not be hard-coded into the architecture

AI obligations differ by jurisdiction, system class, role and transition rule. Those details change, so a useful architecture plan should retrieve them from current approved policy rather than encode one publication-date summary as permanent logic.

The architecture consequence is more durable than the calendar. Systems need an inventory, risk classification, accountable ownership, technical documentation, monitoring, and evidence that can be updated when a legal schedule changes. A hard-coded compliance workflow ages badly. A versioned policy and evidence model can absorb a changed date without rewriting the operating system.

This article is not legal advice. Teams should verify applicable dates and exceptions against the current official text for their role and use case.

The cost structure sits around the model

The model is only one cost centre in the operating system around it.

Integration connects models to data, tools, identity, orchestration, and business systems. Its cost rises with the number of exceptions, not the number of demos. Operation remains after the prototype works: evaluation, monitoring, incident response, retry control, and human review. A workflow that costs cents in model tokens can cost much more when a person has to resolve ambiguous cases.

Evidence has a cost because regulated organisations may need to reconstruct decisions. That record can include the applicable policy, approval, data boundary, execution outcome, and retention rule. Exit has a cost too. Prompts, tools, identity mappings, evaluation sets, and data contracts all influence it. A substitution test supplies stronger evidence of portability than an architecture diagram, though it cannot predict every migration condition.

These are properties of the same architecture rather than four automatic programmes. Their cost should be compared with the operational exceptions and migration risks they are meant to reduce; this draft does not claim a universal saving.

Reversibility is an architecture property

For many workloads, model choice, orchestration, observability, and retrieval storage can be designed for substitution. That does not mean swapping providers weekly. It means preserving the interface and evidence needed to assess a change when economics, regulation, or capability shifts.

Identity, data boundaries, evidence formats and domain workflows accumulate different forms of coupling. The practical test is whether the organisation can still identify who may act, where data has spread, what record survives a supplier change and which business behaviour would have to be rebuilt.

A reversible design leaves four records: the current choice, the interface around it, the evidence needed for replacement, and the condition that would trigger a move. A missing record does not prove lock-in, but it weakens the claim that the layer is portable.

What is already decided, and what remains open?

Three things look durable.

My expectation is that enterprises will use more than one model class because price, latency, privacy, and task shape pull workloads in different directions. A broadly capable model that wins simultaneously on cost, latency, privacy, and task quality would falsify that expectation.

Second, agents will need explicit identity, authority, and evidence. The implementation can change. The need appears whenever software acts on external state.

Third, common protocols should reduce connection work when tools and agents share interfaces, even if the market above them remains concentrated. If implementations fragment into incompatible extensions or concentrate behind one proprietary gateway, that value will be smaller than expected.

Much else is open. The durable orchestration layer is unsettled. Agent identity lacks a shared standard. Runtime governance spans frameworks that solve different parts of the problem. Observability and evidence are still too often treated as synonyms. European regulation has created demand without securing European ownership of the infrastructure that answers it.

What would change this assessment? Reliability improving at the same pace as capability would reduce the burden on the surrounding control system. A portable identity and authority standard with broad production adoption would settle a major layer. A genuinely open evidence format adopted across platforms would reduce exit cost. European growth capital and acquisitions retaining more infrastructure firms would weaken the ownership concern.

Until then, selective commitment is the working hypothesis: differentiation sits in the domain workflow, while the surrounding infrastructure benefits from observable and versioned boundaries. The hypothesis fails where a tightly integrated platform delivers enough operational value to outweigh its exit cost.

A stack decision is more legible when the dependency, replacement evidence and change condition are explicit. The Dutch intervention shows why that matters: once a dependency reaches national identity infrastructure, fewer easy choices remain.

Method note

This draft uses the author’s ten-layer infrastructure map and primary-source checks current to 2 October 2026. Official sources support the Dutch decision; a research paper supports the reliability section; first-party announcements support the protocol and agent-identity examples. Regulatory schedules are intentionally left to current official text rather than restated as fixed dates. Table states and forward statements are visibly author assessments with stated change conditions. Claims requiring an unpublished market review were removed. The piece marks the author’s public open-source project at its single point of reference and uses no private Suite, employer, or commercial material.

Proposed related reading

• Runtime Is the Moment of Consequence

Core sources

• Dutch Investment Screening Bureau, definitive prohibitions under the Telecommunications Act, 26 May 2026
• Rabanser et al., Towards a Science of AI Agent Reliability, arXiv:2602.16666
• EUR-Lex, Regulation (EU) 2026/1744
• Linux Foundation, formation of the Agentic AI Foundation
• A2A project, joining the Agentic AI Foundation
• NIST AI Risk Management Framework
• ISO/IEC 42001:2023 overview