The dominant operating-model debate in agentic systems treats cloud identity — which hyperscaler holds the account, which region invoices the workload, which IAM surface fronts the resources — as the strategic lever for capacity. This paper argues that the framing is a category error. The cloud account is the invoicing surface; it is not the capacity surface. Where compute actually comes from in 2026 is determined upstream of the account by a six-layer stack: silicon fabrication allocation, accelerator-class allocation, hyperscaler regional buildouts, power and water envelopes, sovereignty regimes, and only finally the cloud account's API. The paper develops the argument in three movements. First, it documents the capacity-identity confusion — the operating pattern in which organizations treat multi-cloud, cloud-portability, and account-level redundancy as their capacity strategy — and shows why those instruments fail to address the upstream constraints that determine whether the requested capacity will exist at all. Second, it specifies the six-layer capacity stack with the constraint structure, time horizon, and failure mode at each layer. Third, it shows how the HGC³AE² governance framework provides the scaffolding for capacity decisions that span this stack. The central claim is operational rather than philosophical: any capacity strategy that begins with cloud-account choice is reasoning about the wrong layer. This is Paper 1 of the *Managing Agentics Ops* series; Paper 2 (Heterogeneous Compute Routing) and Paper 3 (Capex/Opex Inflection) operate on the substrate this paper establishes.