TL;DR An AI agent that drives a browser starts on your laptop, where one Chrome window is all it needs. It outgrows that setup the moment it has to run unattended, run more than one task at once, survive a crash, or reach a site that blocks it. Those are the signals to move the agent onto a cloud browser: a browser that runs as managed infrastructure instead of a window on your machine. This post covers when to move and what changes when you do.

An AI agent that reads and clicks web pages needs a real browser underneath it. Your LLM or coding agent writes the plan, but something has to render the page, run its JavaScript, hold the session cookies, and actually press the button. On your laptop that something is the Chrome window you can see. It works, and it keeps working right up until the agent has to do its job somewhere other than your desk.

The gap is not the model and not the agent code. It is the browser they run on. A local browser is a single window tied to one machine and one person watching it. Real agent work is unattended, concurrent, and hostile, and a local browser was never built for any of those three. This is the same reason the browser runs as its own layer in a production agent, separate from the model that decides what to do.

What is a cloud browser for an AI agent?

A cloud browser is a real browser that runs on remote infrastructure and that an agent controls over a network connection instead of on the local machine. The agent connects to it the same way it would connect to a local Chrome, through the Chrome DevTools Protocol, so the automation code barely changes. What changes is everything around the browser: it starts on demand, runs without a screen, scales to many browsers at once, records what happened, and lives behind an IP and identity built for automated traffic.

The short version is that the browser stops being a window on your machine and becomes a service you call. You ask for a browser, you get one, you drive it, you close it. The reliability of keeping that browser alive at scale becomes someone else's job.

How do you know your agent has outgrown a local browser?

Four signals tell you an agent has crossed from a demo into real work. Each one is a place where a local browser stops being enough.

The agent needs to run unattended

The first version runs when you run it, on the machine in front of you, while you watch. The real version runs on a schedule, or when a webhook fires, or when a user is asleep. A local browser assumes a person is there to launch it, click through a login, and notice when it hangs. Nobody is there at 3am. A cloud browser starts on demand from an API call and runs with no screen and no one watching, which is what unattended actually requires.

The agent needs to do more than one thing at a time

One browser window handles one task at a time. The moment you have a hundred users, or a queue of a thousand jobs, one window is a bottleneck, and running a hundred Chrome windows on your laptop will exhaust its memory long before you get there. Cloud browsers scale horizontally: you launch as many independent sessions as you need, each isolated from the others, and you are not limited by one machine's RAM.

The agent needs to survive failure

When a local browser crashes, the run is gone and so is the evidence. You cannot see what the agent saw, so you cannot tell whether the model made a bad call or the page changed. Debugging an agent you cannot watch is the hardest part of running one. Cloud browsers record the session, so a failed run leaves a replay and logs you can open afterward and see exactly where it went wrong.

The agent needs to reach a site that blocks it

Many sites treat automated traffic differently from a person, and an agent coming from a data-center IP with a default browser profile often gets a challenge instead of the page. Solving that reliably means the right IP reputation, a consistent browser fingerprint, and a way to prove the agent should have access. That is a standing job, not a one-time fix, and it is the piece teams most underestimate when they run the browser themselves. Browserbase handles this through Verified access and works with bot-protection providers to give agents verified access to the sites they need.

Local browser vs cloud browser for agents

The trade-off comes down to who owns the reliability of the browser. Running it locally keeps everything on your machine and costs nothing to start. Running it in the cloud hands off the parts that get hard at scale. Here is how the two compare on the dimensions that decide an agent's fate in production.

What changes in your code when you move?

Less than you would expect. Because a cloud browser speaks the same protocol as a local one, moving an agent over is mostly a change of where the browser lives, not how you drive it. With Stagehand, you launch a Browserbase browser instead of a local one and keep the same act, extract, and observe calls on top.

import { browserbase, Stagehand } from "@browserbasehq/stagehand";
import { z } from "zod/v4";

async function main() {
  const browser = await browserbase.launch({
    apiKey: process.env.BROWSERBASE_API_KEY,
  });
  try {
    const stagehand = await Stagehand.create({ browser });
    const [page] = await browser.context.pages();

    await page.goto("https://stagehand.dev");

    const extractResult = await stagehand.extract(
      "Extract the value proposition from the page.",
      z.object({ valueProposition: z.string() }),
    );
    console.log(extractResult.data);

    await stagehand.act("Click the 'Evals' button.");

    const observeResult = await stagehand.observe("What can I click on this page?");
    console.log(observeResult.data);

    await stagehand.close();
  } finally {
    await browser.close();
  }
}

main();

If you are driving the browser directly rather than through Stagehand, the change is the same shape. You ask Browserbase for a session and connect your existing automation code to it over the network, instead of pointing it at a local Chrome.

import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY });

const session = await bb.sessions.create({
  projectId: process.env.BROWSERBASE_PROJECT_ID,
});

// Connect your Playwright or Puppeteer code to session.connectUrl over CDP.

When should you stay local?

Local is the right call while you are still figuring out whether the agent works at all. Prototyping, a script you run by hand a few times, a demo on your own screen: none of that needs infrastructure, and adding it early is just overhead. The signals above are the line. Cross any one of them, running unattended, running concurrently, needing to see failures, or getting blocked, and the browser is no longer a detail you can keep on your laptop.

If your agent has crossed any of the four signals, the next step is to run it on a browser built for that. Create a free Browserbase account, launch a session, and point your existing agent at it.