Como criar agentes financeiros que funcionam em toda a web — Jay Sahnan e Arik Bird, Browserbase

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How to Build Financial Agents That Work Across the Web - Jay Sahnan & Arik Bird, Browserbase · Canal: AI Engineer · 19:08 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Dados, bancos de dados e embeddings, Mercados e economia

Resumo

A apresentação explica como agentes de navegador ajudam empresas financeiras a acessar sites difíceis de automatizar, como portais protegidos e páginas sem API ou MCP. Os exemplos da Ramp, da Bill e da Stripe mostram usos em escala, desde buscar recibos até automatizar pagamentos e verificações KYC. Os palestrantes descrevem um Chromium adaptado para uso em data centers e o Stage Hand, que combina automação determinística com instruções em linguagem natural. Demonstrações mostram como executar tarefas em várias empresas e fontes, extraindo dados estruturados com menos tokens e menor latência.

Pontos-chave

Agentes que precisam ler informações ou realizar ações em sites precisam de acesso a um navegador, especialmente quando não há API ou MCP disponível.
A Ramp usa agentes de navegador para acessar portais, capturar recibos e associá-los a transações; a apresentação atribui à automação mais de 30 mil horas manuais economizadas e um aumento de escala de 5 vezes.
Executar um navegador em um data center pode gerar sinais diferentes dos de um navegador usado por uma pessoa, como fingerprint inconsistente, cookies novos e reputação de rede de data center.
A Browserbase descreve um Chromium adaptado, chamado de verified browser, com alterações voltadas a reduzir bloqueios e manter o processo do navegador ativo entre tarefas.
O Stage Hand é um SDK open source para controlar navegadores, construído sobre Playwright e pensado para automações que precisam se adaptar a mudanças nos sites.
O Stage Hand pode combinar ações determinísticas com instruções em linguagem natural, usando o DOM e a árvore de acessibilidade para localizar elementos.
Segundo a demonstração, reduzir o HTML a uma árvore de acessibilidade pode diminuir o conteúdo enviado ao modelo de 122 mil para cerca de 4 mil tokens.
Colocar o Stage Hand junto do navegador hospedado reduz as viagens de ida e volta entre o agente e o navegador, diminuindo a latência das ações.
As três primitivas apresentadas do Stage Hand são observe, act e extract; extract permite converter dados não estruturados em estruturas definidas com um schema Zod.
As demonstrações aplicam o mesmo código a diferentes empresas e fontes, incluindo sites corporativos, páginas de relações com investidores, documentos da SEC e listagens da New York Stock Exchange.

Capítulos

Início	Capítulo	Resumo
00:01	O que são agentes de navegador	Os palestrantes definem agentes de navegador e explicam por que eles são úteis para acessar sites sem API ou MCP, introduzindo os desafios de empresas financeiras como Ramp, Bill e Stripe.
03:40	Navegadores em data centers e acesso confiável	A apresentação compara o navegador de um laptop com um navegador em data center e descreve adaptações no Chromium para reduzir sinais de automação e problemas de acesso.
07:49	Demonstração de navegadores em escala	Os palestrantes demonstram a inicialização de navegadores hospedados, incluindo uma execução simultânea de 100 navegadores, e apresentam resultados de uso da Ramp.
09:53	Stage Hand e automação adaptável	O Stage Hand é apresentado como uma forma de controlar navegadores em milhares de portais, combinando Playwright com instruções em linguagem natural e reduzindo o conteúdo enviado ao modelo.
14:59	Verificações KYC e primitivas do Stage Hand	A Stripe é apresentada como caso de uso para automatizar verificações KYC; em seguida, os palestrantes explicam as funções observe, act e extract.
16:32	Demonstrações de extração em várias fontes	As demonstrações extraem informações sobre Chipotle e executam tarefas semelhantes em várias fontes e empresas, incluindo páginas corporativas e documentos da SEC.

Citações

Tudo o que você precisa fazer na web, seu agent deveria poder fazer com a ferramenta de navegador. — 01:04

Um agent, milhares de portais diferentes. — 10:55

Nesse mesmo exemplo, o Stage Hand reduz o envio de 122 mil tokens para cerca de 4 mil. — 13:27

Observe, act e extract são três primitivas principais que disponibilizamos no Stage Hand. — 16:02

Conceitos e entidades

