AI Agent Browser Automation on Real Devices

Why AI agent browser automation gets blocked more than people do

An agent browsing the web runs the same protocol a person does and gets a different answer. The cause is rarely the agent’s logic. It is the handful of signals the stack underneath it emits before the first page finishes rendering.

Start with the browser. A browser under automation control sets an internal flag that the W3C WebDriver specification requires it to expose to page scripts. Headless and patched-headless stacks also report GPU, font, and sensor surfaces that no shipping consumer handset produces, a far broader mismatch than one property.

Then the network. Cloud-hosted agents exit through datacenter address space, and the organisation owning a given IP range is public information. A request presenting as a consumer’s phone while arriving from a hosting provider’s range is internally inconsistent, and that is cheap for a detector to compute. Layering a residential proxy on top splits the problem rather than solving it: the browser is still in the cloud, only the exit address moved.

Then history. Most agent runs start from a clean container with no cookies and nothing the target has seen before. People return; an agent that resets every run arrives new every time, and first-visit traffic gets the strictest treatment on any site with a fraud budget.

• Fingerprint — a browser stack whose reported hardware matches no device that ships.
• Network — datacenter ranges, or a proxy split where the browser and the exit IP are different machines.
• Continuity — a session that never accumulates the age a returning visitor has.

None of these is a defect in the agent. They are properties of the infrastructure it was handed. Why real devices beat emulators works through the fingerprint layer in detail.

What session persistence buys an agent mid-task

One-shot scraping tolerates rotation. Agent work does not. A task shaped like “log in, filter to last quarter, open each result, extract the table” is a dozen requests that only make sense as one continuous person.

Change the exit IP between step one and step three and the target sees a session cookie issued to one location suddenly presenting from another. The common response is to invalidate the session. That reaches your team as a logged-out agent partway through a task, not as a proxy error, so the first place anyone looks is the script. The script is usually fine.

Holding the cookie constant while the IP rotates underneath it does not fix this either, because detection systems weigh the two together. Session persistence for AI agents covers the mechanism and what a coherent identity requires.

Where the build-versus-buy line usually falls

Building is the right call more often than infrastructure vendors admit. If your agents hit a small set of cooperative targets, or targets that publish an API, a Playwright script on a modest VM is the correct amount of infrastructure. A device network on top of that is cost with no return.

The line moves when the failure mode changes shape, not when volume grows. Buying starts to pay when:

• Blocks arrive in bursts you cannot reproduce locally, so debugging becomes guesswork against a black box.
• Someone now owns fingerprint maintenance as a standing job, tracking detector changes instead of shipping agent features.
• Tasks run long enough that one identity change mid-run costs the whole run, not a single retry.

How Archonum handles it

Archonum runs each agent session on one real consumer smartphone from a network of 250,000+ devices across 175+ countries. Chrome for Android executes on the phone that owns the residential IP, so the browser, the fingerprint, and the exit address are properties of the same hardware rather than three systems kept in sync. One network hop, no proxy split.

It is a drop-in target for the scripts you already have. Point an existing Playwright or Puppeteer job at Archonum and the automation code does not change; country-locking or holding a sticky session is a change to the connection username, not to your agent. No SDK to learn, no rewrite.

Real devices are not a better disguise. There is simply nothing synthetic in the session for a detector to find.