Field Brief AI Capacity Planning July 2026

The Network Cost of AI: From User Prompts to Agents

A human-paced assistant waits for the next prompt. An agent can keep planning, calling models, and using tools after the user stops typing. That changes token demand, model cost, traffic, concurrency, and which link carries the work.

In brief One visible request is not one unit of AI consumption. Count the model calls, tokens, tool traffic, active time, and paths behind the completed task.

Human-paced AI and agentic AI can begin with the same user goal, then create radically different amounts of work. The difference is autonomy: how much execution continues before a person has to act again.

AI changes the unit of network demand.

The useful planning question is not “How much bandwidth does AI use?” It is “How much traffic does this workflow generate, how long does it remain active, and where does it cross the network?”

This brief is designed for enterprises with 600 or more workers. That does not mean every employee becomes an AI user on day one. It means the access layer has to absorb adoption as it spreads across teams, floors, buildings, and branches. At that scale, aggregate concurrency—not one person’s prompt—is what turns a small workflow into a material infrastructure decision.

AI does not dominate the enterprise link today. Cisco’s report says inference traffic remains negligible beside major categories such as video in the near term. The planning signal is the combination of rapid adoption and a different traffic shape: longer connections, more upstream traffic, and more overlapping model and tool calls.

Traditional web demand is often described as short, bursty, and mostly downstream. AI inference has a different signature. In Cisco’s 2026 AI Impact on Wide Area Networks report, measured AI inference flows lasted about twice as long as non-AI web flows, while the median regular web flow rate was ten times higher. AI was not always a bigger burst. It was a smoother connection occupying the network for longer.

Direction changes too. Nine percent of measured AI inference flows were upstream-heavy, compared with roughly 0.5% of ordinary web transactions. The median downstream-to-upstream ratio narrowed from 145.39:1 for non-LLM traffic to 21.11:1 for AI traffic. That matters at branches and campuses designed around download-heavy behavior.

Observed traffic fingerprint Regular web AI inference
Flow duration How long the connection stays active
normalized baseline
≈2× approximately twice as long
Median flow rate Throughput while the flow is active
10× higher median rate
lower and smoother
Upstream-heavy flows Flows sending more than they receive
≈0.5% ordinary web transactions
9% measured AI inference flows
Down / up ratio Median traffic direction balance
145:1 strongly downstream
21:1 meaningfully more symmetric
Cisco’s measurements compare live AI inference traffic with non-AI web traffic. The multiples are normalized to make the behavioral difference readable; they are not universal sizing constants.

Transport behavior adds another planning dimension. AI services in the study used both TCP and QUIC in a nearly even flow-count split, but QUIC carried 57% of AI data volume. That can change what monitoring and inspection tools can see. The takeaway is not that every AI application has the same profile. It is that a capacity model based only on yesterday’s short, downlink-heavy web session is incomplete.

A user and an agent do not create the same workload.

The difference is not whether AI is present. It is whether a person gates each next step—or software keeps deciding, calling, and retrying on the person’s behalf.

Human-paced AI is the familiar assistant pattern: a person sends a prompt, the model responds, and the person reviews the result before the next meaningful step. The assistant may still use retrieval or tools, and one request can still be large. The defining constraint is that human interaction paces the workflow.

Agentic AI accepts a goal and controls more of the execution loop. The agent can plan, call a model, query a source, use a tool, inspect the result, revise the plan, retry, and sometimes delegate work to other agents before returning to the user. One visible task can therefore produce many inference requests and network conversations at software speed.

One goal, two operating patterns

The agent keeps working after the user stops typing.

Human-paced assistant Person gates the loop
User prompt Model call User review

Usually one or a few calls before the person decides what happens next.

Agentic workflow Software runs the loop
Goal Plan Model Tools Verify

Repeated calls, growing context, tool payloads, retries, and parallel work can accumulate behind one final answer.

Cisco controlled test 26.8 MB total traffic triggered by one deep-research agent task
Traffic increase +450% versus Cisco’s human-performed comparison task
Sources explored 44 through the workflow’s web-proxy tool
Incremental traffic 70% attributed to AI inference

What the 450% means: Cisco measured total traffic for one controlled research task. A 450% increase means about 5.5 times the human-task baseline in that example. It does not mean every agent needs 5.5 times the peak Mbps on every link.

Measured values are from Cisco’s 2026 AI Impact on Wide Area Networks report. The operating-pattern comparison is conceptual; implementations vary by model, agent loop, tools, context, and placement.

This is a continuum, not a clean product category. An assistant can call several tools, and an agent can stop after one step. For planning, classify the completed workflow by observed behavior: model calls per task, tokens per call, tool transfers, task duration, retries, parallelism, and the boundaries crossed.

Tokens price the model. Bytes load the network.

They often rise together in an agentic workflow, but they measure different things and should never be converted with one universal ratio.

