Agentic AI changes how enterprise traffic behaves, but vendors are blurring three very different infrastructure problems. Before buying an “AI-ready” network, there are a few different criteria a B2B leader should consider.
For most of enterprise computing history, the network was treated as plumbing. Applications generated requests, the network carried them, and infrastructure teams tried to make the process sufficiently fast and reliable that nobody else had to think about it.
AI changes that relationship. An AI application rarely makes one request and returns one finished result. An agent may call a model repeatedly, retrieve information from several databases, query outside services, invoke tools, exchange state with other agents and return to the model before it completes one task. The network is no longer transporting the output of the computation. It is participating in the computational loop.
That makes connectivity part of AI performance, reliability, security and cost. It does not mean every company suddenly needs an ultra-low-latency network overhaul.
That distinction matters in assessing a recent VentureBeat article, sponsored by Tata Communications, arguing that continuous inference and agent-to-agent traffic are exposing the limits of traditional network architecture. Its central premise is sound. Its broadest performance claim, that mission-critical AI workloads now require latency below 10 milliseconds, is much less universal than the article suggests.
What the traffic data actually shows
Cisco’s 2026 study of live AI inference traffic across service-provider networks provides some of the clearest evidence that AI traffic is structurally different from ordinary web traffic.
The Cisco report found that:
● AI inference traffic grew roughly fourfold during eight months of observation, although it remains small relative to categories such as video.
● AI inference flows lasted approximately twice as long as conventional web transactions.
● Nine per cent of AI flows carried more data upstream than downstream, compared with approximately 0.5 per cent of ordinary web transactions.
● In one controlled agent test, the agent generated 450 per cent more traffic than a person performing the task manually. Approximately 70 per cent of that traffic came from model inference.
Enterprise networks have generally been designed around human-paced requests, downstream-heavy consumption and reasonably predictable application behaviour. Agents operate at software speed and can initiate many more transactions without waiting for a person.
But Cisco also found that the median flow rate of ordinary web traffic was ten times higher than that of AI inference traffic. More importantly, it concluded that network latency is not yet the dominant inference bottleneck. Model processing generally takes hundreds of milliseconds to several seconds, while network latency in its examples was around 20 to 50 milliseconds. Cisco explicitly said the evidence does not currently justify large-scale movement to edge inference purely for latency reasons.
The network is becoming more important. That is different from saying it is already the principal constraint in every AI deployment.
Three different network problems are being sold as one. Much of the “AI-ready infrastructure” discussion collapses three separate workload classes into a single purchasing argument.
| Network problem | What the workload requires | Businesses affected |
| Large-scale model training | Constant GPU synchronization; extremely high bandwidth, lossless transport and microsecond-scale communication | Model builders and companies operating large GPU clusters |
| Real-time or physical AI | Predictable end-to-end latency, edge placement and resilience | Industrial systems, fraud detection, autonomous operations and some live voice, video or vision applications |
| Enterprise agents | Reliable calls among models, databases, APIs and tools, with strong identity and observability | Most businesses deploying agents into production |
The first problem is real, but specialized. Meta, for example, built a separate backend network for distributed AI training using a non-blocking RDMA fabric and 400G connections. Its engineering account is evidence of how demanding large-scale training can be. It is not evidence that an ordinary B2B company needs to reproduce Meta’s architecture.
The second problem is highly use-case dependent. Amazon Search has operated a machine-learning service with a requirement of no more than 10 milliseconds at the 99th percentile, but AWS also supports real-time inference measured in milliseconds or seconds and asynchronous inference lasting as long as 15 minutes. The appropriate latency target comes from the business process, not from the fact that AI is involved. (Amazon Search case study; AWS asynchronous inference)
For most B2B leaders, the third problem is the immediate one.
Agent reliability is dependency reliability
A conventional application can sometimes degrade gracefully when one service is slow. An agent may be unable to continue at all when a model endpoint, identity provider, retrieval service or tool API fails.
The mathematics becomes unfriendly very quickly. In a simplified example, if a task depends on ten serial components and each is available 99.9 per cent of the time, their combined theoretical availability is approximately 99 per cent. Add more dependencies, retries and external providers and the reliability of the completed business task can fall well below the reliability promised by any individual vendor.
Latency accumulates in the same way. Ten sequential calls that each add 100 milliseconds create one second of delay before accounting for model generation or application processing. A poorly controlled retry can multiply token use, network traffic and API charges. In an action-taking agent, it can also produce duplicate orders, messages or transactions.
This is why the relevant economic unit is no longer cost per token or cost per gigabyte. It is cost per successfully completed business task. That number should include inference, data retrieval, network egress, tool calls, retries, human review and failed runs.
The security boundary is changing too
Agents are also a new class of network actor. They may use delegated authority, operate continuously and call business systems through APIs rather than human-facing interfaces.
Thales’ 2026 Bad Bot Report found that bots generated 53 per cent of web traffic in 2025, 40 per cent of all traffic was classified as malicious bot activity, and 27 per cent of bot attacks targeted APIs. This does not mean legitimate enterprise agents are malicious. It means security systems can no longer assume that a valid credential attached to machine traffic is sufficient evidence of legitimate intent.
Every production agent should therefore have its own non-human identity, narrowly scoped permissions, transaction limits and revocation mechanism. Its tool calls should be logged, attributable and separable from the activity of both employees and other agents. Network segmentation can enforce some of those boundaries, but buying SASE or a new WAN service does not solve agent authorization on its own.
What an AI-ready network should actually do
A genuinely useful AI network is not simply a faster connection carrying an AI label. It should be:
● Observable: AI inference, retrieval and tool traffic can be distinguished and traced across the complete task.
● Workload-aware: critical operational inference can receive different treatment from background summarization or batch analysis.
● Programmable: capacity, routing and policy can change through controlled software interfaces instead of manual device configuration.
● Deterministic where it matters: failover, spending limits, security policy and prohibited destinations are governed by explicit rules rather than model improvisation.
● Identity-linked: policy follows the user, service or agent initiating the action rather than assuming anything inside the network is trusted.
● Resilient: failed paths can be rerouted, interrupted work can resume safely, and retries cannot create uncontrolled actions.
● Economically visible: leaders can see the total cost of moving data among clouds, regions, models and tools.
Tata’s claim that programmable connectivity can scale capacity dynamically and reroute traffic after a disruption describes a useful direction. Its claim of savings of up to 30 per cent, however, comes from Tata’s own product announcement, not an independent comparison. It should be tested against a company’s real workloads and current contracts.
Seven questions leaders should ask before buying anything
| What to ask | Proof to require |
| Where do the models, agents, data and tools run? | A map of every endpoint, provider, region and cross-border path |
| What sits on the critical path of a completed task? | End-to-end traces rather than a diagram of the intended architecture |
| What latency does the business process require? | P50, P95 and P99 targets tied to a customer or operational outcome |
| What happens under stress or during a provider failure? | Load tests, fault injection, failover timing and recovery results |
| What does one successful task cost? | Inference, egress, APIs, retries, failed runs and human review |
| What can each agent access and do? | Separate identities, least-privilege permissions, limits, logs and a kill switch |
| Can the system change providers? | Open interfaces, exit provisions and tested alternative routes |
Tata and Bloomberg Media Studios surveyed 501 senior executives and found that 77 per cent considered AI a board-level priority while 65 per cent described their infrastructure as legacy or still developing. The commissioned study supports the existence of a readiness gap. It does not establish that networking is the cause of every company’s gap. Data quality, integration, compute, governance and organizational capacity can all become the limiting factor.
The best sequence is to map the AI task, measure every dependency and identify the actual constraint before selecting the cure.
The network matters because the system matters
B2B leaders should stop treating the model as the whole AI product. The product is the model plus data, tools, identity, orchestration, compute and the network connecting them. Performance and risk emerge from the whole system.
They should be equally resistant to the claim that every AI application requires a new network architecture or sub-10-millisecond performance. A faster network cannot repair poor data, excessive agent calls, a slow model, weak authorization or a badly designed workflow.
AI is making the network strategically visible. That is the real change. The next step is not an indiscriminate infrastructure overhaul. It is evidence: task-level traces, realistic load tests, explicit latency budgets, dependency maps and costs measured against completed work.
A network can transport a hallucination in under 10 milliseconds. That does not make it a better business decision.
