AI Infrastructure: The Tradeoffs Behind These 12 Vendor Platforms

I have spent the past several months building frameworks that help enterprises adopt AI. The work has two layers.

The first is the Decision Authority Placement Model — DAPM. It identifies drift in decision-making and authority. We have seen it repeatedly: automated systems begin to quietly overtake operational authority without explicit authority being granted. DAPM gives organizations a way to see that drift before it becomes structural.

The second is a domain-specific application of the theory: the 4+1 AI Infrastructure Framework. It maps the AI stack into eight layers that matter to enterprise architecture — compute and network fabric, data storage and governance, context and retrieval, data movement, orchestration, runtime execution, the reasoning plane, and the application layer — and applies DAPM at every layer. I recognized the infrastructure pattern before I recognized the general theory. The 4+1 model came first. DAPM emerged from asking why the same authority questions kept appearing across every vendor assessment.

Today I am publishing the instrument that ties them together: layer2c.com — an independent, public assessment of 12 AI infrastructure vendors that shows how enterprises cede, delegate, or retain authority to platform providers when adopting their technology stack.

The problem

Companies are struggling to identify value from AI. The models are good enough. The GPUs and software are good enough. The problem is not the technology.

My anecdotal experience is a reasonable proxy for what is possible. I have built a seven-figure run rate with just me, my wife, and a few thousand dollars a month in AI spend. I have used patterns I have seen across my 28-year career to capitalize on AI as a co-thinker. Over the past year I have built the following:

• Virtual CTO Advisor
• AI Stackbuilder
• 4+1 AI Infrastructure Framework + RFP
• AI Factory Economic Model
• Decision Authority Placement Model
• The Fourth Cloud Readiness Assessment
• Layer2C.com
• Analyzed 15 years of Tech Field Day content
• Produced several whitepapers, an ebook, and video content

Pre-AI, you could pick any two of those projects, and I would have been happy to accomplish both in the same year. Conservatively, I produced two years of output in less than one. I no longer have the skill to develop code, yet I built three platforms running in the public cloud — another low-level skill I no longer claim.

The productivity gains are real. But as I like to say: scale breaks everything.

I got into a fascinating debate with Jon Stevens, founder of NeoCloud Hot Aisle. Jon’s claim is that in a few short years, AI will displace storage software complexity, and companies like Dell will only sell NFS mounts that scale to petabytes. His evidence is a peer who manages 20PB of storage with a collection of scripts.

The logic is the same as my productivity hack. It is easy for small teams to realize productivity gains from automation and AI. The challenge comes when you try to scale it across distributed teams.

Can I use AI to create a block-level replication scheme? Yes. Can I create a data pipeline that auto-populates a vector store? Sure. Can I operationalize it to manage 20PB of data? Maybe. Can I have a team of 30 across four sites support it through a generation or two of employee turnover? Highly unlikely.

This is the repeated pattern for automation and AI projects. It is relatively easy for born-in-AI companies and small teams to realize the productivity gains. But scale breaks everything.

As a small business, I can identify the gap, perform rapid triage, select a solution, implement the technology, monitor for drift, and iterate — all inside my own head. Large enterprises are much more complex. They need systems for scaling the selection, management of technology, and controlling drift.

Enter Layer 2C

Layer 2C is the reasoning plane — the layer where policy, placement, escalation, evidence, and decision authority become explicit. It is where AI infrastructure stops being a collection of independently managed capabilities and starts becoming a governed operating model.

That layer is where most vendor stories break down. Not because the technology is weak, but because the question changes. It is no longer “Can the system run the workload?” It is “Who determines what the system is allowed to do, how it reasons, where it executes, and how that decision is inspected?”

That is the question layer2c.com is built to answer — vendor by vendor, layer by layer.

Capability is not authority

The simplest way to describe what the site does is this: capability coverage and authority placement are not the same thing.

A vendor may have broad coverage across the AI stack and still require the enterprise to place significant decision authority inside that vendor’s control boundary. Another vendor may preserve more enterprise control but leave gaps in higher-level orchestration, runtime, or reasoning-plane capability. Neither answer is automatically good or bad. They describe different control bargains.

DAPM classifies where that authority sits, using four positions:

Retained means the enterprise preserves a decision surface that can survive vendor substitution. The organization may have to rebuild implementation details, but it does not have to re-decide the architecture.

Delegated means a substitutable partner provides the capability. The enterprise depends on someone else for implementation, but its architectural requirements can survive a partner change.

Ceded means the enterprise has expressed its architecture in vendor-native constructs that do not easily survive a platform move. Substitution requires architectural re-decision, not just operational rebuilding.

Absent means the capability is not meaningfully present at that layer. Note: This is not canonical for DAPM. It’s added for this context. 

A ceded capability can be excellent. A retained capability can be immature. Delegation can be smart. Absence can be intentional. DAPM is not a quality score. It is a way to describe where authority lives and what the enterprise would have to re-decide if the platform changed.

What the site does

Layer2C publishes vendor assessments against the 4+1 Layer AI Infrastructure Model. Each assessment includes a layer-by-layer view, component-level notes, gap analysis, borrowed-judgment commentary, and a DAPM authority profile.

Twelve vendors are live today: Dell, HPE, AWS, VAST, Google Cloud, VMware by Broadcom, Microsoft Azure, NVIDIA, IBM/Red Hat, Oracle Cloud, Palantir, and Cisco. They span infrastructure OEMs, hyperscalers, data platforms, virtualization layers, component providers, open-source platform plays, networking and security vendors, and application-layer platforms that build downward from the decision rather than upward from silicon. 

What the assessments found