Browserbase (empresa): Empresa apresentada como fornecedora de navegadores hospedados e ferramentas para executar agentes de navegador em escala.
Stage Hand (ferramenta): SDK open source da Browserbase para controlar navegadores com ações determinísticas e instruções em linguagem natural.
Playwright (ferramenta): Ferramenta de automação de navegador usada como ponto de comparação para o Stage Hand.
Chromium (ferramenta): Navegador de código aberto cuja versão adaptada pela Browserbase é usada em data centers.
Ramp (empresa): Empresa financeira que usa agentes de navegador para acessar portais, buscar recibos e associá-los a transações.
Bill (empresa): Empresa que processa pagamentos a fornecedores e é apresentada como caso de automação de portais com agentes de navegador.
Stripe (empresa): Empresa apresentada como usuária de agentes de navegador para automatizar verificações KYC de comerciantes.
KYC (conceito): Processo de verificação de identidade e informações de empresas, que a apresentação descreve como automatizável com agentes de navegador.
verified browser (conceito): Nome dado na apresentação à versão do Chromium adaptada pela Browserbase para uso confiável em data centers.
Árvore de acessibilidade (conceito): Representação da estrutura e dos elementos acessíveis de uma página, usada pelo Stage Hand para reduzir e interpretar o conteúdo enviado ao modelo.
Zod (ferramenta): Biblioteca de schemas mencionada como forma de estruturar os dados extraídos de páginas da web.
Jay Sahnan (pessoa): Apresentador da palestra sobre a construção de agentes financeiros que atuam na web.
Arik Bird (pessoa): Apresentador da palestra ao lado de Jay Sahnan.

Tradução completa (pt-BR)

00:01 [música] >> Olá. Olá a todos. Estamos aqui para falar sobre como criar agents financeiros que funcionam em toda a web. Espero que estejam tendo um ótimo dia até agora em Nova York. Eu sou Jay. >> Sou Amarik, e acho que o ponto de partida é: afinal, o que é um agent de navegador,

00:32 certo? Então, pensando nisso, primeiro, se pudermos voltar ao slide anterior: uma rápida votação levantando a mão. Quem está criando agents hoje? Levantem a mão. Certo, estamos no lugar certo. >> E quem trabalha com operações financeiras? Ouvi dizer que está acontecendo uma conferência hoje. Alguém trabalha com finanças? Certo, mais alguns engenheiros. Se também quiserem nos fazer perguntas ao longo da apresentação, podem escanear este QR code e mandar ver. >> Legal. De volta à apresentação. Então, o que é um agent de navegador? Um agent de navegador, se vocês

01:04 pensarem bem, se um agent precisa acessar a web, interagir com ela, ler informações da web e realizar ações nela, precisa de um navegador. Seja para reservar uma passagem de avião, marcar um voo, planejar uma noite especial para você e sua esposa ou obter informações de preços de um concorrente, normalmente é preciso um navegador para acessar aqueles sites mais difíceis de alcançar, que não têm uma API nem um MCP. Então, em resumo, tudo o que você precisa fazer na web, seu agent deve ter a ferramenta chamada navegador.

01:37 Levantem a mão: quem conhece estas três empresas? Ramp, Bill, Stripe. São conhecidas pelo público? Legal. Quando pensamos no que essas três empresas têm em comum, bem, primeiro, são todas instituições financeiras e lidam com informações altamente confidenciais. Mas, pensando em empresas como Ramp, Bill e Stripe, muitas dessas informações estão nas partes mais difíceis de acessar da web: seja atrás de um portal no qual é preciso fazer login, seja em um site fortemente protegido contra bots. É extremamente difícil acessar

02:07 essas informações, e a resposta é usar agents de navegador. Então, para começar, vamos falar primeiro da Ramp. Tenho certeza de que todos nesta sala conhecem a Ramp. Na verdade, somos grandes usuários e fãs da Ramp. Ah, eles facilitam muito o gerenciamento de gastos de uma empresa. À medida que cresciam e expandiam, passaram a precisar interagir com portais cada vez mais difíceis de acessar, e com mais portais do que nunca. Então, o problema, ou a lacuna, era: como podemos

02:38 buscar esses recibos com eficiência e em grande escala? Eles não conheciam os agents de navegador. Então, em vez disso, pensaram: “Vamos simplesmente montar uma equipe de pessoas, e elas vão entrar nesses portais e buscar os recibos”. Bem, isso pode funcionar para uma empresa em série A ou série B, mas, quando você começa a crescer e alcançar as massas, como a Ramp, precisa de uma maneira mais eficiente. Não dá para continuar contratando pessoas. Você vai ficar limitado pela escala. Aí entram os agents de navegador. E agora,

03:08 mais uma vez, somos grandes usuários da Ramp. Reservei meu voo para esta conferência usando meu cartão Ramp. Logo depois que reservei o voo com esse cartão Ramp, a Ramp inicia um agent de navegador. Esse agent de navegador acessa o site da Delta. Faz login. Captura o recibo e o associa à transação. Então, depois de fazer isso, está tudo certo, mas, quando você faz isso em grande escala, vai encontrar coisas como mecanismos antibot. Então, como reduzir esse atrito? Como evitar ser bloqueado?

03:40 >> Para entender isso, quero voltar a como o navegador funciona no seu laptop. Pensem no Chromium ou no Safari, ou no Dear. O Chromium permite acessar a web. É um binário executável. E, neste slide, podemos ver que estamos reservando um voo para Nova York. Em segundo plano, seu navegador tem uma impressão digital completa. Ele sabe qual é a versão do navegador, ah,

