Proxies for AI browser agents: the 2026 workload shape

AI browser agents arrived as a production category in late 2024 and matured quickly through 2025-2026. Claude Computer Use, ChatGPT Operator, Gemini's browser-use variants, and a long tail of open-source agents (browser-use, Nanobrowser, Skyvern, and more) now form a distinct workload shape that doesn't fit the traditional scraping taxonomy and doesn't fit the traditional eval taxonomy either.

The proxy layer under an agent is the part most teams underspecify. This post is the working shape that agent- operating teams end up with, and the reasons each piece of the config matters.

What makes agent traffic different

A browser agent sends traffic that looks like a mix of three patterns that used to be distinct:

1. Human-timescale interactive browsing. The agent loads a page, thinks for several seconds, clicks something, reads, thinks again. From the target's side, the timing profile reads closer to a user than to a scraper.
2. Machine-timescale execution. When the agent decides, it executes fast — form fills at keystroke speeds that are typing-rate-like but without human-realistic dwell; API-like sequence of requests without the typical between-action variance.
3. Multi-turn reasoning over a session. Unlike scraping (which rotates per-request) or traditional browser automation (which maintains session but executes fast), agents hold state over many turns that span minutes to hours.

These mix together in ways that stress anti-bot systems differently than either pure scraping or pure user traffic.

What the proxy layer needs to provide

Long-sticky sessions

Agent sessions regularly span 5-60 minutes. Per-request rotation breaks the target's session-cookie state; the agent loses everything after the first few requests. ISP (static residential-ASN) is the right class for most agent work, specifically because sticky sessions are free — the IP just stays assigned.

For shorter agent runs (under 10 minutes) residential with sticky-10m or sticky-30m is acceptable. For longer (>30 min), ISP's lifetime-of-subscription stability is the only thing that works reliably.

Realistic latency shape

Agents think. The network layer shouldn't add more latency than the agent's thinking time. A residential proxy that adds 200ms per request is fine; one that adds 500ms starts to compound across a 50-turn session into minutes of wall-clock overhead.

Datacenter proxies add ~10-30ms — useful for agents that the target doesn't classify on ASN. But many modern anti-bot systems (particularly for consumer web properties) classify datacenter IPs aggressively, and agent traffic from datacenter origins frequently gets challenged or bounced.

ISP is the sweet spot: datacenter-like latency (~20-50ms added) with residential-ASN classification. Most production agent infrastructure we see runs on ISP for this reason.

Country / region targeting

An agent operating on behalf of a user in Berlin should present as originating from Germany. An agent operating a scheduled task for a UK team should present as originating from the UK. Region mismatch between agent location and user location surfaces in ways that are confusing to debug — content-policy layers, cookie regions, and language defaults all shift.

Our country pages document the ASN depth per market; the residential proxy page covers the overall class.

Identity consistency per task

A single agent task should use a single exit IP from start to finish. Rotation mid-task produces confusing behaviour:

• Cookies set early stop being honored
• Rate limits hit differently per request
• Some platforms detect the origin change and challenge

The header contract that makes this easy: one X-Squad-Session value per agent task, persisted for the task lifetime. Agent frameworks typically have a session identifier already; propagating it to the proxy layer is usually one change.

Observable exit identity

For debugging agent behaviour, knowing which IP and session the agent used per task matters. When something goes wrong, "what exit did the agent use on that request" is the first question. SquadProxy captures exit IP per session in the account dashboard; see the API reference for how to pull it programmatically.

Agent traffic the proxy should NOT do

Two things worth calling out explicitly:

Captcha solving through the proxy

Captcha solvers are a distinct product category. SquadProxy does not solve captchas; we route traffic. Agents that encounter captchas need a captcha-solving layer in the pipeline (2captcha, Anti-Captcha, or self-hosted). The proxy layer's job is to make captchas less common by presenting legitimate-looking origin, not to solve them when they appear.

Fingerprint masquerading

Agents need realistic browser fingerprints (TLS JA3, HTTP/2 fingerprinting, canvas, WebGL). These are browser-layer concerns, handled by the browser-automation library (Playwright with its anti-detection config, or the agent's own browser integration). The proxy layer provides the network path, not the browser identity.

Typical configuration

For a production agent infrastructure we've seen work:

# Agent task runs a multi-turn browser session against
# a set of target websites. One task = one session = one IP.

import httpx
from browser_use import Agent

class SquadProxyProxy:
    def __init__(self, task_id: str, country: str = "us"):
        self.task_id = task_id
        self.country = country

    def get_proxy(self):
        return {
            "http": f"http://USER:PASS@gateway.squadproxy.com:7777",
            "https": f"http://USER:PASS@gateway.squadproxy.com:7777",
        }

    def get_headers(self):
        return {
            "X-Squad-Class": "isp",          # static residential-ASN
            "X-Squad-Country": self.country,
            "X-Squad-Session": f"agent-{self.task_id}",
        }

async def run_agent_task(task_id: str, prompt: str, country: str = "us"):
    proxy = SquadProxyProxy(task_id=task_id, country=country)

    agent = Agent(
        task=prompt,
        llm=... ,  # Claude / GPT-4 / Gemini
        browser_config={
            "proxy": proxy.get_proxy(),
            "extra_http_headers": proxy.get_headers(),
        },
    )
    return await agent.run()

The X-Squad-Session value ties the session to the task; the session identifier stays stable for the lifetime of the agent run, which means the exit IP stays stable too.

What this pattern doesn't cover

• Captcha encounter rate — function of browser fingerprint, target's anti-bot posture, and occasional bad luck. Proxy doesn't fix this beyond presenting legitimate origin.
• Agent skill at the task — proxy doesn't affect whether the agent knows how to fill a form correctly.
• LLM-side rate limits on the agent's reasoning API — these are separate from proxy rate limits. See LLM evaluation use case.
• Cost beyond the proxy layer — LLM inference, browser compute, storage, observability all sum to more than the proxy cost at scale.

Cost shape

Agent infrastructure at scale is concurrency-heavy and bandwidth-light. A single agent task might run 30-50 turns × 100-500 KB per turn = 5-25 MB total bandwidth. A fleet running 100 concurrent agent tasks uses maybe 2-3 GB/hour.

Where the bill comes from is the concurrency ceiling and the ISP IP allocation. Our Team plan covers a 100-concurrent agent fleet comfortably; Lab plan covers larger fleets. See pricing.

Vendor-specific cluster posts

Two vendor-specific companion posts:

• Proxies for Claude Computer Use
• Proxies for ChatGPT Operator

Each covers the specific anti-bot and session patterns of the respective agent system.

Related

• Proxy type: ISP — the exit class most agent infrastructure routes through
• LLM evaluation use case — eval methodology that applies to agent benchmarks
• Residential vs datacenter for AI — broader routing matrix
• Best proxy criteria for LLM training