The framework produced findings that no single vendor’s assessment would reveal on its own. These are initial findings from the first assessment set — vendor stacks evolve, and assessments will update as capabilities ship. But a few patterns are worth naming here, because they demonstrate what the instrument is designed to surface.

Layer 2C is the defining gap — and the defining differentiator. Dell is absent at the reasoning plane. VMware is absent. NVIDIA does not build it. HPE is the only on-prem vendor with a productized Layer 2C — GreenLake Intelligence for IT operations, Kamiwaza via Unleash AI for AI workloads — and that two-part story is structurally unique. VAST has the most ambitious Layer 2C architecture, a closed governance-and-learning loop across PolicyEngine, Polaris, and TuningEngine, but much of it ships later this year.

The cloud and platform vendors are approaching the reasoning plane from different directions. Google Cloud has the most complete productized Intelligence 2C. IBM makes the most explicit 2C claim — watsonx.governance and InstructLab are 100% IBM IP at a layer where every other IBM component is commodity Kubernetes. Microsoft is building 2C as an identity story through Entra Agent ID and the Agent Governance Toolkit. Oracle’s engineering team has published the most sophisticated thinking on 2C from any hyperscaler, but the gap between their published architecture and their shipped product is real.

Every vendor’s Layer 2C story is different. That is the point. The reasoning plane is where vendor strategies actually diverge, and the assessments make that divergence legible.

The NVIDIA dependency extends further than most enterprises realize. Every on-prem vendor depends on NVIDIA GPU silicon at Layer 0. That is expected. What the assessments make visible is how far that dependency reaches into the upper layers. At Layer 2A, NVIDIA provides GPU Operator, Run:ai, and scheduling primitives. At Layer 2B, NVIDIA provides NIM, NeMo, and inference frameworks. The enterprise choosing a Dell or HPE AI Factory is simultaneously choosing a significant portion of NVIDIA’s software stack. The NVIDIA dependency column in each assessment tracks this layer by layer.

The Dell-Palantir inversion is structurally complete. Dell owns Layer 0 and is absent at Layer 2C. Palantir is absent at Layer 0 and strongest at Layer 2C. Dell says “bring any Layer 2C” — and that Layer 2C arrives Delegated, substitutable, with authority distributed across partners. Palantir says “bring any Layer 0” — and everything above the floor consolidates into one Ceded-and-operated authority. Same invitation, opposite consequence. Their heat maps are literal inverses of each other, and the implications for how the enterprise’s control plane gets assembled are opposite as well.

Cloud vendors concentrate authority, not just capability. AWS, Google Cloud, Azure, and Oracle all provide strong or moderate capability at nearly every layer. The DAPM classifications tell the real story: the enterprise consuming these platforms cedes authority across the stack. That is often exactly why enterprises choose cloud platforms: operational leverage in exchange for governance concentration. But it is a trade-off the enterprise should make explicitly, not inherit by default.

These are not the only findings. Each assessment contains layer-level analysis that is specific to the vendor and its competitive position. But these four patterns illustrate what the instrument is designed to do: surface the structural reality underneath the capability story.

How to use the site

If you are evaluating or already running one of these vendor platforms, start with that vendor’s assessment. Read the summary finding for the structural thesis. Open Layer 2C to see the reasoning plane story. Check the DAPM classifications at the layers that matter most to your deployment — for most enterprises, that means Layers 1A (data governance), 2A (orchestration), and 2B (runtime). The borrowed judgment assessment at each layer tells you where your vendor depends on partners for decision-making authority that you will inherit.

If you are a vendor, start with your own assessment and read it as your enterprise buyers will. The gap analysis and borrowed judgment sections surface the questions that serious architects ask after the demo — where the platform preserves customer authority, where it depends on a partner’s roadmap, and where enterprise opinions get embedded in constructs that do not survive a platform change.

Then look at a second vendor. The framework is the same across all twelve, so the comparisons are structural. The cross-vendor comparison view aggregates the layer status and DAPM heat maps side by side.

What this is not

Layer2C is not a procurement recommendation engine. It will not tell a buyer to choose Dell over HPE, Google Cloud over Azure, VMware over AWS, or NVIDIA over the rest of the ecosystem. The right answer depends on the existing estate, the operating team, data gravity, application strategy, compliance posture, and how much authority the organization is willing to place inside a vendor’s control boundary.

Layer2C is also not a lab validation. It does not replace benchmarks, reference calls, proof-of-concepts, or hands-on technical evaluation.

It is decision intelligence. It gives buyers and vendors a structured way to ask better questions before the conversation collapses into feature comparison, roadmap promises, and partner-logo slides.

Why this matters

For vendors, the uncomfortable part of Layer2C is that it does not simply ask whether the product is good. It asks whether the story holds together as enterprise architecture. Where does the platform preserve customer authority? Where does it depend on a partner’s roadmap? Where is the reasoning plane explicit, and where is it implied?

These are the questions serious enterprise buyers eventually ask, even when they do not use this language. They may not say “Layer 2C.” They may not say “DAPM.” But they are asking whether the platform will support the operating model they have to run after the demo ends.

For buyers, Layer2C is a way to slow down the AI infrastructure conversation long enough to see what you are actually buying. The risk is not ceded authority — enterprises cede authority all the time. The risk is accidental ceded authority: signing up for a platform assumption without understanding which parts of the architecture you control, which parts you delegate, and which parts you have placed inside someone else’s roadmap.

If the buyer understands the bargain, it is architecture. If the buyer discovers it later during audit, migration, incident response, cost control, or governance review, it becomes technical debt.

Scale breaks everything. Layer2C is my attempt to show you where it breaks first.

You can explore the research at layer2c.com.