Tokens are the units models process. Input tokens include the prompt and context sent to the model; output tokens are generated by the model. Providers may also distinguish cached input and reasoning tokens. API cost is commonly based on those token categories and the selected model’s rates.

Agentic AI can multiply token consumption in three ways. First, one task can require many model calls. Second, later calls may carry prior messages, tool results, source excerpts, or working state back into the context. Third, retries, verification passes, and parallel agents can repeat work that the user never sees. The useful unit is therefore tokens per completed task, not tokens in the final answer.

Model work Task tokens Σ calls × (input + output)

Shows how much text and context the model processed and generated.

Model economics Task cost token category × model rate

Translates uncached input, cached input, and output into an editable cost estimate.

Network demand Task traffic model + tools + sources + overhead

Includes bytes that token counts cannot describe, such as documents, images, APIs, and tool payloads.

This is why a token forecast is not a bandwidth forecast. The same token count can travel with different serialization, encryption, streaming, caching, and tool data. Conversely, a large file transfer can add substantial traffic while contributing few model tokens if it is filtered or processed before inference. Measure both ledgers and correlate them by completed task.

Calculate the task before you size the link.

Start with a simple workload profile. Open the technical view when you need to control model calls, token categories, prices, traffic, duration, placement, and concurrency directly.

Interactive AI workload calculator

Connect tokens, cost, traffic, and peak link demand.

Choose a workload pattern

Profiles are starting assumptions. Only the Cisco profile’s 26.8 MB traffic value is a measured result.

Model calls / task12
Tokens / task114K
Traffic / task8 MB

Illustrative agentic planning profile. Open Technical view to change every assumption.

Adoption and concurrency Emerging adoption

2 completed tasks per user each day · 10% active at peak · one workflow each → 60 simultaneous workflows

Move the slider to change task frequency, peak-active share, and parallel workflows. The selected workload card continues to define the work inside each task.
Model work / day 136.8M 14,400 model calls across completed tasks
Estimated model cost / day $201.60 $4,032 per 20 workdays
Full workflow traffic / day 9.6 GB 192 GB per 20 workdays
One completed task Agentic workflow
Model calls12
Tokens114K
Model cost$0.168
Network traffic8 MB

Do not convert tokens into bytes. The cost ledger counts model processing. The traffic ledger also includes tool calls, source data, protocol overhead, and any payloads that never become model tokens.

One completed task vs. the human-paced starting profile

See what the agent loop multiplies.

Baseline: 1 call · 2.5K tokens · 0.5 MB · 30 sec
Model calls12×
Token work45.6×
Model cost37.3×
Workflow traffic16×
Average task transfer rate1.6×

This is a per-task comparison against the calculator’s illustrative human-paced profile. Daily totals and peak link demand also depend on task frequency, duration, placement, and concurrency.

Whole-link busy hour

See the AI increment inside existing demand.

46.3% utilized after AI

Before AI 450 Mbps 45% of link capacity
AI adds at peak +12.8 Mbps 60 simultaneous workflows
After AI 462.8 Mbps 46.3% of link capacity

537.2 Mbps of modeled headroom remains. AI adds 1.3 percentage points to link utilization.

Show the calculation method Daily tokens = 600 users × 2 tasks × 12 calls × (8,000 input + 1,500 output) Daily cost = uncached input + cached input + output at the entered rates AI peak = 8 MB × 8 ÷ 300 sec × 60 simultaneous × 100% link share Whole link = 450 existing + 12.8 AI = 462.8 Mbps

The workload card defines what happens inside one completed task. The adoption slider controls how often that task runs and how many workflows overlap: task frequency, peak-active share, and parallel workflows. Its five milestones are transparent planning positions—not an adoption forecast.

The default agentic profile is deliberately transparent: 600 enabled workers, two completed tasks per user per day, 12 model calls per task, 8,000 average input tokens and 1,500 output tokens per call, 25% cached input, and editable planning rates of $1 per million uncached input tokens, $0.25 per million cached input tokens, and $5 per million output tokens. Those are assumptions, not a claim about a particular model or deployment.

Switch to the Cisco research profile to load the measured 26.8 MB workflow-traffic value. Its model-call and token inputs remain illustrative because Cisco’s report publishes the network result—not a token ledger for that task. The calculator keeps that boundary visible instead of inventing a token count and labeling it measured.

Daily tokens, daily cost, and daily traffic describe cumulative consumption. Peak Mbps describes simultaneous pressure at one link. The same organization can have a large monthly model bill with little office-link impact if agent fan-out stays in a provider cloud—or modest token usage with a large local transfer if workflows move documents, images, or datasets across an enterprise boundary.

Adoption scale

See tokens, cost, and traffic compound together.

Rows reuse the selected workload assumptions at three adoption levels. Cost uses the editable rates above.