04:12 o sistema operacional, as fontes, o tamanho da tela e até o fuso horário. O site também vê um visitante conhecido. Talvez você já tenha visitado o site, talvez tenha alguns cookies. Você já fez login ou reservou viagens demais na mesma conta. Também há um padrão conhecido. Cada solicitação passa pela rede. Você tem uma reputação de rede. E, em toda a navegação, é evidente que você é uma pessoa. E agora o problema aparece quando você tenta colocar essa mesma versão do Chromium

04:42 em um data center. É aí que escalamos para além do laptop. Precisamos replicá-lo. Empresas como a Ramp não vão deixar milhares de laptops ligados, executando uma versão diferente do Chromium para cada pessoa. Também não vão ter uma pessoa com um cron job executando isso. Precisam de uma infraestrutura escalável que permita acessar sites de forma confiável. Mas os problemas começam a aparecer quando colocamos esse mesmo Chromium no data center. Ah, digamos que façamos isso.

05:13 Digamos que já o tenhamos colocado lá. O problema agora é que, quando iniciamos um navegador chamado “headless”, essa instância sem interface gráfica em algum lugar na EC2, toda vez que a iniciamos, ela terá uma impressão digital diferente. Terá cookies novos. Talvez seja preciso fazer login novamente. E os proxies vão deixar claro que você está vindo de um data center, e não de um IP residencial. E claro, você poderia enganar o site

05:44 usando um serviço de proxy e trocando de proxy. Isso significa que talvez apareçam menos captchas ou que você possa falsificar sua localização a partir desse data center, mas isso não resolve os problemas fundamentais do Chromium. Você está usando o mesmo Chromium que usa em um laptop. E, se descermos um nível e formos um pouco mais a fundo, pensando no que torna o Chromium tão bom, se olharmos para o processo do navegador, certo? Dentro dele, há um mecanismo de página.

06:14 Esta é uma versão bastante simplificada. É onde o conteúdo é renderizado e onde ficam todo o HTML e o JavaScript. Depois, há a rede e, se vocês já inspecionaram isso antes, podem abrir a aba de rede e ver todas as solicitações entrando e saindo. E há o dispositivo e os gráficos. O mecanismo é tão bom que eles podem fazer uma mudança a cada duas semanas, o que é péssimo para nós, como empresa que tenta automatizar a web. Então, fizemos um fork. E eu poderia falar para sempre sobre quantas mudanças fizemos no binário do Chromium.

06:46 Ah, mas fizemos um fork e criamos um navegador verificado que executamos no data center. E as três coisas que fizemos e que vou compartilhar agora são: primeiro, removemos a flag de automação. Uma escolha óbvia, certo? Quando você controla um navegador sem interface gráfica por meio de automação, passa webdriver igual a true, e nós simplesmente trocamos isso para false em todos os lugares. Depois, alinhamos a identidade. Em vez de agora ser chamado de Chrome sem interface gráfica, passamos a chamá-lo de Chrome. Isso pode parecer uma solução simples, mas, por causa de como

07:17 o Chromium é complicado, isso vai fundo no código e está em tantos lugares diferentes que precisamos encontrar. A cada duas semanas há uma nova mudança. É por isso que temos nossa própria versão. Também mantemos o processo ativo. O que quero dizer com isso é que muitos trabalhos de scraping, automação ou workflows que as pessoas executam localmente como desenvolvedores, ou mesmo na infraestrutura hospedada, começam e param. Elas encerram o navegador e matam o Chromium assim que a tarefa termina. Em vez disso, deixamos o Chromium em execução e fechamos as janelas.

07:49 Então, por que não colocar isso à prova? Temos um trecho de código aqui e vou perguntar ao Aric: podemos iniciar um navegador? Certo. E lembrem-se de que o Wi-Fi está péssimo hoje. Então, o início vai levar um segundo para renderizar, e agora estamos vendo um iframe com a visualização ao vivo de um navegador hospedado no BrowserStack. Ótimo. Podemos ir para Roma. Certo, nada de especial. Vamos parar isso. E passar para o próximo slide.

08:20 Por que não iniciamos 100 navegadores? Fazemos exatamente a mesma coisa, mas vamos iniciá-los simultaneamente. Certo. Vamos para o próximo slide. Agora, o que vai acontecer em segundo plano é que estou chamando a mesma coisa com vários sites diferentes, e você vai poder, Aric, percorrer alguns dos sites. Não estamos automatizando neste momento. Estamos apenas acessando os sites com 100 navegadores. Agora vou tentar uma coisa durante o próximo minuto. Preparei isso muito rapidamente, e o

08:51 o Wi-Fi está meio ruim. E tudo passa por um portal Engrok no meu laptop. Então, se não funcionar, seguimos em frente. Quero que todos escaneiem este código QR e vocês receberão um site aleatório dentre esses 100. Alguém me diga se consegue ver um navegador. Estou tentando provar para vocês que esses navegadores estão na nossa nuvem e que vocês têm acesso a eles. Alguém avise quando carregar. >> Tomara que os deuses das demonstrações estejam do nosso lado.

