TL;DR Agents are already most of the traffic on the web, but the web still hides behind logins, CAPTCHAs, and forms that were never built for them, and a single session forgets everything the moment it ends. In a joint webinar, Browserbase and Box walked through how those two gaps close together: Browserbase gives agents a real browser to reach the 85% of the web with no clean API, and Box gives them a shared, permissioned, version-controlled file system to remember and collaborate on what they find. Two live demos, a PG&E bill pulled behind a login and turned into structured data, and an end-to-end market-expansion agent, show the pattern in practice.

Watch the full webinar below.

Chris Kim, a senior developer relations engineer at Box, hosted Kyle Jeong, a growth engineer at Browserbase, for a session on connecting both platforms to your agents. The framing was simple: an agent that can act in the real world needs two things it rarely has together. It needs to reach systems that only exist as websites, and it needs somewhere durable to put what it learns so the next run, and the next teammate, can build on it.

Browserbase covers the first half. Box covers the second. This post walks through the thesis and both demos, and points you at the code so you can build the same setup.

Why do agents need a browser at all?

The new user of the internet is not a human. Cloudflare's own numbers, cited by CEO Matthew Prince, put more than 60% of traffic across their network as agents rather than people. The problem is that most of the web was built for humans clicking, not agents calling. A large share of it sits behind CAPTCHA walls, login portals, and pages with no clean API, which is exactly where most knowledge work happens. As Box put it in the recap, agents need the roughly 85% of the web that is not reachable through an API.

Browserbase is the platform for building browser agents: agents that use a real browser to do work on behalf of a person. You get the primitives to give an agent proper web access. Search and Fetch read from the web cheaply. When an agent needs to write to the web, submit a form, click through a flow, or download a file, it needs a browser, so Browserbase runs headless Chromium browsers in the cloud that can act on any site.

Agent identity: trust and authentication

The part you only discover the first time you try to automate the web yourself is identity. Kyle broke it into two halves. Trust is how an agent gets access to the web safely: Browserbase partners with providers like Cloudflare and uses Web Bot Auth, an open protocol, to cryptographically sign its browsers. A provider can check the signature, see the browser is Verified as coming from Browserbase, and let it through instead of throwing a challenge. Residential proxies and automatic CAPTCHA solving round out access for sites that still push back.

Authentication is the other half: staying logged in. You do not want an agent re-entering a password and a 2FA code on every run. Contexts save the state of a browser after a login so future sessions resume already authenticated, and you can attach one context to any session or spin up thousands of them for different portals. Browserbase is SOC-2 Type II compliant and HIPAA-ready, and for teams that want nothing retained, it offers zero data retention and per-session controls to disable recording and logs.

Demo 1: pulling a utility bill behind a login, then reading it with Box

The first demo answers a question every finance and operations team eventually asks: can an agent log in to a portal, download a document, and turn it into structured data, without a human in the loop? The task was a PG&E electric bill.

Kyle first used Contexts to log in to the PG&E account once, saving the authenticated state so the agent would not face the login or 2FA on later runs. Then he kicked off a Browserbase Agent, the managed service where you hand over a prompt and a target outcome and it plans and executes the steps with a single API call. Agents start by breaking down the task to find the cheapest path: it checks whether Search or Fetch is enough before opening a full browser. This task needed a browser, so it opened a live session, navigated to the account, opened the billing history, viewed the PDF, and downloaded it. Downloads land in Browserbase storage by default, or your own bucket on enterprise plans.

From there Box took over. The bill was uploaded into Box, and Box AI ran OCR to extract the figures directly, without downloading the document out to a separate model provider or duplicating it. The file stays in Box, governed, while the agent reads what it needs.

After a run, the Agents dashboard has an optimize tab. A second, outer agent reviews the traces of the first and looks for a faster, cheaper path to the same result, then lets you apply and re-run it with a click. The harness gets better at the task over time instead of running the same slow path forever.

What is Stagehand, and why not just use Playwright?

The second thing Kyle covered was Stagehand, Browserbase's SDK for browser agents. If you have done any browser automation you have met Playwright, Puppeteer, or Selenium. They drive a browser through the DOM, and they were written for testing front-end UIs. That heritage makes them a poor fit for handing to an agent: the extra surface area is token-heavy and slow when a model is the one deciding what to do.

Stagehand is built around three AI primitives instead. act takes a natural-language instruction and performs it on the page. observe returns the actions available on a page, like a clickable button. extract pulls structured JSON out of a page against a schema. All three are self-healing: when a page changes and a cached action misses, the primitive looks at the page again and updates what it does, so you are not paying an engineer to babysit brittle selectors.

