Agent Browser Runtime: Sessions, Profiles, Proxies, and Live Debugging

An agent browser runtime is the execution environment where AI web agents actually get work done. It is not another automation library, and it is not a thin HTTP wrapper around a headless browser. It is the infrastructure underneath: a hosted Chromium process with an API for creating sessions, persisting profiles, configuring proxy settings, and inspecting live activity while an agent is mid-task.

This post breaks down the four operational pillars of an agent browser runtime — sessions, profiles, proxies, and live debugging — and shows how they map to a concrete implementation you can use with browser-use, Playwright, Puppeteer, or Selenium today.

What is an agent browser runtime?

A traditional browser automation setup has three moving parts: a script (or in this case, an LLM loop), a driver, and a browser binary. The script drives the browser, the driver translates commands, and the browser renders pages. That architecture is fine for a test suite. It is fragile for an AI web agent that must log in, navigate, handle dialogs, retry, and maintain state across dozens of steps.

An agent browser runtime changes the model. The browser is no longer a process you spawn locally. It becomes a managed service. Your agent sends actions over the Chrome DevTools Protocol (CDP), and a hosted Chromium instance executes them in an isolated session. You get a browser session API to create, attach to, and destroy sessions on demand, plus controls for profiles, proxies, and observability that are nearly impossible to build yourself on a laptop.

This matters for anyone using browser-use, the popular open-source browser automation library. Browser-use is the orchestration layer; the agent browser runtime is what the orchestration layer runs on. If you are evaluating browser-use alternatives, pay attention to the runtime underneath rather than the library on top. That is where production failures actually happen.

Why agents fail without a proper runtime

Local Chromium and ad-hoc cloud VMs fail in predictable ways once an AI agent starts doing real work:

• Stateless sessions. Every retry or sub-task starts with a cold browser. Logins are lost, cookies vanish, and the agent redoes expensive steps.
• IP reputation problems. Datacenter IPs get blocked by login flows and anti-bot systems. The agent stalls on a CAPTCHA instead of completing the task.
• No visibility. You cannot see what the agent is doing while it is doing it. Debugging becomes "read the logs and guess."
• Flaky WebSocket plumbing. Exposing CDP publicly is a security risk. Tunneled, authenticated CDP endpoints are the correct pattern, but they are fiddly to build.
• The browser-use developer tax. Every new machine, teammate, or environment requires reinstalling browsers, handling dependencies, and fighting version mismatches.

A browser-use developer hits these walls quickly. The first 50 runs work; the 500th run reveals that session persistence, network identity, and debugging surfaces are not optional — they are the runtime.

Sessions: the core unit of an agent browser runtime

In Remote Browser, every agent gets its own browser session. A session is a live, isolated Chromium process with a stable CDP endpoint. You create it with one API call, connect over CDP, run your agent against it, and close it when the job finishes.

Session isolation is the important part. AI agents are unpredictable. A runaway navigation loop, a heavy page, or a leaked script can consume resources. Isolation guarantees one agent's behavior does not affect another — which is especially important when you run multiple agents against the same site or the same account infrastructure.

The browser session API is deliberately simple:

1. Create a session with optional profile, proxy, and region settings.
2. Attach using the returned CDP URL.
3. Detach and reconnect without losing the browser state.
4. Close the session when the task is complete.

Because the CDP endpoint is authenticated and ephemeral, you can attach from anywhere: a CI runner, a serverless function, or your local machine. That means the same session can outlive the process that created it. If your agent crashes, the session stays alive and a new process can attach to it and continue. The rate at which you create browser sessions is a pricing and concurrency question, not an architectural one; check /pricing for current session limits and parallelism details.

Profiles: persistent state for agents

Sessions give you short-term memory. Profiles give you long-term memory.

A profile is a persistent browser context. It stores cookies, localStorage, IndexedDB, site preferences, and any other state Chromium writes to disk. When a session starts with a profile, it boots with that exact state. When it closes, the state is saved back.

This is what separates a serious agent browser runtime from a bare browser API. Consider an e-commerce agent that checks inventory, a social media agent that posts daily, or a customer-service agent that must stay authenticated to a dashboard. None of these work if the agent must re-authenticate on every run. With profiles, the login happens once; every subsequent session inherits it.