09:22 >> Sim, você está vendo um navegador? Incrível. Sim? Tem outro? Ótimo. Legal. Muito bom. Dá para interagir com ele também. Pelo iframe, você pode clicar, controlar, mover e fazer coisas. E isso me leva à próxima coisa. Vou parar isso agora. Obrigado, Eric. Vamos à próxima coisa: controle. Como controlamos esses navegadores? >> E, resumindo, a Ramp agora pode implantar milhares de agents de navegador. Eles

09:53 já economizaram mais de 30 mil horas de trabalho manual de entrada de dados, que antes era feito por pessoas e agora é feito por agents, e a escala aumentou 5 vezes. Então, apenas trocando pessoas por agents, conseguiram acelerar os negócios e economizar muitas horas, que agora podem dedicar a outras iniciativas na Ramp. Quando falamos da Bill, vimos a escala e o acesso da Ramp. Agora, o foco é o controle. Todo mundo conhece a Bill. A Bill processa muitos pagamentos para milhares de diferentes

10:23 fornecedores. Quando pensamos em usar agents para fazer isso, o maior desafio é que cada portal… Próximo slide, por favor. Cada portal é diferente. O fluxo de checkout é diferente. O processo para preencher o pagamento é diferente. A interface muda. Então, na prática, a Bill considera impossível automatizar isso com agents. Por isso precisamos de uma equipe de pessoas para acessar os portais clicando e fazer isso em nome dos nossos clientes. E, mais uma vez, a resposta é um agent capaz de usar um navegador.

10:55 Para a Bill, a ideia era: como podemos criar um único agent capaz de interagir com milhares de portais diferentes e realizar ações neles? Um agent, milhares de portais diferentes. >> Isso nos leva ao Stage Hand. Stage Hand é nosso SDK open source que permite controlar um navegador. Pense no Playwright, mas construído sobre uma camada muito mais robusta. >> [fungada] >> Seu agent vai usar o Stage Hand para controlar o navegador. Vou mostrar um pouco como isso funciona. Vamos para o

11:25 próximo slide. Quero começar entendendo de novo o que há de errado com o Playwright. O Playwright é ótimo. Aprendi a programar usando Selenium e Beautiful Soup e escrevendo scripts de Playwright à mão. Isso foi antes da IA. Agora, nem me lembro da última vez que programei. Então, o problema do Playwright é que, assim que o site muda, o botão muda de lugar, a caixa de texto muda, por exemplo, de “primeiro nome” para apenas “nome”. Lá nos bastidores, quando você procura aquele XPath no Playwright ou tenta clicar em um elemento ou seletor, seu script também vai quebrar.

11:55 E tudo bem se você estiver fazendo tarefas pontuais e executando tudo localmente, mas, quando tenta escalar como uma empresa como a Ramp ou a Bill, precisa de confiabilidade em todas as ocasiões. Criamos o Stage Hand porque queríamos dar aos agents a capacidade de navegar pela web e controlá-los. Próximo slide.

12:25 Então, como ele sabe, de fato? O que é diferente? Bem, se você usar… Desculpe. O que é diferente? O Stage Hand funciona, em alguns aspectos, de modo um pouco parecido com o Playwright. Você pode usar regras determinísticas e chamar page.click ou qualquer outro comando que encontraria em um script de Playwright. Mas, quando fica um pouco mais complexo, você pode enviar prompts em linguagem natural para executar ações no site. Em vez de page.click, use page.act: preencha este formulário, ou digite meu nome, ou digite a senha, encontre o botão vermelho.

12:55 Então, o Stage Hand consegue pegar o DOM, a árvore de acessibilidade e tudo o que vê no site, passar isso para um LLM, para um agent, e entender onde clicar e clicar ali. Talvez você esteja pensando que isso pode ficar caro, mas é aí que entram nossos excelentes engenheiros por trás do Stage Hand. E, para demonstrar isso rapidamente, Eric, você poderia clicar no botão de comparação?

13:27 Se você usasse um agent com o Playwright, enviaria tudo o que está à esquerda. Isso dá 122 mil tokens. E é HTML bruto. Aí você pergunta ao agent: “Onde clico? Para onde vou?”. Antes de enviar isso ao agent, o Stage Hand reduz o DOM a uma árvore de acessibilidade bem legal, na qual enviamos apenas cerca de 4 mil tokens para este mesmo exemplo. E ele fornece seletores diretos. Então, o Stage Hand diz: “Clique aí”. Isso economiza muito dinheiro na quantidade de tokens enviados, mas também reduz o

13:58 contexto e produz resultados mais rápidos. E, se avançarmos, outro motivo para usarmos o Stage Hand com o Browserbase é que há menos… Há menos viagens de ida e volta. Digamos que estejamos controlando um navegador em um data center. Precisamos nos comunicar com ele. Enviamos o HTML de um lado para o outro o tempo todo. O que fazemos no Browserbase é colocar o Stage Hand junto ao navegador. Isso significa que o Stage Hand é uma extensão do Chrome em um navegador hospedado. Assim, essas ações ficam muito