AI-enabled users Model calls / day Tokens / day Model cost / day Traffic / day
600 14,400 136.8M $201.60 9.6 GB
1,500 36,000 342M $504 24 GB
5,000 120,000 1.14B $1,680 80 GB

Where the bytes land matters more than the total.

The same agent task can be inexpensive at the office edge and expensive at enterprise egress—or the reverse—depending on where orchestration, models, and tools run.

If an agent runs in a cloud service, the office access link may carry only the user’s request and the final streamed response. Most of the agent-to-model and agent-to-tool traffic can remain inside the provider’s cloud. If the agent runs in an enterprise data center, those fan-out calls may cross a WAN, firewall, proxy, private interconnect, or internet egress point instead.

Traffic placement

Measure at the boundary you intend to protect or expand.

01 · User edge
Device → access → WAN Always sees the user request and returned answer. It sees fan-out only when the agent is on the far side of this boundary.
Access-link measurement
02 · Enterprise boundary
Agent → security → egress Can carry repeated model, retrieval, and tool calls when the agent is hosted inside the enterprise.
Egress measurement
03 · Service fabric
Models, tools, and sources Cloud-hosted fan-out may never return through the office link even though it is part of the total system workload.
The calculator’s “traffic crossing this link” input exists for this reason. Set it from observation where possible; use 100% only as a conservative bound when architecture details are not yet known.

Placement also changes troubleshooting. A slow answer from an internal AI assistant can still be caused by an oversubscribed access-switch uplink even when the model is healthy. Conversely, an office link can look healthy while an enterprise egress point, security stack, or cloud interconnect is carrying the agent’s hidden fan-out. Total bytes describe the workload. Link-local measurements identify the bottleneck.

The quiet risk is concurrent state.

A lower-rate flow is not necessarily a lighter operational burden when it remains open longer and overlaps with hundreds of other tasks.

Longer-lived AI connections change more than utilization. They can increase the number of simultaneous sessions held by firewalls, proxies, network address translation, load balancers, and monitoring systems. Agentic workflows add fan-out: one user task can create multiple model and tool conversations before the answer returns.

Connection occupancy

Different flow shape, different operating pressure.

Regular web short, higher-rate bursts
AI inference lower-rate, longer-lived flow
This is a qualitative timeline based on Cisco’s observed duration and median-rate relationship. It illustrates occupancy, not an exact byte-for-byte trace.

That is why average daily volume and peak Mbps belong in the same model but answer different questions. Daily volume informs transit, egress, and cost. Peak Mbps informs immediate link pressure. Concurrent flows, duration, and transport mix inform the stateful infrastructure in between. None should be inferred from only one of the others.

Latency needs similar care. Cisco notes that today’s model inference time can dominate the network—for example, tens of milliseconds of network latency inside a response that takes seconds to generate. As inference hardware becomes faster, the network becomes a larger share of the experience. The practical response is not to blame or absolve the network in advance. It is to measure model time and path time together.

Turn the workload change into an access-layer decision.

AI strengthens the case for a faster, more efficient access layer—but the upgrade trigger is measured aggregate demand, not the word “AI” on an application roadmap.

The traffic profile is changing in several directions at once: longer-lived sessions, more upstream context, more concurrent flows, and agent fan-out across models and tools. Across a 600+ worker enterprise, those characteristics join video, cloud applications, and device growth on the same shared wireless and switching infrastructure. The relevant unit becomes the combined busy-hour load across a floor, building, or site—not a single user’s average.

Cisco’s Wi-Fi 7 design guide describes the technologies that expand that envelope: 320 MHz channels can double potential throughput versus 160 MHz, 4096-QAM carries 20% more data per symbol under suitable radio conditions, and Multi-Link Operation can use multiple bands to improve throughput, latency, and reliability. These are shared-radio capabilities—not guaranteed application speeds for every client.

Observed constraint Evidence to collect Action to evaluate
Wireless airtime or contention

Busy-hour channel utilization, retries, client density, roaming, latency, and 6 GHz-capable client share.

Wi-Fi 7 design using 6 GHz, MLO, wider channels where appropriate, and a channel plan matched to the environment.

AP wired uplink near 1 Gbps

AP switch-port throughput, burst behavior, queue drops, negotiated speed, and power mode.

2.5, 5, or 10 GbE multigig ports so the wired handoff does not cap aggregate wireless capacity.

Many APs converge on one switch

Access-switch uplink utilization, oversubscription, buffer pressure, and simultaneous AI task volume.

Higher-capacity switch uplinks or fabric sized for the combined busy-hour load—not the rating of one AP.

WAN or security boundary is slow

Link-local AI traffic share, upstream/downstream balance, flow duration, loss, latency, and inspection load.

WAN, egress, or security capacity at the constrained boundary. A wireless refresh will not repair a bottleneck elsewhere.

