---
type: analysis
slug: agent-capacity-is-easier-to-project-than-agent-demand
title: "Agent capacity is easier to project than agent demand"
description: "Epoch AI turns projected HBM supply into a striking capacity estimate, but the gap between sessions hardware could serve and useful work customers will buy remains unmeasured—not proof of either a shortage or a glut."
published_at: 2026-10-06T11:00:00.000Z
topics: ["trends"]
source_urls: ["https://epoch.ai/publications/estimating-the-agent-population","https://developers.openai.com/blog/openai-for-developers-2025","https://t.me/qwgai/990","https://epoch.ai/"]
author: "Andrey Reshetnikov"
author_profile: https://newruntime.com/owner-profile.md
---
# Agent capacity is easier to project than agent demand

Epoch AI turns projected HBM supply into a striking capacity estimate, but the gap between sessions hardware could serve and useful work customers will buy remains unmeasured—not proof of either a shortage or a glut.

## Summary

Epoch AI estimates that HBM shipped in 2025–2027 could support about 30–170 million concurrent frontier-model agents, assuming full deployment and allocation to those workloads. A more efficient model benchmark raises the estimate to about 1.9 billion. These are conditional capacity calculations, not deployment or demand forecasts; the report’s spending comparison also depends on utilization and API-equivalent pricing.

## What happened

Epoch AI estimates agent concurrency from projected HBM supply and serving capacity, where memory capacity and bandwidth shape how many sessions can run and at what speed. It then translates continuous agent-hours into human-workweek equivalents and estimates spending at API-equivalent prices. Under its stated assumptions, using 20% of central capacity would correspond to $2.6–5.3 trillion in annual API-equivalent spending after deployment, compared with roughly $1 trillion in annualized developer revenue by end-2027 under its fivefold-growth comparison. This is a conditional comparison of potential capacity and spending, not realized revenue, observed adoption, or a labor-market forecast. The central uncertainty is whether actual workloads, affordability and utilization can support anything like that scenario.

## What the archive adds

The archive describes a broader transition from chatbots toward agents that plan, use tools and require orchestration and oversight. That makes potential demand plausible, but it does not establish its volume or value. The dossier also points to alternative open-source stacks and local-agent benchmarking; these are relevant context for competition and efficiency, but the supplied excerpts do not establish their performance or economics relative to Epoch AI’s assumptions. The evidence pack does not provide verified historical utilization outcomes for comparable infrastructure forecasts.

## Trend signal

AI infrastructure analysis is increasingly translating hardware supply into possible workloads. Epoch AI’s estimate makes the serving ceiling legible; agent platforms and tool-using workflows offer a possible route to consuming that capacity. Yet the conversion is not automatic: theoretical sessions are not equivalent to useful tasks, and API-equivalent spending is not a measure of what customers will pay. Long-context workloads are an important caveat to simple agent counts: they can change memory needs and serving capacity, so a session estimate may not map cleanly to a stable number of practical workloads. This is a demand-proxy mismatch, not evidence that hardware is already idle or scarce.

## Why now

Epoch AI’s estimate is driven by projected HBM shipments over 2025–2027, which define the potential memory pool (primary evidence). Memory capacity and bandwidth shape possible concurrency and serving speed (primary evidence). The report’s more efficient-model scenario produces a substantially higher concurrency estimate, making model efficiency an important driver (primary evidence). Finally, its API-equivalent spending comparison assumes deployment, allocation, utilization and pricing conditions that the report’s capacity estimate does not itself establish (primary evidence).

## Connections to other events

The strongest inference is that capacity projections put pressure on the demand proxies used to interpret them. The 30–170 million range depends on hardware shipment, deployment, allocation and serving assumptions; the higher efficiency scenario shows how sensitive concurrency can be to model assumptions. A long-context workload may consume a different share of the memory pool than a short task, while an agent session can vary in value and resource use. So neither headline concurrency nor API-equivalent spending settles whether this capacity will be economically productive. The binding question is verified task value per unit of deployed inference, not the number of sessions a model can theoretically sustain.

## Why it matters

Builders should optimize and evaluate real tasks rather than target a projected agent count. Buyers should treat capacity estimates as infrastructure scenarios, not as automation plans or evidence of guaranteed price declines. If deployed supply outruns useful demand, competition may shift toward efficiency and price; if valuable workloads absorb it, capacity could instead enable broader delegation. Either outcome depends on utilization and customer economics that the estimate cannot determine.

## What happens next

- **At least one published analysis or product case study will report agent workload economics using completed-task value or success alongside capacity or request counts.** (6 months, 55%). Watch for: A public technical report, product document or case study includes a measured task-success or value metric alongside inference or capacity measures.
- **A public discussion of scaling an agent workload will identify deployment, workload allocation, utilization or serving assumptions as material to interpreting nominal capacity.** (12 months, 60%). Watch for: A company report or technical publication explicitly distinguishes available inference capacity from the share actually deployed or used for agent tasks.

## Limits and uncertainty

The evidence supplied confirms Epoch AI’s headline estimates and their conditional nature, but does not include the full report’s technical detail needed to independently verify every calculation or quantify the long-context caveat. The capacity estimate depends on projected HBM shipments, deployment, allocation and serving assumptions; the spending comparison additionally depends on API-equivalent prices and utilization. Nothing here establishes a current shortage, future oversupply, actual task volume, or customer willingness to pay. This take could be wrong if demand expands quickly or serving economics change materially.

## Skill to build now

Practice cost-per-verified-task evaluation. Choose one representative workflow, define what counts as a correct result, run a small batch of tasks, and record inference cost and pass/fail outcome for each. Compare total cost with the value of successful tasks; include one long-context example rather than extrapolating from short prompts.

## Reader takeaway

This week, instrument one agent workflow and calculate cost per verified task: log model charges or token use, retries, and which outputs pass a defined quality check, then compare that cost with the task’s value to the user or business. Repeat with a representative long-context case. That exercise tests real demand economics; a count of possible concurrent sessions does not.

## Open question

Will HBM-backed capacity make valuable agent work cheaper and more available, or will the demand signals used to justify it continue to overstate what customers will actually deploy and pay for?

## Sources

- [epoch.ai](https://epoch.ai/publications/estimating-the-agent-population)

- [developers.openai.com](https://developers.openai.com/blog/openai-for-developers-2025)

- [t.me](https://t.me/qwgai/990)

- [Epoch AI](https://epoch.ai/)

- [How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks](https://arxiv.org/abs/2604.22750)

- [DeepSeek R1 on H100: Measured Inference Throughput and Cost](https://inferencex.semianalysis.com/run/deepseek-r1-on-h100)

- [AI Inference Performance Benchmarks](https://developer.nvidia.com/deep-learning-performance-training-inference/ai-inference)

- [Is a compute crunch coming?](https://epoch.ai/gradient-updates/is-a-compute-crunch-coming)

- [2026 Market Outlook – “Focus on the HBM-Led Memory Supercycle”](https://news.skhynix.com/en/2026-market-outlook-focus-on-the-hbm-led-memory-supercycle/)

- [Observability and usage | OpenAI API](https://developers.openai.com/api/docs/guides/agents-api/observability)

Author: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json