14:28 mais rápidas, e não há latência de ida e volta para essas ações nem para as instruções do agent sobre onde clicar e para onde ir em seguida. Então, quando juntamos essas duas coisas, os navegadores oferecem escala, o Stage Hand oferece controle, e vamos mostrar um exemplo que usa os dois. >> Este é nosso último exemplo. No caso da Ramp, vimos que os agents de navegador resolvem o problema de escala e de acesso a sites muito

14:59 protegidos. No caso da Bill, era automação adaptativa. Como os agents de navegador podem permitir que você interaja com milhares de portais diferentes sem precisar gerenciar milhares de scripts diferentes de Playwright. Agora, com a Stripe, todo mundo nesta sala conhece a Stripe. A Stripe integra milhares, dezenas de milhares de comerciantes mensalmente, trimestralmente, trimestralmente e anualmente. E, mais uma vez, eles sabiam que a única forma de acessar as informações para verificar se essas empresas eram reais e se eram as empresas certas para fazer negócios era por meio de um

15:31 navegador. E isso foi antes da era dos agents de navegador. Então, eles tinham uma equipe de pessoas acessando os portais da Secretaria de Estado e usando o navegador para obter essas informações. Assim, uma mudança rápida é poder usar o agent de navegador para automatizar essa verificação KYC. >> Vamos nos aprofundar um pouco mais no Stage Hand. Em vez de usar um agent direto, como a Bill, você poderia usar act, extract e observe. Essas

16:02 [fungada] são três primitivas principais que o Stage Hand oferece a você como desenvolvedor. Uma delas é observe: encontre o botão “saiba mais”. Isso é executar uma ação. Próximo slide. Act: clique no botão de login. Próximo slide. E então extract. Esta é minha favorita, porque você pode extrair qualquer coisa para um schema Zod, o que é ótimo para engenheiros, porque pegamos dados muito desorganizados e não estruturados da web, convertemos em dados fáceis de usar e ler e os enviamos

16:32 para um agent. Próximo slide. Agora vou mostrar mais algumas demonstrações. Vamos começar pelo site de uma empresa e acessar o Chipotle para descobrir o que vende usando o Stage Hand. E vamos ao próximo slide. Certo. Este navegador vai iniciar em um navegador hospedado e abrir a página; vai usar o extract do Stage Hand para extrair as informações. E pronto. Temos o Chipotle Mexican Grill. Está vendendo chips com limão. Legal.

17:03 Se apertarmos em parar… Agora é que a coisa vai ficar divertida. Vamos para o próximo. Agora, vamos pesquisar quatro fontes diferentes sobre a Chipotle. Vamos acessar o site deles, a página de investidores, o documento enviado à SEC e a listagem na Bolsa de Valores de Nova York. Certo? Então, está rodando e, tudo bem, você também pode rolar a página quando elas carregarem. Certo, ótimo. Temos o documento da SEC lá embaixo, e temos a Bolsa de Valores de Nova York, e, lá em cima, acho que temos o site

17:34 que vai aparecer daqui a pouco. Mas lá está: eles também têm relações com investidores. Então, isso está acontecendo mais rápido do que aparece na tela. Isso já está acontecendo nos bastidores. O que está sendo transmitido de volta para nós é apenas a visualização ao vivo. E, obviamente, quando você está executando tantos navegadores em escala, nem sempre vai ficar conferindo a visualização ao vivo. Isso serve mais para desenvolvimento. Certo, legal. Vamos parar isso. E vamos para o próximo. Agora, vamos fazer 20 empresas nas mesmas três fontes. E vamos clicar em executar. E lembrem-se: é o mesmo código que está sendo executado em todos os sites.

18:06 Depois, vamos para o próximo slide. E podemos ver a Chipotle aparecendo no topo. Agora fiquei com fome. JPMorgan. Lá está. Certo, continue rolando. Vamos ver o que mais tem. Goldman Sachs. Fazendo as mesmas tarefas em todos os sites, sem interrupções, sem bloqueios, usando Stage Hand também. E isso é muito legal, porque é um navegador verificado, como mencionei logo no começo, o que significa que você não se depara com tantos CAPTCHAs. E, se acontecer, nós

18:36 os resolvemos. E o Stage Hand nos permite navegar sem que ninguém fique olhando. Certo? E podemos parar por aí. Acho que dá para ver alguns resultados do lado direito. Próximo slide. Certo, legal. Temos alguns resultados aqui. Dados do documento enviado à SEC. Continue rolando. Sinceramente, não faço ideia do que significam essas coisas da SEC. Não sou do ramo financeiro. Mas espero que seja útil. Legal. Vamos para o próximo slide. E aquele modelo para a SEC foi

19:08 algo que criei há algum tempo. Se quiser acessar especificamente aquele modelo da SEC, você pode. Mas também temos, se quiser começar a trabalhar com algo baseado em navegador ou com qualquer coisa que mostrei, temos, no nosso site, um prompt que você pode copiar; basta enviá-lo ao seu agent, e ele fará boa parte do trabalho também. Próximo slide. Certo. Muito obrigado. Essa foi a nossa apresentação. >> [aplausos]

