How to Build Financial Agents That Work Across the Web - Jay Sahnan & Arik Bird, Browserbase
Browser agents for financial data behind logins and anti-bot protection. Covers Ramp, Bill, and Stripe case studies, why cloud browsers get blocked, how Browserbase forked Chromium for reliable data-center use, and how Stagehand's act, extract, and observe primitives keep automations resilient to site changes.
Financial data often sits behind logins and anti-bot walls with no API, and this talk argues that browser agents are the practical way through. The speakers frame a browser agent simply: any agent that needs to read from or act on the web needs a browser, because the hardest-to-reach sites are exactly the ones without an API or MCP server.
Three case studies: Ramp, Bill, and Stripe
The three examples share a pattern. Each company’s critical information lives in portals that require authentication or are protected by bot detection.
Ramp: fetching receipts at scale
Ramp’s problem was retrieving receipts from a growing number of vendor portals for each card transaction. Early on, a team of humans logged into portals and downloaded receipts, which works for a Series A or B company but becomes a hard bottleneck at Ramp’s size. The current approach spins up a browser agent immediately after a card transaction: the agent navigates to the vendor, logs in, captures the receipt, and matches it to the transaction. The result is thousands of deployed browser agents, more than 30,000 manual hours of data entry saved, and a fivefold increase in scale.
Bill: one agent, thousands of portals
Bill processes payments across thousands of vendors, and every vendor portal has its own checkout flow, payment form, and UI that changes over time. Bill’s prior assumption was that this could only be handled by teams of humans clicking through portals. The goal was a single agent that can operate across all of them.
Stripe: automating KYC
Stripe onboards tens of thousands of merchants and must verify that each business is real. Verification often means visiting state Secretary of State portals, which previously required human operators. A browser agent can automate this know-your-customer workflow.
Why browsers get blocked in the data center
A laptop browser carries a rich, consistent identity: browser version, OS, fonts, screen size, time zone, cookies, login history, and a residential network reputation. Moving the same Chromium into a data center breaks that picture. Every headless launch gets a fresh fingerprint, empty cookies, and a data-center IP that is easy to flag. Proxies and location spoofing help only at the margins, because the underlying browser is still recognizably automated.
Forking Chromium for the cloud
Chromium ships a meaningful change roughly every two weeks, which makes it impractical to keep patching an upstream build for automation. Browserbase forked it into a verified browser for data-center use. Two of the changes highlighted were removing the automation flag (setting navigator.webdriver to false everywhere it appears) and changing the browser identity from “headless Chrome” to plain “Chrome.” These sound simple but touch many places in the codebase. The fork also keeps the browser process alive between tasks rather than killing Chromium after each job and closing only the windows, which avoids the cold-start signature of automated sessions.
The live demo launched browsers in the cloud, showed a hosted browser streamed as a live iframe, and ran 100 browsers concurrently across different sites, with attendees able to interact with one of them.
Stagehand versus Playwright
Playwright scripts are deterministic and brittle: a changed button, a renamed field, or an updated XPath breaks the automation. That is tolerable for one-off local tasks but not for systems that need reliability on every run across many sites.
Stagehand is Browserbase’s open-source SDK, built on top of Playwright. It supports ordinary deterministic Playwright calls, and it also accepts natural-language instructions such as finding a red button or filling in a form. To keep costs down, Stagehand reduces the page from its raw DOM to a compact accessibility tree before sending it to an LLM. The speakers gave one example in which the raw HTML was about 122k tokens and the accessibility-tree representation was about 4k tokens, while still producing direct selectors for the model’s chosen actions.
Latency is also addressed by colocating Stagehand with the browser. Instead of round-tripping HTML and action instructions between a remote agent and a data-center browser on every step, Stagehand runs next to the hosted browser, which removes most of that round-trip overhead.
Act, extract, and observe
Stagehand exposes three primitives. observe identifies candidate elements on the page, such as a “learn more” button. act performs an action, such as clicking a login button or entering a password. extract pulls structured data out of messy web pages into a Zod schema, which turns unstructured content into typed data an agent can consume directly. The speakers called extract their favorite primitive.
In the demo, Stagehand extracted company information from Chipotle’s website and then ran the same code across four sources (website, investor page, SEC filing, and the NYSE listing) and then across 20 companies in parallel, including JP Morgan and Goldman Sachs. The verified browser meant fewer CAPTCHAs, and where CAPTCHAs did appear, Browserbase solved them.
The session closed with a prompt-based starter kit and an SEC-filing template that developers can use to start building browser-based workflows.