The wired side has to keep up with the radios. Cisco’s current Wi-Fi 7 portfolio illustrates the range: the CW9172 uses a 2.5 GbE multigig uplink, while the higher-capacity CW9176 supports 2.5, 5, and 10 GbE. Cisco’s design guide notes that capable Wi-Fi 7 access points can exceed a 1 GbE handoff under aggregate load. That is the practical case for multigig access switching: prevent the AP’s switch port from becoming the ceiling after investing in more wireless capacity.

This does not mean every branch needs 10 GbE to every AP today. Client support, channel availability, RF design, cabling, Power over Ethernet, switch uplinks, WAN capacity, and actual workload concurrency still determine the result. Upgrade the layer the evidence identifies, then rerun the same representative AI tasks to prove the user experience changed.

Call to action Build one AI-ready access baseline this quarter.

Choose a representative office or branch from the 600+ worker environment. Measure three real AI workflows during the busy hour, trace every boundary they cross, and compare the result with wireless airtime, AP ports, switch uplinks, security inspection, and WAN headroom.

Build the baseline before adoption hides it.

The goal is not one universal “AI bandwidth” number. It is a repeatable measurement method for each important workflow and network boundary.

01 Define representative work.

Separate simple chat, retrieval, coding, document analysis, image generation, and agentic research. Each has a different task size, duration, and fan-out pattern.

02 Measure one completed task.

Capture bytes, duration, upstream/downstream balance, flows, transport, and user-perceived time. Repeat enough times to understand median and high-end behavior.

03 Observe the right boundary.

Measure access, WAN, enterprise egress, data-center, and cloud paths separately. The total workflow and the load on one link are not the same quantity.

04 Model actual concurrency.

Use task starts by minute and active duration—not just licensed users—to establish a peak planning envelope. Recheck after rollout changes user behavior.

05 Correlate path and workload.

Connect flow and link data with model runtime, tool calls, errors, and experience. ThousandEyes network tests, for example, expose loss, latency, jitter, throughput, and hop-by-hop path evidence that can separate link pressure from model delay.

The result should be a living workload profile: completed tasks, model calls, input and output tokens, cache share, model cost, MB per task, active seconds, upload ratio, concurrent flows, transport mix, path placement, peak starts per minute, and user experience. Rerun it when the model, agent loop, tool set, data source, pricing, or hosting pattern changes.

AI capacity is not a single forecast. It is a measured relationship between work, time, concurrency, and place.

Start with one real task. Trace the traffic it creates. Identify the boundary that carries it. Then scale the math with observed usage instead of a generic assumption. That is how an AI roadmap becomes a network plan.

Source Trail View the Evidence and Calculation Method Measured findings are kept separate from illustrative calculations and author interpretation.

Cisco: AI Impact on Wide Area Networks

Primary source for the live traffic comparison, near-term scale, flow duration and rate, upstream-heavy flow share, down/up ratios, TCP/QUIC mix, and the controlled deep-research test.

OpenAI: Token Definitions

Primary documentation for the distinction among input, output, cached, and reasoning tokens, and for the explanation that model usage and pricing are tracked in token categories.

ThousandEyes Network Tests

Primary product documentation for the network measurements referenced in the operational playbook: loss, latency, jitter, throughput, path trace, hop IPs, and per-hop latency.

ThousandEyes Path Visualization

Primary product documentation for visualizing end-to-end paths and the network nodes between an agent and target.

Cisco Wi-Fi 7 Design Guide

Primary source for 4096-QAM, 320 MHz channels, Multi-Link Operation, access-layer design considerations, and the relationship between high-capacity Wi-Fi 7 radios and switch-port speed.

Cisco Wi-Fi 7 Access Points

Primary product data for the concrete multigig examples: a 2.5 GbE uplink on the CW9172 and a 2.5/5/10 GbE multigig uplink on the CW9176.

Calculator Method

Task tokens equal model calls × average input and output tokens. Cost separates uncached input, cached input, and output at editable per-million-token rates. Daily traffic equals users × completed tasks × MB per task. Peak AI Mbps equals task traffic × 8 ÷ task seconds × link share × simultaneous workflows. The human comparison divides each selected per-task result by the illustrative assistant baseline of one call, 2,500 tokens, 0.5 MB, and 30 seconds, using the same entered token rates. Monthly totals use 20 workdays and decimal network units.

Transparent arithmetic · no forecast model

Interpretation Boundary

Cisco’s 26.8 MB and 450% results describe one controlled deep-research workflow across the measured system. The calculator marks that traffic value as measured; its associated token, price, duration, concurrency, and placement defaults remain editable author assumptions, not Cisco findings or product sizing guidance.

Author analysis
Join the thread

React or leave a comment.

What are you measuring as AI traffic moves from experiments into daily work?