Writing · August 21, 2026 · 12 min read
The Map of AI
Most maps begin with the model. This one follows a common cloud AI request from the grid to the application on screen.
The model is the middle
Most AI diagrams start with the model. I think they start too late.
They show a neat box for the model, then another for the application. That leaves out most of the system that makes the answer possible: electricity, chips, buildings, serving infrastructure, gateways, permissions, tools, and the product a person actually trusts with a task.
This map follows one common cloud AI request across eight layers. Other AI systems take other paths. A local model can skip the cloud, a direct API call can skip a gateway, and one company can combine several layers behind a single endpoint.
I use one request throughout the essay: ask a coding assistant to migrate a repository from the Next.js Pages Router to the App Router. The visible action is one sentence and a press of Enter. Underneath, the request can cross years of infrastructure decisions and milliseconds of software decisions.
The lower half of the map is a supply chain that exists before the request. Power is connected, accelerators are fabricated, a data center is built, and a training run produces weights. The live request begins in an application, passes through an agent runtime and perhaps a gateway, reaches an inference server, and returns as tokens and tool calls.
I care about the distinction because control moves differently at each layer. A grid queue limits capacity years ahead. A router can change the model for this request. A permission check can stop one file edit. Calling all three AI infrastructure hides more than it explains.
The stack at a glance
I sized the bands by editorial emphasis; market share is outside the scope of this map.
Company labels loading.every name opens its official site ↗
Before and after you press Enter
The first five stops exist before your request: power, chips, a data center, a training run, and model weights. The live path then runs from the application through its agent runtime, perhaps through a gateway, and into an inference server. Scroll to follow each handoff.
- L1 · Energy & gridPJM Interconnection · GE Vernova · Constellation Energy
- L2 · Chips & fabsTSMC · Nvidia · ASML
- L3 · Data centersAWS · CoreWeave · Azure
- The training runthe run that produces trained weights
- L4 · ModelsOpenAI · Anthropic · DeepMind
- L8 · ApplicationsChatGPT · Cursor · Perplexity
- L7 · Agent runtimes and permissionsMCP · Agents SDK · Agent Framework · AgentCore · ADK · A2A · Nvidia · LangGraph · Braintrust · Mozilla.ai
- L6 · Routing and gatewaysOpenRouter · LiteLLM
- L5 · Inference and servingTogether · Fireworks · Groq
L1 · Energy and grid
The path starts before there is a prompt. Data centers need power that is available at the right site, at the right voltage, on a schedule the project can survive. Generation, transmission, interconnection, transformers, and switchgear each run on a different clock.
Berkeley Lab's reference case projects U.S. data centers using 649 terawatt-hours of electricity in 2030, or 11.8 percent of national electricity use. Its sensitivity cases span 9.5 to 15.3 percent. That range matters more than a single dramatic headline because demand, efficiency, and buildout remain uncertain.1Lawrence Berkeley National Laboratory, United States Data Center Energy Usage Report: 2025 Update, published June 2026. The 649 TWh figure is one reference case among several scenarios.
PJM's 2028/2029 capacity auction cleared $16.4 billion, with every price at the $325 cap, and still procured 6,831.3 megawatts less unforced capacity than its reliability requirement. Money cleared the market; it did not create missing capacity on demand.
The bottleneck continues after generation. Hitachi announced more than $1 billion of U.S. plant expansion in 2025, including $457 million for transformer production in Virginia. A finished compute hall can still wait for the heavy equipment that connects it to the grid.
Our repository migration will consume a trivial sliver of this system. The capacity still had to exist before the request arrived. At this layer, control means deciding whether another block of compute can be powered at all.
L2 · Chips and fabs
Electricity becomes useful AI compute through accelerators, memory, packaging, and the network between them. The accelerator gets the famous logo. A training cluster also depends on high-bandwidth memory feeding it fast enough and on links that let thousands of devices work as one machine.
ASML is the sole commercial supplier of leading-edge extreme-ultraviolet lithography machines, while TSMC fabricates a large share of advanced AI accelerators and custom chips. That large share is concentrated enough to make fabrication and lithography strategic chokepoints without pretending either company touches every chip.
The company descriptions are revealing: Synopsys sells the design machinery, TSMC describes CoWoS as an integration layer, and Micron documents the memory hierarchy around accelerators. A chip label compresses design tools, wafers, memory, packaging, testing, and yield into one square.
The network is part of the computer. Nvidia presents co-packaged optics as an emerging response to the power and distance limits of electrical links. A slow fabric can strand expensive accelerators, so useful cluster capacity is smaller than the sum of the chips a buyer owns.
The coding request never chooses a fab. It inherits the hardware choices made by the service running it. At this layer, control is exercised through manufacturing capacity, software ecosystems, and the ability to make many devices behave like one computer.
L3 · Data centers
A rack of accelerators is still inventory. A data center turns it into an operated service by supplying power distribution, cooling, networking, storage, physical security, technicians, and enough redundancy to keep workloads alive when equipment fails.
The International Energy Agency describes grid queues and long connection waits as a critical constraint in many regions. The qualifier matters. Some projects are power-limited, others are constrained by land, cooling, equipment, capital, permits, network access, or customers.
This is also where announcements become slippery. Contracted power, a building under construction, an energized hall, installed accelerators, and available customer capacity are different states. A press release can move faster than concrete, substations, or commissioning.
U.S. evidence from Berkeley Lab and the World Resources Institute connects data center growth with electricity demand, cooling water, land, air quality, utility planning, and decisions about who pays for new infrastructure. A global gigawatt number cannot tell one community what a particular site will do to its grid or bill.
Our migration request lands on capacity scheduled by a cloud or specialist provider. The building does not understand JavaScript. It controls whether enough reliable compute and network capacity is available when the serving layer asks for it.
L4 · Models and training
Training converts compute, data, and engineering decisions into weights. Pretraining teaches broad statistical structure. Post-training, tool-use training, and evaluation shape how those weights behave in a product. The resulting model is a reusable artifact, while the cluster that produced it can move on to another run.
Independent estimates put the cloud-equivalent compute for some final frontier runs above $100 million. That narrow estimate excludes much of the experimentation, data work, people, and supporting systems around the final run. Few organizations can fund the full loop, though the field is larger than three labs.
OpenAI, Google DeepMind, Anthropic, Meta, SpaceXAI, Qwen, DeepSeek, Kimi, Z.ai, Mistral, Cohere, and other programs belong in the picture. They cannot be reduced to a single ranking. Closed APIs, open-weight releases, regional reach, private deployment, price, latency, and coding ability describe different contests.
Open weights and open source grant different rights. Access to parameters can make self-hosting practical, while the Open Source Initiative asks whether people may use, study, modify, and share the whole system. The license says more about what builders can do than the launch label does.
For the repository migration, the model supplies learned coding ability and generates candidate changes. It has no repository permissions yet, no durable task state, and no guarantee that its training matches the framework version in front of it. Those responsibilities belong higher on the map.
L5 · Inference and serving
Inference is the live execution layer. A serving system loads model weights onto accelerators, accepts requests, schedules them into batches, manages memory, and streams generated tokens back. Training creates the capability once; inference pays the compute bill each time somebody uses it.
Cloud platforms such as Azure, AWS, and Google Vertex serve models alongside specialists such as Together, Fireworks, Groq, and Nvidia NIM. They package hardware scheduling, deployment, scaling, monitoring, and APIs around the weights. The model name alone does not identify the service quality a user receives.
Batch size trades latency for throughput. A key-value cache keeps attention state from being recomputed for the whole conversation. Quantization can lower memory use and cost, with possible quality tradeoffs. Retrieval can add current repository files before generation; many inference calls work without it.
Serving quality has several dimensions. MLCommons measures throughput, interactivity, latency, and concurrency because one headline speed cannot represent them all. The fastest endpoint for one short prompt may be the wrong endpoint for a long coding task with tools and a large context window.
This layer turns the migration prompt, repository context, and prior tool results into the next token. Its control is immediate: queue the request, reject it, slow it down, place it on different hardware, or serve a different model version behind the same name.
L6 · Routing and gateways
A gateway sits between the application and one or more model endpoints. It can attach credentials, enforce budgets, log requests, retry failures, choose a region, or send different tasks to different models. Many systems call a provider directly and have no separate routing layer.
For the migration, a router might send planning to a strong reasoning model, repetitive edits to a cheaper model, and a failed request to a fallback. That flexibility also creates a control point: the gateway can change cost, latency, privacy exposure, and model behaviour without changing the interface the user sees.
OpenRouter, LiteLLM, Cloudflare AI Gateway, Vercel AI Gateway, and cloud routing products show the range of mechanisms. This product catalog does not measure how much traffic runs through them. A logo proves the product exists; adoption and architectural independence remain open questions.
Where should this task go?
A router compares capability, latency, price, availability, and policy for each task. The deciding factor changes with the work and with current conditions.
- Route A Low latency, text input, standard context.
- Route B Long context and stronger planning, with a higher call cost.
- Route C Image input, strict schemas, and approved customer-document handling.
Case 1 of 4
Pull action items from a non-confidential meeting transcript while the attendee waits.
Your call: which destination takes it?
The router’s choice
Routed to Route A · latency decides this case
Route A returns the list within the response-time budget and has enough extraction accuracy for a result the attendee can check against the transcript.
Under the hood (Under the hood: the factor this card leaves out)
Every case in this set
- Pull action items from a non-confidential meeting transcript while the attendee waits. Routed to Route A; latency decides this case. Route A returns the list within the response-time budget and has enough extraction accuracy for a result the attendee can check against the transcript. Under the hood: This prompt repeats often, so cache state can change first-token latency. A route switch may start with a cold cache.
- Draft a migration plan from a repository and incident notes for a service with sparse documentation. Routed to Route B; price decides this case. Route B costs more per call and produces a reviewable plan in one pass. This job runs once, and an engineer reads the result tomorrow, so repair time carries the most weight. Under the hood: The routing budget includes the engineer's review time. A thin plan can make a cheap call expensive to finish.
- Turn scanned customer invoices into a fixed JSON schema during an approved overnight batch. Routed to Route C; capability decides this case. Route C accepts images, supports the required schema, and is approved for customer documents. Those requirements determine the destination before the batch starts. Under the hood: Schema adapters and tokenizers vary across model families. The router must select the matching adapter with the destination.
- Summarise a customer document covered by a data-residency agreement. Routed to Route B; policy decides this case. The customer's contract names the allowed processing region. That clause narrows the pool first, and the router chooses among the approved destinations. Under the hood: Availability changes throughout the day. Region and contract filters apply before the router checks live capacity.
The routes and cases are fictional examples of the decision process.
L7 · Agent runtimes and permissions
An agent runtime turns model calls into work. It keeps task state, exposes tools, decides when to call them, validates results, handles retries, and stops the loop. The model proposes actions; the runtime decides which actions are possible in this environment.
MCP, OpenAI's Agents SDK, Microsoft's Agent Framework, AWS AgentCore, Google's ADK and A2A work, Nvidia's Agent Toolkit, LangGraph, and Braintrust cover different parts of this layer. Protocols, runtimes, state machines, deployment systems, and evaluation tools should not be collapsed into one interchangeable category.
The repository migration makes the boundary concrete. The runtime reads files, searches for old routes, runs tests, applies patches, and asks for approval before a risky command. It also limits the working directory and removes secrets from the model's reach. Those constraints matter more than whether the model can describe the edit in prose.
Persistent memory can help an agent resume a long task, and it also expands the attack surface. Stored instructions, retrieved files, and tool output can carry stale or hostile content. Identity, least privilege, audit trails, and explicit approval boundaries are part of the runtime, not optional polish.
L8 · Applications
The application is where the stack becomes a product. It owns the interface, user identity, conversation state, repository connection, tool approvals, error recovery, and the way model output is presented. Two products using the same model can feel like different systems because this layer chooses the workflow.
General assistants such as ChatGPT, Claude, Gemini, and Copilot sit beside specialist products such as Cursor and Perplexity. The specialist can win by shaping context, tools, and feedback around one kind of work even when another company supplies the underlying model.
In our example, the application shows the migration plan, the files being changed, the test output, and the approval prompt. It can preserve a diff the user can inspect or hide the whole operation behind a spinner. That design choice changes trust even if every lower layer stays identical.
Distribution belongs here too. A default assistant inside an operating system, browser, office suite, or developer environment starts closer to the user than a better model behind an unfamiliar signup. The last mile can decide which upstream stack receives the request.
Build a common cloud AI stack
Eight layers, shuffled. Arrange one common cloud AI stack from physical capacity to the application. Other systems combine layers or skip them. This is one useful architecture among several. Your order disappears when you leave, and you can reveal this map's answer whenever you want.
- Applications
- Models
- Chips & fabs
- Routing and gateways
- Data centers
- Agent runtimes and permissions
- Energy & grid
- Inference and serving
Show this map's order
- Energy & grid: a transistor switches nothing without electricity, and whether that electricity can be bought at all is settled years earlier, in interconnection queues and turbine order books.
- Chips & fabs: everything above it is a program, and a program has to run on a transistor somewhere.
- Data centers: a chip in a box does nothing until a building gives it power, cooling, and a network.
- Models: weights are what a long training run leaves behind, and that run is months of those buildings and that hardware.
- Inference and serving: weights sit inert until a serving system loads them and turns them back into tokens.
- Routing and gateways: routing begins once several models are available to receive a request.
- Agent runtimes and permissions: deciding what happens next presumes a model call you can already make.
- Applications: the application is where a person supplies the request, approves actions, and receives the result.
Capacity control and request control
The map contains two kinds of control that are easy to confuse. Capacity control determines what can exist: access to grid connections, fabrication, accelerators, buildings, capital, and trained weights. These decisions are slow, concentrated, and difficult to reverse.
Request control determines what happens now: which application receives the prompt, which tools and data it can reach, which gateway handles it, which model endpoint serves it, and what the user is allowed to approve. These decisions can change between two consecutive requests.
In the coding task, a chip supplier has enormous influence over available capacity and almost no direct say over whether this agent may edit package.json. The application and runtime have tight control over that one action and no ability to clear an interconnection queue. Asking who controls AI has no useful answer until the object and timescale are named.
Governance and shared systems
Governance sits across all eight steps. Law, procurement, standards, security, identity, data rights, and evaluation cut across the route. A rule can change which chips ship, what a model developer documents, how an agent authenticates, or what an application discloses.
The European Union's AI Act shows why dates and scope matter. General-purpose AI obligations began applying in August 2025, while broader provisions and enforcement milestones extend through August 2026 and beyond, with exceptions and transitions. One slogan cannot carry that timeline.
Open standards, open-source software, open-weight models, public research, and shared datasets are not synonyms. They grant different rights and create different governance. Shared infrastructure such as protocols and evaluation methods can influence several layers without becoming another box in the request path.
The migration request therefore crosses a second map laid over the first: licenses on the code and model, credentials for tools, organizational policy, security checks, evaluation, and a human approval boundary. These shared systems shape every handoff while remaining cross-cutting.
Where the map breaks
The eight layers describe one useful path. A laptop running an open-weight model collapses the cloud, gateway, and external serving path. A hyperscaler can own chips, data centers, models, serving, and the application. A robot adds sensors, control loops, batteries, and physical safety that this map barely touches.
Boundaries will keep moving. Gateways may become features inside application platforms. Agent runtimes may absorb more routing. Model providers may sell complete work environments. The point of naming layers is to inspect the handoffs while they matter, then redraw them when the architecture changes.
The model is the most visible object in AI. It may not be the most durable source of control. Power contracts last longer than model releases. Chip ecosystems outlive benchmarks. Agent permissions can matter more than raw intelligence. Distribution can outweigh a small quality lead.
If you want to understand where AI is going, do not stop at the model leaderboard. Follow the request. Find the bottlenecks. Separate the capacity decisions made years ago from the software decisions made in milliseconds. Then ask who controls each handoff, what can fail there, and how easily the user can leave.
Companies and projects shown on the map
The opening plate keeps only a few examples per layer. This directory preserves the complete reviewed field and each official destination.
Sources and reading notes
As of 2026-08-12 · newest first
Electricity and grid
- Berkeley Lab: U.S. Data Center Energy Usage Report · 2026-06 · independent report · U.S. electricity and water scenarios, not a universal forecast
- IEA: Electricity 2026, Grids · 2026 · intergovernmental analysis · grid queues and connection constraints
- CoreWeave 2025 Form 10-K · 2026-03-02 · company filing · contracts, financing, risks, and useful lives
Semiconductors
- TSMC: CoWoS advanced packaging · accessed 2026-08-12 · company documentation · logic and HBM integration; not comparative capacity evidence
- NIST: additional TSMC U.S. investment · 2026-07-16 · government announcement · planned U.S. investment raised to $265 billion
- Stanford HAI: AI Index Report 2026 · 2026 · independent report · estimates of AI compute and semiconductor concentration
Models and inference
- MLCommons: Endpoints benchmark · accessed 2026-08-12 · benchmark method · throughput, interactivity, latency, and concurrency
- Stratechery: Who's Afraid of Chinese Models? · 2026-07-20 · analysis · its COGS versus R&D section is the framing behind the serving-cost argument; subscriber content
- Artificial Analysis: Model leaderboard · accessed 2026-07-23 · independent benchmark snapshot · dated capability comparison; English text-only weighting, not adoption
- Hugging Face: State of Open Source on the Hub, Spring 2026 · Spring 2026 · platform analysis · open-model distribution and ecosystem activity, not active users
- Narayanan and Kapur: Up the Stack · 2026-07-09 · essay · historical commodity-and-complements argument
- Anthropic and Amazon compute agreement · 2026-04-20 · company announcement · contracted maxima and company-reported Trainium deployment
- Epoch AI: How much does it cost to train frontier models? · 2024-06-03 · independent estimate · training-run cost methodology and uncertainty
Routing and agents
- NIST: AI Agent Standards Initiative · 2026 · standards · interoperability and security work, not adoption evidence
- OWASP: AI Agent Security Cheat Sheet · accessed 2026-08-12 · security guidance · agent-specific risks and controls
- Ramp Router · accessed 2026-07-26 · correction · Ramp was placed in L6 routing on this map and should not have been: a company routing its own traffic is not a peer of the gateway vendors beside it. It is opening the router by request, which is worth watching and is why the link stays
- Mozilla.ai: The Control Layer · 2026-07-07 · essay · public argument for the control-layer framing
- Linux Foundation: Agentic AI Foundation · 2025-12-09 · standards governance · MCP contribution and AAIF formation
Policy and governance
- European Commission: AI Act enforcement from August 2, 2026 · 2026-07-31 · regulator · enforcement and transparency dates, with exceptions and transitions
- FTC: large AI partnerships and investments · 2025-01-17 · regulator study · compute access, switching costs, talent, and information access
- OSI: Open Source AI Definition 1.0 · accessed 2026-08-12 · definition · distinguishes system freedoms from access to weights
- European Commission: Digital Markets Act · accessed 2026-08-12 · distribution governance · gatekeeper framing for core platform services
- EO 14409: Promoting Advanced AI Innovation and Security · 2026-06-02 · primary · opt-in early-access review for frontier models
- European Commission: General-purpose AI obligations · current at cutoff · regulator guidance · applicable dates and obligations