Transcrição original

[00:01] [music] >> Hello. Hello everyone. We are here to talk about how to build financial agents that work across the entire web. I hope you’ve been having a great day so far in New York. I am Jay. >> I’m Amarik and I think the place to start is what even is a browser agent,

[00:32] right? So if we think about it and first if we want to go back to the previous slide, quick show of hands, who is building agents today? Show of hands. Okay, we’re in the right place. >> And who works on like finance operations? I heard about some conference going on today. Anyone in finance? Okay, couple more engineers. If you also want to ask us any questions throughout, you can scan this QR code and you’ll be able to ask away. >> Cool. Back to the show. So what is a browser agent? An a browser agent if you

[01:04] think about it, if an agent needs to access the web, interact with the web, read information from the web, take action on the web, it needs a browser. Whether it is booking a plane ticket, booking a flight, planning a date night for you and your wife, getting some pricing information on a competitor, it typically needs a browser to be able to access those hardest to reach sites that don’t have an API or don’t have an MCP. And so in a nutshell, anything that you need to do on the web, your agent should have the tool called the browser.

[01:37] Show of hands, who knows these three companies? Ramp, Bill, Stripe. They familiar with the crowd? Cool. When you think about what these three companies have in common, well first they’re all financial institutions, they’re dealing with highly sensitive information, but when you think about it for like Ramp, Bill, and Stripe, a lot of this information lives on the hardest to reach parts of the web, whether that is behind a portal where you need to log in, whether it’s on a website that is heavily protected by antibot. It is extremely challenging to get access to

[02:07] this information, and the answer is using browser agents. So, if we want to start off, we’ll go with Ramp first. So, Ramp, I’m sure everyone in this room is familiar with Ramp. We actually are big users and fans of Ramp. Uh they make it incredibly easy to for a company to manage spend. When they were growing and scaling, they started having to interact with hardest to reach portals, and more portals than than ever before. And so, the problem or the gap was, how can we

[02:38] fetch these receipts efficiently at scale? They didn’t know about the browser agent. So, instead, they’re like, let’s just put together a team of humans, and they will log onto these portals, and they’ll go fetch these receipts. Well, that can that can be good for a series A, series B company, but when you start growing and scaling to the to the masses that uh Ramp is at, you need a more efficient way. You can’t continue to hire humans. You’re just going to be bottlenecked by the limitation of scale. So, in comes browser agents. And now,

[03:08] again, we are big users of Ramp. I booked my flight to this conference using my Ramp card. Immediately after booking my flight on that Ramp card, Ramp spins up a browser agent. That browser agent goes to Delta. It logs in. It captures that receipt, and it matches it to the transaction. Um so, once they do that, that’s that’s all good and dandy, but when you’re doing it at scale, you’re going to run into things like antibot. So, how do you reduce that friction? How do you eliminate getting blocked?

[03:40] >> And to understand this, I really want to go back to how does the browser work on your laptop? Think about Chromium or Safari or dear. Chromium allows you to access the web. It’s an executable binary. And right now from this slide we can see that we are booking a flight to New York. And in the background, your browser has an entire fingerprint. It knows your browser version, uh

[04:12] there’s OS, there’s fonts, there’s screen size, and even time zone. The website also sees a familiar visitor. Maybe you visit the site before, maybe you’ve got some cookies. You’ve logged in or you’ve booked too many trips on the same account. There’s a familiar pattern as well. Each request will go through a net You’ve got a network reputation. And all the navigation, you are clearly a human. And now the problem comes when you try and put that same version of Chromium

[04:42] into a data center. And that’s when we scale beyond the laptop. We need to replicate it. For companies like Ramp, they are not going to have thousands of laptops open running a different human version of Chromium. They’re not going to have one person with a cron job running this either. They need scaled infra that lets them get to sites reliably. The problems start to appear though when you put that same Chromium in the data center. Um let’s say we do this.

[05:13] Let’s say we’ve put that in. The problem now is when we launch a called out browser, that headless browser in an an an EC2 instance somewhere. Every single time we launch it, it’s going to have a different fingerprint. It’s going to have fresh cookies. You may need to log in again. And proxies. It’s going to clear indicator that you are coming from a data center instead of a residential IP. And sure, you could trick the website by

[05:44] using a proxy service and changing your proxy. And that means is you might not be presented as many captures or you can fake your location from that data center, but that still doesn’t change the underlying problems with Chromium. You’re using that same Chromium on a laptop. And if we just step one step down and go a little bit deeper and think about what makes Chromium so good is if you look at the browser process, right? Inside you have a page engine.

[06:14] This is a very simplified version. And where it renders the content and it has all the HTML, JavaScript. Um then you have your network and if you ever like inspected before you go on a network tab and you can see all the requests coming in and out. And you have your device and graphics. The engine is so great that they can make a change every 2 weeks, which makes it terrible for us as a company trying to automate the web. So we forked it. And I could go on forever on how many changes we made to the Chromium binary.

