AI agents and infrastructure: how much compute, and where?

01 / The demand story and the location story are different

Our central view is that agents can increase the amount of work performed per user, while spreading that work across a wider infrastructure stack. Neither trend selects a data-center location by itself. A viable project still needs a customer, an appropriate technical design, reliable power, connectivity and a credible delivery plan.

This research combines two questions: how personal and enterprise agents change compute demand, and where their workloads may run. Published product announcements, research observations and our scenario analysis are identified separately. The result is a framework for evaluating infrastructure, not a forecast of contracted megawatts.

02 / More steps per task can mean more compute

An agent may plan, call tools, inspect results and retry before returning an answer. Anthropic reported roughly four times as many tokens for agents and fifteen times for multi-agent systems versus chat in its research-system data. These are observations from a particular system, not universal multipliers for every application. [1]

Adoption also needs a clear denominator. Menlo Ventures and Morning Consult surveyed 5,067 U.S. adults in July 2026; agent-use results should be read with each chart’s stated population. Trial, regular use, paid use and retained use measure different things. None alone tells us how much incremental electricity a user consumes. [4]

Token totals are not interchangeable. Input, output, cached context and repeated reasoning carry different computational costs. A service that remains available all day also does not imply a GPU working at full utilization all day. Measure completed useful tasks, their resource requirements and the cost of serving them.

03 / An illustrative bridge from tokens to average power

Zeke Hausfather examined 3.2 billion tokens from eight weeks of his own Claude Code logs. He estimated 170 kWh of data-center electricity, with a 70–330 kWh range. The logs are observed; the electricity is modeled. This implies roughly 53 Wh per million tokens, with a rounded 22–103 Wh range. Its cache-heavy workload is not a population average. [2]

We use those rounded intensities only to show how assumptions change scale. Every row below assumes one million tokens per user per day. These are hypothetical user counts and usage levels, not an adoption forecast.

The output is average power over 24 hours at the assumed daily usage. It is not a site’s interconnection requirement, IT nameplate capacity or an annual demand forecast. Provisioning also depends on peak concurrency, redundancy, utilization, hardware and the energy-accounting boundary. Do not add facility overhead a second time to an intensity that already includes it.

For comparison, Google estimated 0.24 Wh for a median Gemini Apps text prompt using a broader serving-system boundary. A median chat prompt and a long-running agent task are different units of work. This benchmark cannot simply be multiplied by an agent’s prompt count. [3]

04 / Five places where agent workloads can run

Product architecture already spans local and cloud execution. Meta describes Muse as using a dedicated cloud computer, while Apple’s third-generation foundation-model family includes both on-device and server models. These examples support a hybrid view; they do not disclose a map of the physical facilities serving each request. [5], [6]

The following placement framework is our synthesis. The layers can work together within one application. “Edge” is not a single facility size, and an enterprise agent is not automatically an on-premises workload.

05 / Distributed inference and large clusters can coexist

Akamai’s AI Grid announcement combines orchestration across a 4,400-location network with a rollout of thousands of GPUs. Its network-location count is not a count of GPU data centers. The same announcement describes a four-year, $200 million agreement for a multi-thousand-GPU cluster: distributed routing can coexist with concentrated capacity. [7]

NVIDIA’s Vera Rubin POD architecture combines GPU, CPU, networking and context storage. Its design illustrates why agent infrastructure is broader than accelerators alone. This is a vendor architecture, not proof that every agent workload needs that scale or configuration. [8]

CBRE’s H1 2026 North American report describes growing interest in 25–75 MW sites for inference, enterprise AI and latency-sensitive use, and 2–20 MW urban infill demand currently led by hyperscaler network infrastructure. These are market observations in a specified region, not universal sizing rules or proof of demand for a particular site. [9]

06 / Location follows the service requirement

Latency should be budgeted across the entire task: device and network access, model serving, tool calls, data retrieval and repeated steps. A small network delay may be immaterial for one asynchronous task and decisive when many sequential calls or real-time interactions accumulate. Test an actual service-level target rather than assigning a universal distance radius.

Data processing location, storage location and legal residency requirements are separate questions. Microsoft revised its Copilot in-country processing timeline in April 2026. A country appearing in an older announcement does not establish that the same service is available there now. Check the product, contracted scope and current deployment evidence for each workload. [10]

For an Asian campus, this means evaluating actual customer geography, cross-border connectivity, data constraints, power delivery and cooling conditions together. Proximity to a major market can be valuable, but a regional AI narrative is not a substitute for a customer-specific deployment plan.

07 / From a demand signal to deliverable capacity

Our infrastructure interpretation is a sequence of evidence, not a direct conversion from token volume to megawatts. First establish recurring paid use. Then identify the incremental workload and whether it requires new capacity. Match its location and technical requirements to a customer with an executable commitment. Finally verify the site, power, engineering, operating responsibilities and economics.

A project review should answer six practical questions: Who pays, for what service and term? What capacity is committed rather than discussed? When can usable power arrive? Does the facility support the required racks, cooling and network? Who operates and accepts the service? What funds maintenance, hardware renewal and downside cases?

For a buyer discussion, ask for the inference and training mix; the GPU, CPU and storage requirements; and the real-time services, target latency and regions to serve. These answers guide design. A single campus’s CPU-to-GPU power ratio should not become a planning standard for unrelated workloads.

For INTERTIE.ai, this research informs how we assess AI-ready infrastructure. Our adopted model integrates campus development, company-owned GPUs and cloud operations. GPU deployment and cloud services are in development. The analysis does not change the commercial status of any project or establish existing ownership or available capacity.

08 / What would change the conclusion?

The most useful next evidence is measured resource use per completed task, paid retention, deployment geography and signed capacity commitments. Track energy per useful task alongside total demand: efficiency can lower the footprint of each task even while adoption grows. Token pricing is not a substitute for energy measurement.

The thesis weakens if task economics fail, usage does not persist, efficiency outpaces adoption, or existing capacity absorbs the work. The placement case changes if models move onto devices, data constraints tighten, or centralized systems serve the required latency at lower cost. Our conclusion remains conditional: agents may expand infrastructure demand, but capacity must be earned workload by workload and project by project.