The recently launched Stagehand v4 moves the runtime into the browser itself as a Chrome extension. The first two versions were a superset of Playwright; v3 and v4 dropped it for a custom Chrome DevTools Protocol driver. Putting the runtime inside the browser shortens the round trip for every CDP command, which benchmarks to roughly 2x faster than Playwright on executable actions, and it unlocks batching: when a model knows it needs to click three things, Stagehand can dispatch them at once instead of one round trip at a time. Accessibility-tree pruning keeps the page snapshot small so long-horizon tasks do not blow out the context window.

Around those primitives sits a model gateway and router that benchmarks frontier models on real production tasks and automatically serves the most accurate, most cost-efficient one for the job, so you are not throwing your most expensive model at every step. Domain allow-listing blocks any URL you do not want an agent touching at the browser level, a real defense against prompt injection. Action caching, on automatically, replays consistent actions without new LLM calls and has saved customers up to 30% in token cost. Stagehand also reaches into nested iframes and shadow DOM that Playwright cannot, which matters for legacy portals and EHR systems, and it is OpenTelemetry-compatible so you can pipe traces into tools like Braintrust.

Demo 2: driving Stagehand from a thin agent harness

To show Stagehand as a tool an agent controls rather than a script a human writes, Kyle wired it into a thin harness and exposed a small MCP server with three tools: screenshot the page, snapshot the page as an accessibility-tree-plus-DOM representation, and run code against the browser. Instead of offering act, observe, and extract as separate tools, the run tool lets the agent look at the page and generate the code it needs to move the page toward the goal, then execute it. On computer-use benchmarks like Online-Mind2Web and WebVoyager, running code this way came out ahead on both accuracy and cost. In the demo, a simple prompt to find a jacket on Amazon produced a batched sequence, click the search box, type the query, submit, dispatched together and finished quickly.

Where does Box fit, and why not just a local file system?

If Browserbase gives an agent hands to act on the web, Box gives it a memory that other people and other agents can share. Chris made the case that a single agent session is always context-limited, so teams started exporting memory to files an agent can re-read later, which produces impressive personal knowledge bases that act as a second brain for one agent.

Real work is collaborative, and that is where a personal file store falls apart. When agent A shares a document with agents B and C, everyone ends up with a copy, the copies drift out of sync, and no one can tell which version is current or which files are even safe for an agent to touch. Chris pointed to the horror stories: agents reaching confidential files they should never have seen, then taking irreversible actions on them.

Box's answer is to move that personal vault into a shared, governed file system that agents, humans, and applications all connect to as a single source of truth. Files stay synced. Every actor, including each agent, gets its own permission boundary, so an agent might see one folder while you see the rest. Every file keeps a full version history you can revert to, and every action an agent takes is reviewable and auditable. Connecting an agent to Box takes a platform app for credentials, a set of scoped folders, and the Box CLI, MCP, or REST API to wire it in.

Putting both together: an end-to-end market-expansion agent

The final demo is where the two halves meet. The scenario: a fictional mid-size AI company, Relay AI, wants to know whether it should expand into Singapore. That is a real research project, go read authoritative sources, pull down economy reports, extract the facts that matter, write a brief, then combine that brief with internal company documents to produce a strategy. It spans the open web and private, governed files, which is exactly the seam a browser and a file system close together.

Chris set up a Codex agent with access to both the Browserbase CLI and the Box CLI. The Box account already held a company-brain folder with the internal context, a company profile and expansion criteria, plus empty market-research and output folders waiting to be filled.

The first prompt sent the agent to the web through Browserbase to research Singapore as an expansion market: visit three authoritative sources, download a 2025 economy report, extract a few decision-relevant facts, write a research brief, and upload it into the market-research folder in Box. The agent did the whole chain, searching sites, downloading the report PDF, extracting it to text, and writing a cited brief grounded in live sources rather than the model's training data, then landed it in Box where a teammate or another agent could pick it up.

The second prompt closed the loop. The agent pulled the three internal Relay AI documents back out of Box, combined them with the research brief it had just written, produced a strategy document with a recommendation, and uploaded that to Box too, synced and ready to share with a click. Both artifacts are governed, versioned, and collaborative from the moment they exist.

Where this leaves us

The pattern under both demos is the same. An agent that can only call APIs is stuck with the 15% of the web that offers one. An agent that only keeps notes to itself cannot hand work to a teammate. Give it a real browser and it reaches the rest of the web the way a person does, through the login and the form and the download. Give it a shared, governed file system and what it finds becomes durable, permissioned, and collaborative instead of trapped in a single session.

That is the layer Browserbase runs: real browsers at scale, Verified access to sites that check who is asking, Contexts that keep agents logged in, and a recording of every session for when a run needs explaining. If you want to build the setup from the webinar, you can create your first session in a couple of minutes.