Jay Sahnan and Arik Bird on Building Financial Agents for the Whole Web

Jay Sahnan and Arik Bird open with a question: what is a browser agent? If an agent needs to read information from the web or take action there, it needs a way to use a browser. Booking a flight, planning an evening out, or checking a competitor’s prices can all require sites with no API or MCP interface.

Ramp, Bill, and Stripe all handle sensitive financial information, much of it tucked behind logins or anti-bot protections. Those portals can be difficult to access at scale. The speakers use these companies to show where browser agents can help.

Ramp helps companies manage spending, but growth brought more vendor portals and more receipts to collect. At first, people logged in and fetched the receipts. That can work for a smaller company, but a growing operation cannot keep hiring people at the same pace as the workload.

The example is a flight booked with a Ramp card. After the purchase, Ramp starts a browser agent, sends it to Delta, logs in, retrieves the receipt, and matches it to the card transaction. Once this happens at scale, however, anti-bot systems can block the traffic.

To explain why browser traffic gets blocked, the speakers start with a laptop. Chromium is an executable that opens the web, but a site sees more than a request: it can see browser version, operating system, fonts, screen size, and time zone. It may also recognize a logged-in visitor or a familiar pattern of activity.

A website also sees the network reputation behind each request. Someone using a personal browser may look like a familiar human visitor. Put Chromium into a data center and that pattern changes. A company such as Ramp cannot scale by leaving thousands of laptops open, or by relying on a single person’s scheduled script.

Launching a headless browser in an EC2 instance can produce a new fingerprint each time, along with fresh cookies and another login. A data-center IP can also be an obvious signal. Proxies may change the apparent location or reduce some challenges, but they do not change the underlying browser characteristics.

The speakers describe Chromium as a browser process coordinating a page engine that renders HTML and JavaScript, network requests, and device and graphics functions. Chromium changes frequently, with major releases every couple of weeks and weekly security updates. For a company automating browsers, those changes create ongoing maintenance work.

Browserbase says it forked Chromium to make a verified browser for data-center use. One change is removing the WebDriver automation indicator throughout the code. Another is presenting the browser as Chrome instead of headless Chrome. The speakers emphasize that these changes reach into many parts of Chromium and must keep pace with upstream updates.

The third change is to keep the browser process alive. Many automation jobs start a browser and immediately shut it down when a task ends. Browserbase instead closes the windows while leaving Chromium running, so a new task does not always need to restart the whole process.

The live demonstration starts with one hosted browser. After it loads, the presenter navigates to Rome, then stops the session and launches 100 browsers at once. The group is initially just visiting websites in parallel; the next demonstration is about letting attendees access and interact with those sessions.

The audience can open a random browser through a QR code and interact with it in an embedded view. The demo is a little rough because it depends on Wi-Fi and a tunnel from the presenter’s laptop, but it shows that a cloud browser can be opened and controlled remotely.

The presenters connect the infrastructure example back to Ramp. They say Ramp now deploys thousands of browser agents, has saved more than 30,000 hours of manual data-entry work, and has increased scale fivefold. The time formerly spent collecting receipts can go to other company initiatives.

The next example is Bill, which processes payments across thousands of vendors. Each portal has its own checkout and payment flow, and the interface can change. If people must click through each one, the work does not scale. Bill’s goal was a single agent that could act across many different portals.

Stagehand is Browserbase’s open-source SDK for controlling a browser. The speaker compares it to Playwright with additional capabilities. An agent uses Stagehand to operate the browser, combining standard commands with ways to interpret a page when its interface is less predictable.

A hand-written Playwright script can break when a website moves a button or changes a field label. A selector that worked yesterday may no longer match. One-off local tasks may tolerate that, but companies such as Ramp and Bill need browser workflows that remain reliable every time they run.

Stagehand can still use deterministic commands such as a page click. When a task becomes more complex, a developer can give it a natural-language instruction such as filling out a form or finding a red button. Stagehand examines the page and accessibility tree, then passes a compact view to a model to identify the right control.

The speakers address the cost of sending a full page to a model. In one comparison, raw HTML contains about 122,000 tokens, while Stagehand’s compact accessibility-tree snapshot contains around 4,000. The smaller representation can reduce context and cost while giving the agent selectors it can use.

Browserbase also places Stagehand next to the hosted browser. If an agent runs elsewhere, it may have to send page data back and forth for each action. Running Stagehand alongside the browser cuts those network round trips and can make instructions and interactions faster.

Stripe onboards thousands of merchants over time and must verify that each business is real. Before browser agents, the company had people visit Secretary of State portals to gather the evidence. The speakers describe browser automation as a way to handle this know-your-customer verification.

Stagehand offers three primitives: observe, act, and extract. Observe can find a control, such as a Learn more button, without clicking it. Act performs an action such as clicking Login. Extract turns messy web information into structured output, including a Zod schema that software can pass to an agent.

The first research demo opens Chipotle’s website and extracts what the company sells. The next version checks four sources: the company website, investor relations page, an SEC filing, and a New York Stock Exchange listing. The browser sessions can run in parallel, while a streamed live view is mainly useful during development.

The presenters scale the same workflow to 20 companies. The demo scrolls through results for Chipotle, JPMorgan, and other companies, with the same task running across sites. They show extracted information from the sources, while noting that users do not need to watch every live browser when many sessions are running.

The last results view brings together company information from the website, investor relations, and SEC filing. The presenters say Browserbase’s verified browser can reduce CAPTCHA frequency, and that Stagehand can navigate without someone watching the live view. They point viewers to a reusable prompt on the Browserbase website for getting started.

The talk closes with an invitation to use Browserbase’s website and its copyable prompt to begin building browser-based workflows. The examples have moved from retrieving a receipt, to acting across payment portals, to gathering business information for verification and research.