Hosted Agents: The Practical Runtime for Browser-Use AI Workloads

# Hosted Agents: The Practical Runtime for Browser-Use AI Workloads

AI agents that interact with the web need a browser runtime. The open‑source browser-use ecosystem has made it simple to define agent goals with Python, but every agent still requires a real Chromium instance to execute those goals. Running that browser locally works for demos, but production workloads quickly expose limitations: inconsistent environments, scaling bottlenecks, and the overhead of managing browser sessions.

Hosted agents solve this by decoupling agent logic from browser execution. Instead of spinning up a local Chrome with Playwright or Puppeteer, you point your agent code to a remote Chromium session that is managed, scaled, and secured as part of a cloud service. This post explains how hosted agents work with Remote Browser, why they are the missing runtime layer for browser‑use projects, and how to integrate them in minutes.

What Are Hosted Agents?

A hosted agent is an AI-driven browser automation process that runs on a remote Chromium instance rather than on your local machine. The agent code (written in Python, TypeScript, or any language with a CDP client) connects to a cloud-managed browser via the Chrome DevTools Protocol (CDP) or WebDriver. The remote browser handles:

• Full HTML rendering and JavaScript execution.
• Persistent cookies, localStorage, and session state (persistent profiles).
• Proxy and geolocation configuration.
• Stealth features to avoid bot detection.
• Session isolation between concurrent agents.

The agent itself remains lightweight—it only sends high-level instructions and receives page state. The heavy lifting happens inside the remote browser.

Hosted vs. Local vs. Self‑Managed

For browser‑use agents that need to run 24/7, access sites with geo-restrictions, or scale across dozens of concurrent task executions, hosted agents eliminate the operational debt.

Why Hosted Agents Matter for browser‑use

The browser-use library has become the de facto standard for defining AI browser tasks. A typical workflow looks like this:

from browser_use import Agent
from langchain_openai import ChatOpenAI

agent = Agent(
    task="Find the cheapest flight from JFK to LHR next Friday",
    llm=ChatOpenAI(model="gpt-4o")
)
await agent.run()

By default, the agent uses a local Chromium instance. That’s fine for prototyping, but when you move to production you need:

• Reliable uptime – Your local machine may sleep, restart, or lose network.
• Session persistence – Long‑running agents require cookies and login state to survive across invocations.
• Geographic targeting – An agent checking prices for UK users should appear to be in London.
• Concurrent execution – Many agents working on different tasks simultaneously.

Hosted agents solve all of these. Instead of a local browser, you provide a remote endpoint:

agent = Agent(
    task="...",
    llm=...,
    browser=RemoteBrowserConnection(
        cdp_url="wss://remote-browser.dev/session/abc123",
        # or use Playwright connect_over_cdp
    )
)

Remote Browser’s API gives you that CDP endpoint instantly, with persistent profiles, configurable proxy, and full session isolation.

How to Connect a Hosted Agent to Remote Browser

Connection is done through standard Playwright or Puppeteer. Here’s a TypeScript example using Playwright’s CDP integration:

import { chromium } from 'playwright';

// 1. Get your hosted browser session from Remote Browser
const CDP_URL = 'wss://remote-browser.dev/session/xyz789';

// 2. Connect Playwright to the remote instance
const browser = await chromium.connectOverCDP(CDP_URL);
const context = await browser.newContext({
  // optional: inject persistent profile, set locale, etc.
});
const page = await context.newPage();

// 3. Let the agent drive the browser
await page.goto('https://example.com');
// … agent tasks …
await browser.close();

The key benefit: you never manage a Chromium binary, browser driver, or display server. The hosted agent receives a fully functional browser in under one second.

Using Persistent Profiles

For agents that need to stay logged in (e.g., managing a SaaS account or scraping a dashboard), Remote Browser supports persistent profiles. Each session can be configured with a unique profile ID. The cookie jar, localStorage, IndexedDB, and extension data survive across reconnects.

const browser = await chromium.connectOverCDP('wss://remote-browser.dev/session/xyz789?profile=my-saas-bot');

The profile is stored securely on the remote browser server and can be reused on demand.

Comparison: Hosted Agents vs. Other browser‑use Runtimes

There are several ways to run browser‑use agents. The table below compares hosted agents (Remote Browser) with common alternatives.

For teams building browser‑use automations that need reliability and geographic distribution, hosted agents reduce infrastructure to zero.

Using Hosted Agents with browser‑use Quickstart

If you already have a browser-use agent, switching to a hosted agent is a three‑step process:

1. Create a session via Remote Browser’s API or dashboard (returns a CDP endpoint).
2. Connect your agent code using connectOverCDP (Playwright) or puppeteer.connect.
3. Run your agent as before.

The browser-use library’s Agent accepts a custom browser connection. Refer to the Remote Browser documentation for the exact connection string format.

Example: hosted agent with browser‑use (Python)

from browser_use import Agent
from playwright.async_api import async_playwright

async def run_hosted_agent():
    async with async_playwright() as p:
        browser = await p.chromium.connect_over_cdp(
            "wss://remote-browser.dev/session/abc123"
        )
        agent = Agent(
            task="Click the 'Subscribe' button on the landing page",
            browser=browser,
            llm=...  # your LLM
        )
        await agent.run()

The browser is remote, but the agent code runs anywhere—your laptop, a GitHub Action, or a serverless function.

Stealth and Proxy for Hosted Agents

Websites often detect and block automated browsers. Remote Browser’s hosted agents include configurable browser settings to reduce detection:

• Proxy integration – Assign a residential or datacenter proxy per session.
• Viewport & geolocation – Emulate a specific screen size and location.
• Time zone & locale – Match the profile’s expected region.
• WebGL, canvas, and font fingerprinting – Controllable parameters (see /documentation for the full list).

These settings are configured when creating a session and persist for its lifetime. No need to patch browser launches or install third‑party stealth plugins.

When Hosted Agents Beat Self‑Hosted Setups

For most production browser‑use workloads, hosted agents offer a better total cost of ownership when you factor in operations, maintenance, and developer time.

Getting Started

Ready to try hosted agents with Remote Browser?

1. Sign up for an account (free tier available).
2. Create a session – you’ll get a CDP endpoint.
3. Connect your browser‑use agent using Playwright’s connectOverCDP.
4. Scale – add more sessions for concurrent tasks.

Refer to the Remote Browser pricing page for current session costs and free allowances. For detailed API references, visit the /documentation. And if you want to understand the underlying architecture, read our earlier post on remote browsers for AI agents.

---

*Remote Browser is a hosted Chromium runtime built for AI agents. It supports Playwright, Puppeteer, Selenium, and direct CDP connections. No servers to manage – just a CDP endpoint.*

*External reference: Playwright CDP documentation*