When a federal agency says they're "using OpenAI," they might mean they have a direct API contract with OpenAI the company. Or they might mean they're on Azure OpenAI Service, where Microsoft is the host, Microsoft holds the data residency commitments, and Microsoft is the entity in the contract — even though OpenAI trained the underlying model. These are different relationships with different security postures, different audit trails, and different procurement paths. Treating them as equivalent is the mistake that sends conversations sideways.
The AI supply chain has four distinct layers. What each one does, and what it specifically doesn't do, is the prerequisite for every other question in this section.
The Four Layers
Frontier labs train foundation models. This is the research and compute-intensive work of building model weights from scratch: assembling training data, running the compute, and producing the artifact that everything downstream depends on. OpenAI, Anthropic, Google DeepMind, Meta AI, and Mistral sit in this layer. Their core product is the model itself. Most of them also operate direct API access, which is where the conflation begins: a lab that trains a model and also sells API access to it looks, from the outside, like a single entity. It isn't, functionally. The training organization and the serving infrastructure carry different risk profiles. The single brand obscures that.
Hyperscalers host and serve models at scale. Azure, AWS, and Google Cloud are the canonical examples, but the function is distinct from the frontier lab function: hyperscalers provide the infrastructure, the API endpoints, the compliance certifications, the data residency controls, and the enterprise contracts. Azure OpenAI Service runs OpenAI's models on Microsoft's infrastructure under Microsoft's terms. AWS Bedrock runs models from Anthropic, Meta, Mistral, and others under Amazon's terms. The hyperscaler is the entity that signs your BAA, appears in your FedRAMP documentation, and answers your incident response call at 2 a.m. The frontier lab usually doesn't.
Aggregators sit between hyperscalers and enterprise applications. This layer is still forming, and the players range from model routing platforms to AI gateway products to inference optimization services. Their function is abstraction: they let an application call "a model" without being hardwired to a specific provider, they add observability and rate limiting and sometimes fine-tuning, and they manage the complexity of a world where the best model for a given task might shift quarterly. Some aggregators are independent companies; some are features inside larger platforms. The category doesn't have clean edges yet, which is worth naming rather than papering over.
The enterprise layer is where buyers actually live. This is the application, the workflow, the integration — the thing that touches users and gets something done. A procurement officer using an AI-assisted contract review tool is at the enterprise layer. The tool might call an aggregator, which routes to a hyperscaler, which serves a model the frontier lab trained. Four hops. One user. One conversation with your AE.
Why This Matters Now
Buyers are showing up to conversations with AI requirements that are actually questions about different layers of this stack, asked as if they're all the same question. "Is this FedRAMP authorized?" is a hyperscaler question. "Is this model trained on our data?" is a frontier lab question, mostly. "Can we swap models without rewriting our integration?" is an aggregator question. "Who owns the output?" is an enterprise layer question with legal implications that nobody has fully resolved.
The conflation isn't the buyer's fault. The marketing layer of the AI industry has worked hard to make the stack invisible. When a hyperscaler brands its AI offering with the frontier lab's name, and the frontier lab's name is synonymous with the product category, the layers collapse in the buyer's mental model. Your job in these conversations is to make the stack visible again. Ask the question that separates the layers: "When you say you're using [lab name], are you going through [hyperscaler] or direct?"
That one question usually produces a pause, followed by a more productive conversation.
What This Section Covers
The subsequent lessons work through each layer in detail. Lessons 1 and 3 profile the major vendors at the frontier lab and hyperscaler layers. Lesson 2 covers open-weight models and what "open" actually means in licensing terms, a question that matters more in federal accounts than anywhere else. Lesson 4 is pricing structures, which vary enough across layers that a single mental model won't hold. Lesson 5 covers capability tiers. Lesson 6 addresses the geopolitical dimension, which is increasingly a procurement factor in federal accounts. Lesson 7 covers the aggregator and enterprise layers, where the market is moving fastest and the vendor landscape is least settled.
Each lesson assumes you have this map. Without it, the details don't have anywhere to land.
IDAM Bridge — In identity, the directory stores identity data, the IdP issues assertions about it, and the service provider consumes those assertions. Three layers, three distinct trust relationships, three separate contracts. The closest AI equivalent: the frontier lab produces the model (the source of truth), the hyperscaler serves it and issues the API response, and the enterprise application consumes it. It diverges here: in IDAM, standards like SAML and OIDC formalize what each layer can claim about the others — a signed assertion from a trusted IdP carries specific, auditable meaning. In AI, no equivalent standard exists. The hyperscaler can make claims about model provenance, safety, and capability that the frontier lab never formally attested to, and there's no mechanism yet for verifying those claims at the protocol level. You're trusting the chain. You're not verifying it.