Until recently, traffic on the open web came in two broad shapes. Human browsing, episodic, attention-bound, hard-capped by how many pages a person could read in a sitting. And programmatic scraping, high-volume, fan-out, mostly stateless, mostly invisible to the user.
A third shape is emerging fast. Browser-using AI agents, Anthropic’s Computer Use, OpenAI’s Operator, the various open-source autonomous agents, drive a real browser through a sequence of pages on behalf of a user. The traffic they generate doesn’t look like either of the previous two. Sites that defended successfully against scraping aren’t yet sure what to do about it. Infrastructure providers underneath those agents are still figuring out the right primitives.
This post is a snapshot of what AI agent traffic actually looks like in production today and how it’s shaped the infrastructure stack that supports it.
What the traffic looks like at the wire
A canonical AI agent flow today: user asks the agent to “find me the cheapest non-stop flight from New York to Tokyo in late August.” The agent spins up a headless Chromium, navigates to Google Flights, fills in the form, submits, parses results, follows the cheapest into the airline’s site, navigates to the booking page, confirms availability, returns the answer.
That’s 8–15 HTTP requests over 30–90 seconds, with the following properties:
Bursty. Either zero requests or a sustained sequence, no steady-state in between. The agent is idle until the user asks, then runs hard for a minute.
Stateful within the burst. The agent’s flow has cookies, a session, a User-Agent. Requests N+1 needs to look like a continuation of request N from the target site’s perspective. An IP change mid-flow breaks the session.
Heterogeneous endpoints. Each agent run visits multiple distinct sites, search engine, airline 1, airline 2, possibly a comparison aggregator. Each site has its own anti-bot posture.
User-anchored geography. The user wants flights from JFK, not from a random datacenter. The agent’s traffic should geolocate plausibly to where the user is asking from, or at least to where they want to appear to be booking from.
Latency-sensitive. The user is sitting there waiting. Per-request latency of 800ms instead of 200ms multiplies across 12 requests to make the difference between “the agent answered in 30 seconds” and “the agent answered in 1.5 minutes.”
This shape doesn’t match either the human-browsing model (too fast, too stateful at machine speed) or the scraping model (too few requests per session, too session-bound, too user-anchored).
Why naive infrastructure fails
A few patterns that experienced data teams use successfully don’t carry over:
Per-request rotation of a large residential pool. The default scraping pattern. Wrong for agents because the session needs IP coherence, login cookies, search state, fingerprint binding. Per-request rotation breaks the session at request 2.
Datacenter proxies for speed. Tempting because of the latency profile. Wrong because the upstream targets the agent visits (Google, airlines, e-commerce, banks) aggressively defend against datacenter traffic. Half the agent’s runs fail with CAPTCHAs.
Single static residential IP. Tempting because it’s coherent. Wrong because the IP burns fast across agents, one IP serving thousands of agent flows looks like a scraper after the first 100 runs.
The shape that works is closer to sticky sessions on residential, with a fresh session per agent run, with geographic targeting that matches the user’s intent, with the session bounded to the run’s natural lifetime.
The pattern that works
The architecture most production agent deployments converge on:
user_request → agent.spawn( proxy_session_id=hash(user_id, request_id), # unique per user-run pair proxy_country=user_geo_or_intent, proxy_ttl=longer_than_expected_run, # don't expire mid-flow ) → browser navigates target sites through that session → agent returns result → proxy session expires naturallyThe proxy abstraction is per-run, not per-request. Inside a run, the agent has one consistent residential IP. Across runs, every agent flow gets a fresh IP from a fresh ISP from (usually) a fresh city. Pool diversity protects against any single IP being burned by repeated agent traffic; session coherence protects against the target site flagging the agent as suspicious mid-flow.
This is functionally the same pattern that a comparison-shopping bot would use, sticky residential session per session, per-customer attribution to a stable sid. The wrinkle for AI agents is that the volume is dramatically higher (every user query that triggers an agent run is a session) and the duration is shorter (most agent flows are under 2 minutes).
Bandwidth-priced residential infrastructure fits this naturally: agent runs are bandwidth-bounded transactions, not concurrency-bounded ones. Pay per GB the agents move; concurrency is the agent runtime’s problem, not the proxy’s.
What target sites are doing
A lot of nothing, yet. Most major sites still treat AI agent traffic the same as scraping traffic, same anti-bot rules, same blocking. This is going to change quickly, in two directions:
Sites that benefit from agent traffic will accommodate it. Booking flows, e-commerce checkout, comparison shopping. The agent is a real user being served by a layer of automation; the conversion is still real. Smart sites are starting to publish agent-friendly endpoints, robots-style declarations that say “treat traffic with this user-agent and this header as a human-mediated agent, don’t block, do throttle.”
Sites that lose from agent traffic will harden. Anything ad-supported has a real problem, agents don’t see ads, don’t click ads, don’t convert advertisers. News sites, free content sites, anything monetized through impressions has incentive to detect and block agent traffic specifically. This is going to be the next leg of the anti-bot arms race, and it will be more contested than scraping was because the agent layer has powerful corporate backers who lose if their agents get blocked.
The infrastructure layer in the middle, that’s us and our peers in residential proxy networks, sits in an interesting spot. We’re the access layer that lets agents reach sites the sites don’t yet welcome them on. As the negotiation between sites and agent providers plays out (probably through a mix of contracts, payment relationships, and revised robots.txt-style protocols), the role of pure infrastructure providers will narrow on the “permitted” path and widen on the “needs IP-level diversity” path.
What to watch in 2026
A few signals worth tracking if you’re building on agents:
The fraction of agent runs that need re-auth mid-flow. Today it’s near-zero with proper sticky sessions. If it starts climbing, target sites have learned to detect agent fingerprints and are challenging mid-session. Mitigation requires either better browser fingerprinting on the agent side or different proxy strategies.
Latency p99 on multi-step agent flows. Today it’s mostly network and target-site response time. If proxy gateways become a bottleneck under concurrent agent load, the infrastructure layer needs to scale.
Geographic agent traffic distribution. Today most agent traffic geolocates to wherever the agent runtime is hosted (US-East mostly). As agents start mediating real user transactions (shopping, booking, banking), traffic needs to geolocate to the user’s location for site logic to work correctly. This is the bull case for city/ASN-precise residential infrastructure becoming the default.
Agent-friendly site declarations. Watch for the emergence of an agents.txt analog or a structured “I welcome agent traffic with these constraints” declaration. If it happens, the proxy layer’s role narrows; if it doesn’t, the proxy layer remains the access mediator.
The takeaway
AI agents are a real new traffic shape. They’re not scraping, not browsing, not RAG retrieval, they share characteristics with each but match none of them cleanly. The infrastructure underneath has to flex to support per-run sticky sessions at scrape-volume concurrency with user-anchored geography and latency targets a third of what scraping tolerates.
The good news for infrastructure providers: residential proxy networks built right already support exactly this shape. Sticky sessions per agent run, fresh IPs per session, geographic precision, bandwidth pricing that scales with usage. The primitives that matured serving scrapers and comparison bots are the same primitives agents need.
The product question for the next two years isn’t whether agent traffic will be a real category, it already is. It’s how cleanly the infrastructure stack and the target-site ecosystem will converge on terms both can live with. We’ll have a sharper picture by next year’s launch post.