[06:46] Um but we forked it and came up with a verified browser that we run in the data center. And what we did with three things I’m going to share now is we first removed the automation flag. An obvious one, right? When you’re driving a headless browser um through an automation, you will pass this webdriver equals to true and we just swap that to false everywhere. Then we aligned on the identity. Instead of now being called headless Chrome, we’re calling it Chrome. Now these may seem like simple fixes, but because how

[07:17] complicated Chromium is, this goes deep into the code and it’s in so many different places that we need to find. And every 2 weeks is a new change. That’s why we have our own version. We also [clears throat] keep the process alive. What I mean by that is a lot of scraping jobs or automation jobs or workflows that people are doing as developers locally or even in the hosted infra will start and stop. They kill the browser and they kill a Chromium instantly as soon as the task is done. Instead, we leave chromium running and close the windows out.

[07:49] So, why don’t we put it to the test? We’ve got a snippet here and I’m going to ask Aric, can we launch a browser? Okay. And bear in mind the Wi-Fi has been terrible today. So, it’s launch is going to take a second to render and we are now looking at an iframe of a live view of a hosted browser on BrowserStack. That’s great. We can go to Rome. Okay, nothing special. Let’s stop that. And let’s go to the next slide.

[08:20] Why don’t we launch 100 browsers? Do the exact same thing but we’ll launch them concurrently. Okay. And to the next slide. Um now what’s going to happen in the background is I’m calling the same thing with a bunch of different websites and you will be able to Aric scroll through the um some of the sites and we’re not automating at the moment. We’re just going and visiting the sites as 100 browsers. Now I’m going to try something for the next minute. Um I set this up very quickly and the

[08:51] Wi-Fi is a little sucks a little bit. And it’s all through an Engrok portal on my laptop. So, if it doesn’t work, uh we’ll move on. Um I want everyone to scan this QR code and you will be given a random website out of one of these 100. Um someone tell me if they can see a browser. I’m trying to prove to you that these browsers in our cloud and you have access. Someone shout out when they’re when it’s loaded. >> Hopefully the demo gods are with us.

[09:22] >> Yeah, you got a browser? Awesome. Yeah? Got another one? Great. Cool. Sweet. Nice. You can actually interact with this as well. Um through the iframe you can click, control, move and do things. And that takes me on to the next thing. I’m going to uh stop that now. Thanks, Eric. Um Um let’s take me on to the next thing is control. How do we control these browsers? >> And just to sum this up, Ramp now can deploy thousands of browser agents. They

[09:53] have saved north of 30,000 manual hours in data entry that is done that used to be done by humans that is now done by agents, and their scale has gone up 5x. So, just by switching from humans to agents, they were able to accelerate their business and save a bunch of those hours, which now they can dedicate to other initiatives across Ramp. When we talk about Bill, so Ramp scale and access. Now, it’s about control. Everyone’s familiar with Bill. Um Bill, you know, processes a ton of payments across thousands of different

[10:23] vendors. When you think about using agents to do that, the biggest challenge is well, every portal Next slide, please. Every portal is different. The checkout flow is different. The process to fill out the payment is different. The UI changes. So, in reality, the way Bill thinks about this is it’s impossible to automate with agents. That’s why we need a team of humans to go click through portals and do this on behalf of our customers. Um and again, the answer to this is an agent that can use a browser.

[10:55] Um and so, for Bill, the notion was how can we build a single agent that can interact and act upon thousands of different portals. One agent, thousands of different portals. >> Um that brings us to Stage Hand. Stage Hand is our open-source SDK that lets you control a browser. Think about Playwright, but built way on top of it. >> [snorts] >> Your agent will sit and use Stage Hand to control the browser. I’m going to show you a little bit how. Go to the

[11:25] next slide. I want to start with understanding again what is wrong with Playwright. Playwright’s great. I first learned how to code by using Selenium and beautiful soup and writing Playwright scripts by hand. This was before AI. Now, I can’t remember last time I coded. And so, with Playwright, what the problem is is as soon as that website changes, the button moves, the text box changes like from first

[11:55] name to just name. In the in the back, like when you’re looking for that XPath in Playwright or you’re trying to click on an element or a selector, your script’s also going to break. And now, that’s fine if you’re doing one-off tasks and you’re running everything locally, but when you try to scale like a company like Ramp or Bill, you need reliability every single time. The reason we like built Stage Hand was because we wanted to give the ability to agents to navigate the web and control them. Next slide.

[12:25] So, how does it actually know? What’s different? Well, if you play play Sorry. What’s different? So, Stage Hand actually works a little bit like Playwright in some sense. You can use deterministic rules and go page.click or everything you’d see in a Playwright script. But, when it gets a little bit more complex, you can actually send natural language prompts to go and do actions on the site. Pay page.click or page.act, go fill out

[12:55] this form, or enter my name, or enter password, find the red button. Stage Hand will then be able to take the DOM and accessibility tree and everything it sees on the website, pass it to an LM, pass it to an agent, and understand where to click and go and click it. Now, you may be thinking it might get expensive, but that’s where we have our excellent engineers behind Stage Hand. And to demonstrate this quickly, Eric, if you could hit that compare button.