Profiles also support identity separation. You can have one profile per user account, per customer, or per task type. Since profiles are independent of sessions, you can run many sessions against the same profile — for example, several parallel agents that all operate as the same logged-in user, or one agent that rotates between profiles for different workflows.

For a deeper look at how profiles and session persistence fit into agent production architecture, see our earlier post on remote browsers for AI agents.

Proxies: network identity in an agent browser runtime

The web an AI agent sees is not the web you see. Cloud providers' IP ranges are heavily filtered by anti-bot systems, login flows, and content restrictions. A runtime that ignores the network layer will produce agents that fail intermittently and are nearly impossible to debug.

Remote Browser lets you attach a proxy to a session at creation time. The proxy is applied directly to the hosted Chromium, so all traffic — including WebSocket connections from the page — flows through it. You can specify a datacenter or ISP proxy depending on the target site's tolerance.

This is also where the "stealth-related" browser settings live. The goal is not to evade terms of service; it is to make legitimate automation look like a normal user. Configurable browser settings such as timezone, language, and viewport help align the environment with the proxy's geographic location. If you are building at scale, you should also review how detection-adjacent settings work across a fleet of sessions — our post on stealth browsers covers the operational side of that question.

Live debugging: see what the agent sees

The most underrated pillar of an agent browser runtime is live debugging. An AI agent is stochastic. It can decide to click the wrong button, fill the wrong field, or scroll into an infinite loading state. Log output tells you what the agent *thought* it was doing. It does not tell you what the page actually showed.

Remote Browser includes a live viewer that streams the active session as it happens. You can watch the agent operate in real time, see the exact DOM state, and intervene if it goes off course. Combined with CDP access, you can also evaluate JavaScript, inspect network requests, and take screenshots mid-session.

For debugging browser-use workflows specifically, this is a force multiplier. When a browser-use loop spins on the same selector or fails to find a button, the live viewer shows you why within seconds. Instead of guessing, you can inspect the page and fix the prompt, the selector, or the runtime config. This debugging surface is also useful for human review: before trusting an agent to complete a high-stakes task, you can watch a replay of what it did. The underlying CDP integration is standard — Playwright supports connecting over CDP and Puppeteer does too — so your existing debugging tooling works against the runtime.

Runtime comparison at a glance

The table is not about which tool is more "powerful." Local Chromium can do everything a hosted one can. It is about which setup survives contact with production: authentication walls, IP blocks, long-running sessions, and the requirement to debug an autonomous process.

Connecting a TypeScript agent over CDP

Here is what it looks like to connect a Playwright-based agent to a Remote Browser session using CDP. The pattern works identically with Puppeteer and with browser-use's Playwright backend.

import { chromium } from 'playwright';

// 1. Create a browser session with a persisted profile
const res = await fetch('https://api.remote-browser.dev/v1/sessions', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    profileId: 'agent-account-1',
    proxy: 'datacenter:us-east',
  }),
});

const { sessionId, cdpUrl } = await res.json();

// 2. Attach to the hosted Chromium over CDP
const browser = await chromium.connectOverCDP(cdpUrl);
const context = browser.contexts()[0] ?? await browser.newContext();
const page = context.pages()[0] ?? await context.newPage();

// 3. Run your agent loop (Playwright-native or browser-use)
await page.goto('https://app.example.com/dashboard');
console.log(`Session ${sessionId} loaded:`, await page.title());

// The session stays alive even if this process exits.

The code is deliberately minimal. There is no browser installation, no user-data-dir management, and no tunnel to expose CDP publicly. You create a session, attach over a secure URL, and get a real, inspectable Chromium context with profile and proxy already applied.

Taking browser-use to production

If you are already using browser-use, the most direct path to production is to point its Playwright backend at a Remote Browser session instead of a local Chromium. Your agent code stays the same. What changes is everything around it:

• Sessions that survive crashes and retries.
• Profiles that keep logins alive across runs.
• Per-session proxy assignment so the agent's network identity matches the task.
• Live visibility into every step the agent takes.

That combination is what turns a promising browser-use prototype into a dependable agent browser runtime workload. You keep the library you like, and the runtime handles the fragile infrastructure: browser lifecycle, state persistence, network identity, and observability.

The next time you debug a browser-use agent that loses its session, gets blocked by anti-bot logic, or fails in a way that only makes sense if you could see the page — remember that those problems are not agent problems. They are runtime problems. An agent browser runtime exists to solve them before your agent ever runs.