[13:27] If you were to use an agent with playwright, you’d be sending everything on the left. Uh, that’s 122k tokens. And that’s a raw HTML. And you ask your agent, “Where do I click? Where do I go to?” What Stage Hand does before it hits that agent is it shrinks the DOM to a really cool accessibility tree, where we’re only sending like 4,000 tokens for this same example. And it’ll give direct selectors. So, Stage Hand will go, “Click that.” Save a lot of money on um the amount of tokens that you’re sending, but also reduce the

[13:58] context and get quicker results. And if we go next, another reason why we use um Stage Hand and with Browser Base is because there’s fewer net There’s fewer round trips. Let’s say we are currently controlling a browser in a data center. We’ve got to talk back. We send the HTML back and forth every single time. What we do at Browser Base is we put Stage Hand next to the browser. And that What that means is Stage Hand is a Chrome extension on a hosted browser. So, those actions become a whole lot

[14:28] quicker, and there’s no round trip latency from those actions and those like instructions from the agent of where to click and where to go next. And so, when you bring these two things together, you need scale from the browsers, Stage Hand gives you the control, and we’re going to show you an example that use both. >> This is our last example. So, with Ramp, we saw that browser agents solve the issue of scale and access to heavily

[14:59] protected sites. With Bill, it was adaptive automation. How can browser agents enable you to interact with thousands of of different portals with ha- without having to manage thousands of different playwright scripts. Now, with Stripe, everyone’s familiar with Stripe in this room. Stripe onboards thousands, tens of thousands of merchants on a monthly, quarterly, quarterly, yearly basis. And again, they knew that the only way to access the information to verify that these businesses were real and they were the right business to work with is through a

[15:31] browser. And this was before the age of browser agents. So, they had a team of humans going on and going to Secretary of State portals and using the browser to get that information. So, a quick switch is being able to use the browser agent to go and automate this KYC verification. >> Um let’s dig a bit more into Stage Hand here. Um so, we have instead of using a direct agent like Bill, you could use act, extract, and observe. Those

[16:02] [snorts] are three key primitives that Stage Hand we give we expose to you as developer. Um one is observe, find the learn more button. Um this is taking action. Next slide. Act, click the login button. Next slide. And then the extract. Now, this is my favorite one because you can extract anything into a Zod schema, which is great for engineers because we’re taking really messy unstructured data on the web and converting it to a really easy-to-use data and readable and send

[16:32] it to an agent. Next slide. Now, I’m going to show a couple more demos. We’re going to start with one company website and we’re going to go to Chipotle and find out what it sells using Stage Hand. Um and next slide then. Okay. So, this browser will now spin up on a hosted browser and browse page and it’s going to use Stage Hand um extract to extract it. And there we go. We’ve got Chipotle Mexican Grill. Um it’s selling some lime chips. Cool.

[17:03] Uh if we press stop. Now, this is where it’s going to get fun. Let’s go for the next one. And now we’re going to research four different sources for Chipotle. We’re going to go to their website, investor page, SEC filing, and New York Stock Exchange listing. Okay? So, we’re running and all right, you can also scroll once they load. Okay, great. So, we’ve got the SEC filing down at the bottom, and we’ve got New York Stock Exchange, and up top I think we’ve got the website

[17:34] that will appear in a second. But, there we go, they got investor relations, as well. So, these are actually happening quicker than they are on the screen. This is already being happened in in the back. It’s just the live view that’s streaming back to us. And obviously, when you’re running so many browsers at scale, you’re not always going to be checking the live view. This is more for development. Okay, cool. Let’s stop that. And let’s go to the next one. Now, we’re going to do 20 companies for the same three sources. And we’re going to hit run. And bear in mind, this is the same code that’s running on every single website.

[18:06] Then, we go to the next slide. And we can see Chipotle will come up at the top. I’m getting hungry now. Um JP Morgan. Um there we go. All right, keep on scrolling. Let’s see what else is there. Golden Sachs. Going and doing the same tasks across every single site without interruption, unblocked, all using Stage Hand as well. And it’s really cool cuz it’s a verified browser that I mentioned at the very start, which means that you don’t get hit with as many CAPTCHAs. And if you do, we

[18:36] solve them. And the Stage Hand allows us to navigate without anyone looking at this. Okay? And we can stop there. And I think we can see some results on the right-hand side. Um next slide. Okay, cool. We’ve got some of the results here. Um SEC filing data. Keep on scrolling. I honestly have no idea what the SEC stuff means. I’m not a finance guy. But, hopefully it’s useful. Cool. Um let’s go to the next slide. And so, that SEC template I was

[19:08] something I built a while ago. If you want access to that particular, just the SEC one, you can do. Um, but we also have if you want to get started with anything browser-based or anything I showed, we have if you go to our website, we have a copy prompt which you just send it to your agent and that’ll do a lot of the work as well. Uh, next slide. Okay. Thank you so much. That’s our talk. >> [applause]