Por que agents de navegador com 99% de precisão ainda falham — Derek Meegan, 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: Why 99% Accurate Browser Agents Still Fail — Derek Meegan, Browserbase · Canal: AI Engineer · 16:46 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Derek Meegan explica por que uma demo bem-sucedida de browser agent não garante resultados confiáveis em produção: custos e riscos se acumulam a cada etapa, enquanto o valor só aparece quando a tarefa inteira é concluída. Ele mostra como medir o sucesso por transação, permitindo retries, e recomenda avaliar performance, custo e manutenção. No exemplo de um portal de seguro-saúde, o sistema melhora ao transformar operações complexas em ferramentas determinísticas, reutilizar a autenticação e orientar o agent com uma skill. Assim, o modelo se concentra apenas nas partes ambíguas, reduzindo falhas e custos de manutenção.

Pontos-chave

Uma execução bem-sucedida em uma demo não representa milhares de execuções sem supervisão em produção.
Agents interagem com o navegador por representações textuais, screenshots ou ambientes de execução dinâmica de código.
Em tarefas transacionais, cada etapa adiciona custo e risco, mas o valor só é obtido quando a tarefa inteira termina.
Uma taxa de sucesso de 99% por etapa pode resultar em apenas cerca de 36% de sucesso ao longo de uma trajetória de 100 etapas.
O sucesso deve ser medido por transação, não por execução isolada; retries podem elevar a taxa de conclusão.
A prioridade é garantir performance; depois, custo e manutenção podem ser tratados como problemas de otimização.
Resultados verificáveis, como um recibo ou um registro consultável, ajudam a determinar se a tarefa foi concluída.
Ferramentas determinísticas podem encapsular operações complexas e verificar resultados sem depender das decisões do modelo.
Reutilizar a autenticação e fornecer uma skill com o caminho crítico reduz etapas e ambiguidades para o agent.

Capítulos

Início	Capítulo	Resumo
00:00	Da demo à produção	A palestra apresenta a diferença entre uma execução supervisionada em um site e milhares de execuções em produção.
01:03	Como agents interagem com a web	O palestrante descreve as camadas do navegador e as principais estratégias para representar páginas e executar ações.
04:11	O desafio das tarefas transacionais	Custos e riscos crescem a cada etapa, mas o valor só é realizado quando toda a trajetória termina.
06:17	Como medir valor e confiabilidade	A conversa aborda lucro, resultados verificáveis, retries e as dimensões de performance, custo e manutenção.
10:59	Fatores de risco e arquitetura para produção	O exemplo de um portal de seguro-saúde mostra como ferramentas determinísticas, autenticação reutilizável e uma skill melhoram o desempenho e a manutenção.
16:11	Conclusão: bem-vindo à produção	O palestrante conclui que retirar do agent etapas que não exigem julgamento reduz responsabilidades e ajuda a superar os desafios de confiabilidade.

Citações

O custo se acumula continuamente, enquanto a realização de valor é terminal. — 04:41

Se cada etapa tem uma taxa de sucesso independente de 99%, uma trajetória de 100 etapas chega a cerca de 36% de sucesso. — 05:13

O cliente não se importa necessariamente com quantas tentativas você faz, mas com a conclusão confiável do fluxo de trabalho. — 08:54

Retiramos da responsabilidade do modelo as etapas que simplesmente não precisam estar sob a responsabilidade do agent. — 16:11

Conceitos e entidades

Derek Meegan (pessoa): Engenheiro de software da Browserbase e palestrante sobre a implantação de browser agents em produção.
Browserbase (empresa): Empresa que ajuda clientes a implantar automações de navegador para seus usuários.
browser agent (conceito): Sistema que usa um agent para realizar tarefas interagindo com páginas e funções de um navegador.
DOM (conceito): Representação estrutural da página, baseada no HTML, que pode ser usada para descrever o conteúdo do navegador.
accessibility tree (conceito): Representação textual semântica da página e de seu estado, voltada à acessibilidade.
Computer Use (conceito): Abordagem em que o navegador é representado por uma sequência de screenshots da página.
CDP (ferramenta): Protocolo mencionado como uma forma de interagir com o navegador por meio de execução dinâmica de código.
OCR (conceito): Técnica usada no exemplo para extrair entidades de um documento e compará-las com o sistema de registro.
skill (conceito): Procedimento que orienta o agent pelo caminho crítico de uma tarefa e reduz ambiguidades.
browser automation (conceito): Automação de tarefas realizadas em sites por meio de um navegador.

Tradução completa (pt-BR)

00:00 Muito bem. Implantar agents de navegador. Fazer uma demonstração de um agent de navegador uma vez é fácil. É em um único site. É uma única execução em um dia bom, com você observando e torcendo para dar certo. Mas sabemos

00:32 que a produção é muito diferente. São milhares de execuções sem supervisão, enquanto o site pode mudar ou o seu modelo pode simplesmente ter um dia ruim. É por isso que estamos aqui. O que separa uma demonstração da produção? Meu nome é Derek Megan. Sou engenheiro de software na Browserbase. Hoje, vamos dividir esta palestra em quatro partes. Primeiro, vamos pôr ordem no caos e entender concretamente como os agents interagem com a web. Segundo, vamos

01:03 definir o impossível e explorar por que executá-los em escala é tão difícil. Terceiro, vamos dar um passo atrás. Vamos pensar no que é importante e na proposta de valor que os agents oferecem. E, por último — que espero ser o motivo pelo qual estamos todos aqui —, vamos gerar valor para os acionistas. Então, primeiro, como os agents interagem com a web. Gosto de pensar na saída de um modelo como uma distribuição de probabilidade. Você recebe tokens de entrada. Eles representam o

01:35 estado da página, o objetivo geral ou as etapas que já foram executadas. Então, o modelo explora uma distribuição de ações possíveis e propõe a mais provável. Em seguida, essa ação é convertida em uma chamada de ferramenta estruturada e executada de forma determinística para interagir com o navegador. Mas a interface do navegador é complexa. Há várias camadas distintas. Há requisições entrando e saindo do navegador. Há o Document Object Model, ou a representação HTML da página. Você pode fazer uma captura de tela do navegador. Há a árvore de acessibilidade, que é uma representação textual semântica da página, e o armazenamento do estado do navegador: cookies, console, URL, abas etc. Por baixo de tudo isso, há um ambiente de execução de código dinâmico, no qual você pode interagir com o navegador escrevendo código arbitrário em JavaScript ou usando CDP.

02:05 Como conectar tudo isso? Normalmente, no setor, há três estratégias principais.

02:36 A número um é criar uma representação textual do navegador. Isso normalmente envolve usar o estado HTML da página e a árvore de acessibilidade para criar uma representação híbrida. A número dois é o uso do computador, em que o navegador é representado por uma série de capturas de tela da página. Por fim, e cada vez mais popular, está remover o harness do agent, substituindo ferramentas feitas sob medida por ambientes de execução dinâmicos nos quais o agent pode escrever código arbitrário para interagir com o navegador.

03:08 Na prática, a maioria dos sistemas em produção se apoia na primeira estratégia, na segunda ou numa combinação das duas. Agora, vamos pensar nos tipos de trajetórias de agents no navegador. Aqui, defino três, distribuídas ao longo de um espectro de autonomia do agent. No extremo de menor autonomia, temos trajetórias de navegador criadas para fins específicos, feitas especialmente para concluir uma única tarefa. No extremo de maior autonomia, temos automações de navegador criadas

03:38 sob demanda, em que não sabemos de antemão qual é a tarefa e o usuário nos fornece uma tarefa arbitrária para concluir. No meio, temos algo entre as duas. Usamos o navegador como um detalhe de implementação para atingir um objetivo maior, como fazer uma pesquisa aprofundada ou uma análise de concorrentes. Em escala, quero mesmo me concentrar nesses workflows transacionais. Não porque isso torne as coisas fáceis, mas porque é o que normalmente vemos em escala. Esses workflows são transacionais por natureza,

04:11 pois queremos concluir uma unidade de trabalho de ponta a ponta. Por outro lado, os agents de navegador nos oferecem um ambiente de execução flexível para lidar com a ambiguidade em produção. Então, sabemos como os agents interagem com a web, quais tipos diferentes de trajetórias podemos encontrar e estamos nos concentrando especificamente em workflows transacionais. Por que isso é tão difícil em produção? Acho que tudo se resume a uma interação fundamental.

04:41 A acumulação de custos é contínua, enquanto a realização de valor ocorre apenas no final. A cada etapa da trajetória, você incorre em um custo incremental. Além disso, incorre em um risco incremental de falha. No entanto, só recebo valor dessa trajetória no navegador quando todas as etapas da tarefa são concluídas. Isso quer dizer que, com agents de navegador, não há crédito parcial. E a grande maioria das automações da web se enquadra nessa categoria. Então, você diz: “Tudo bem, a cada etapa

05:13 há mais risco e mais custo. Se eu usar um modelo altamente capaz, posso contornar esse dilema.” Considere este experimento mental. Você tem um agent de navegador em que cada etapa tem uma taxa de sucesso independente de 99%. Se a trajetória no navegador tiver 100 etapas, a taxa geral de sucesso em escala começa a ficar em torno de 36%, ou seja, apenas cerca de um terço das vezes. Isso não é muito bom e certamente não é assim que entregamos resultados confiáveis para

05:44 os clientes em produção. Então, você diz: “Tudo bem, estamos acumulando custos continuamente, estamos acumulando riscos continuamente e a probabilidade de realizar valor é muito baixa.” Isso sugeriria nunca usar um agent de navegador. Felizmente, esse não é o tema da minha palestra hoje. Acho que essa dinâmica é real, mas a matemática não conta a história toda. Então, é hora de dar um passo atrás. Vamos pensar no que é importante e em como os agents realmente

06:17 entregam valor. Para ilustrar o valor que gostaria que os agents entregassem, vou propor uma equação simples, talvez pouco usada por muitos de nós. E essa equação é: lucro é igual à receita menos os custos. Sim, muito simples. Mas talvez isso seja ignorado quando pensamos em agents de navegador. O que quero dizer é que seu agent é apenas mais um item na lista de custos e que ele deve lhe dar mais do que tira. Mas, quando pensamos no que seu

06:48 agent deve lhe dar, surge a pergunta: o que um agent de navegador realmente oferece? Para responder, gosto de pensar no contexto do cliente. Na Browserbase, ajudamos nossos clientes a implantar automações de navegador para os usuários deles. Muitas vezes, eles não estão automatizando a web para atender às próprias necessidades, mas realizando ações na web em nome de seus clientes. Portanto, um agent de navegador realmente oferece a conclusão repetida de uma tarefa para o seu cliente.

07:19 Pelo menos, esse é o resultado ideal. A questão é como criar um sistema dinâmico que permita obter o benefício de lidar com problemas ambíguos e, ao mesmo tempo, concluir a tarefa repetidamente, sempre que o ambiente permanecer igual. Vamos analisar três dimensões, em ordem de importância. A primeira é o desempenho. A segunda é o custo e a terceira é a manutenibilidade. E, quando pensamos em desempenho, essa é a principal medida

07:50 de sucesso na qual queremos nos concentrar. Porque, quando sabemos que um agent de navegador tem bom desempenho e consegue concluir a tarefa que pedimos, custo e manutenibilidade se tornam apenas problemas de otimização. Gosto de problemas de otimização porque podem ser resolvidos com engenharia. Então, a primeira coisa que precisamos perguntar é como é o sucesso, de fato. E, nessas trajetórias transacionais de navegador, o sucesso se manifesta como algum tipo de artefato concreto deixado pela execução. Se você está pagando uma conta, isso

08:23 pode ser um e-mail de confirmação. Se está fazendo um pedido, pode ser um ID do pedido ou um recibo. Ou, se está enviando um formulário, pode ser um novo registro em um sistema que você consegue consultar de forma determinística. Segundo, com que frequência um agent acerta? Há duas maneiras de medir isso. De forma ingênua, você pode medir o sucesso de um agent por execução. Suponha que você tenha um agent de navegador cuja probabilidade

08:54 de sucesso em qualquer execução seja de 50%. No entanto, se permitir que esse agent tente de novo para uma transação específica, talvez até quatro tentativas adicionais, a taxa de sucesso por transação sobe rapidamente para 94%. Então, ao pensar em qual métrica importa, mais uma vez, eu insistiria que nos baseássemos na perspectiva do cliente. O cliente não se importa necessariamente com quantas tentativas você faz, mas sim com o fato de o workflow ter sido concluído com sucesso e de forma confiável. Em resumo,

09:26 permita novas tentativas e meça o sucesso por transação. Em seguida, vamos explorar os custos e dividi-los em duas dimensões. A primeira é o custo por execução, que hoje é predominantemente composto pelos custos dos modelos. Mas, à medida que a engenharia avança no cenário open source de modelos, há uma enorme pressão para reduzir o preço da inteligência. E acredito que, com o tempo, o custo dos modelos se tornará uma parcela cada vez menor

09:57 de implantar trajetórias de agentes de navegador. Em seguida, vêm a infraestrutura e a computação. Quais são os recursos reais de que você precisa para executar as trajetórias do seu agente de navegador? E, por último, há a integração adicional e as ferramentas. Depois, pensamos na manutenção ao longo do tempo. Precisamos investir em observabilidade não só de como o agente tomou decisões, mas também do que realmente aconteceu no navegador. Em segundo lugar, há o tempo dos desenvolvedores. Quando algo quebra ou não está funcionando de maneira ideal, as pessoas precisam intervir e reconfigurar o

10:28 harness ou ampliar seus recursos. E, por último, vem a reavaliação. À medida que o problema muda, os sites mudam e os modelos evoluem, precisamos reavaliar nossa solução atual para que ela resista ao teste do tempo. Então, falamos sobre desempenho, falamos sobre custos unitários e também sobre facilidade de manutenção. Quais são os fatores de risco para a durabilidade disso tudo ao longo do tempo? Bem, antes de mais nada, o

10:59 ambiente pode reagir. Os sistemas antibot e, de modo geral, sabemos que a web não é o lugar mais amigável para o seu agente. Em segundo lugar, a tarefa muda. O trabalho subjacente muda sob o agente, e pedimos a ele que lide com a ambiguidade. Felizmente, isso também se beneficia do aumento da capacidade dos modelos, que conseguem entender de forma mais intuitiva a intenção do usuário e, portanto, diante de algo que dá errado, corrigir o rumo e, por fim, concluir o

11:30 objetivo. Em terceiro lugar, surgem métodos melhores, e esse é um dilema clássico da automação da web. O que acontece se eu estiver automatizando a web hoje e esse mesmo site criar uma API amanhã? Mas, para a grande maioria dos casos de uso de agentes de navegador, uma API não vai surgir tão cedo. E, por fim, o modelo se desvia da tarefa. Os modelos são inerentemente não determinísticos. Então, de uma execução para outra, talvez não sigam exatamente o caminho ideal ou o caminho crítico para

12:01 realizar a ação. Por fim, chegamos ao cerne da palestra. Como podemos gerar valor para os acionistas de forma concreta? Essa é a questão. Entendemos que, se um modelo tem bom desempenho, então custo e facilidade de manutenção são um problema de otimização. Portanto, vamos explorar isso juntos na prática. Vamos analisar uma arquitetura de alto nível de um agente de navegador para tarefas do mundo real. Essa tarefa consiste em automatizar um portal de seguro-saúde. Cada etapa que realizamos ao criar

12:34 esse sistema dinâmico deve influenciar uma dessas alavancas principais: custo, desempenho ou facilidade de manutenção. Então, primeiro, começaremos com um agente simples. O objetivo desse agente é fazer login e baixar uma explicação dos benefícios. Chega uma solicitação, o agente executa a ação no navegador, e este é o sistema mínimo necessário para simplesmente fazer algo. Em seguida, você percebe que, para baixar essa explicação dos benefícios,

13:04 é preciso interagir programaticamente com a página. E, depois de fazer o download, você precisa recuperar esse arquivo do armazenamento e trazê-lo para o ambiente de execução do agente. Então, você cria uma ferramenta que faz tudo isso em uma única transação. Em vez de o modelo precisar tomar decisões na hora, você encapsula uma operação complexa em uma única chamada de ferramenta. Em seguida, você quer dar ao agente a oportunidade de verificar seu trabalho em tempo real. Isso pode ser feito dando a ele

13:34 outra ferramenta. Essa ferramenta é uma ferramenta de OCR que extrai entidades do documento de forma determinística e as compara com o sistema de registro. Ótimo. Agora o agente sabe se realmente fez o trabalho direito ou não, porque tem um mecanismo determinístico para verificar isso. Em seguida, você percebe que, embora esse portal possa ter ambiguidades na lógica de negócios, o fluxo de autenticação nunca muda, e você quer reutilizar o

14:05 mesmo mecanismo de autenticação para várias operações de negócios no mesmo portal. Então, você tira essa lógica de autenticação das responsabilidades do modelo. Mais uma vez, estamos reduzindo o número de etapas que o agente precisa executar para concluir a tarefa com sucesso. Isso significa custos unitários menores, desempenho melhor e manutenção mais fácil, além de podermos reutilizar essa função de autenticação em vários workflows de lógica de negócios no mesmo portal. Por último,

14:37 restringimos a responsabilidade do agente apenas à área de ambiguidade necessária. Então, criamos uma skill. Essas skills se parecem muito com um procedimento operacional padrão que, no passado, usaríamos com pessoas, exceto que esse procedimento operacional padrão é para um agente e permite que ele siga o caminho crítico com mais precisão. No início da palestra, discutimos como o resultado de um agente pode ser entendido como uma distribuição de probabilidade. Então, se

15:08 apresentarmos o caminho crítico ao agente, ele saberá que está na etapa dois e que precisa executar a etapa três, porque a descrevemos nessa skill. Assim, é mais provável que ele execute essa etapa três. Ele sabe exatamente aonde precisa ir, e removemos a ambiguidade do processo de decisão do agente. No fim, este é o resultado final. Temos um sistema bastante complexo. Chega uma solicitação, uma função de autenticação sem servidor autentica o navegador. Esse navegador é disponibilizado para

15:39 o ambiente de execução do agente. O agente navega pelo portal usando a skill fornecida, chama uma função determinística de download, envia o arquivo baixado para uma ferramenta de verificação e pode saber com certeza se sua trajetória teve sucesso ou falhou. No fim, esse sistema tira das responsabilidades do modelo as etapas que simplesmente não precisam ser responsabilidade do agente. Reduzimos o número de etapas que ele precisa executar, sem deixar de alcançar o

16:11 resultado desejado. Assim, o sistema é mais fácil de manter e tem melhor desempenho, e podemos superar o dilema dos agentes de navegador. Então, aqui estamos. Bem-vindos à produção e parabéns. Agora vocês estão de plantão. Obrigado.

16:46 [música]

Transcrição original

[00:00] All >> [music] >> right. Deploying browser agents. Uh running a browser agent demo once is easy. Uh it’s on one site. It’s one run on a good day with you watching and your fingers crossed. Uh, but we know

[00:32] production is vastly different. Thousands of runs unattended while the site can change or your model can just have an off day. So that’s why we’re here. What separates a demo from production? My name is Derek Megan. I’m a software engineer at Browserbase. And today we’ll break up this talk into four parts. First, we’ll bring order to chaos, and we’ll understand concretely how agents interact with the web. Second, we’ll

[01:03] define the impossible and explore why running them at scale is so hard. Third, we’ll take a step back. We’ll think about what’s important and the value proposition that agents propose. And then last, which is hopefully the reason why we’re all here, we’ll generate some shareholder value. So first how agents interact with the web. I like to think about the output of a model as a probability distribution. You receive input tokens. They represent the

[01:35] page state, the overarching goal or the steps that have already been taken. Then the model explores a distribution of possible actions proposing the most likely one. Then that action is transposed into a structured tool call and deterministically executed to interact with the browser. But the interface of the browser is complicated. You have several distinct layers. You have requests flowing in and out of the browser. You have the document object model or the HTML

[02:05] representation of the page. You can screenshot the browser. the accessibility tree which is a semantic textual representation of the page and the browser state storage cookies console URL tabs etc. Underneath all of this, you have a dynamic code execution runtime where you can interact with the browser by writing arbitrary do JavaScript or CDP. How do you wire these together? Typically in industry, there’s three

[02:36] main strategies. Number one is creating a textual representation of the browser. This typically involves taking the HTML state of the page in the accessibility tree and creating a hybrid representation. Number two is computer use where you represent the browser in a series of screenshots of the page. And finally, and becoming increasingly popular, is deharing your agent, removing tailor made tools in favor of dynamic execution environments where the agent can write arbitrary code against the browser.

[03:08] In practice, most production systems lean on the first, the second, or a combination of the first and the second two strategies. Now let’s think about the type of agentic trajectories on the browser. And here I define three spanning across a spectrum of agenticness. From least agentic, we have purposebuilt browser trajectories that are specially made to complete a single task. To the most agentic, we have just in

[03:38] time browser automations where we don’t know what the task is beforehand and the user provides us an arbitrary task to complete. In the middle, we have something sort of between both. We’re using the browser as an implementation detail to serve a larger goal, such as performing deep research or competitor analysis. At scale, I really want to hone in on these transactional workflows. Not because it makes things easy, but that’s because we typically see at scale. These workflows are transactional by nature

[04:11] where we want to complete a unit of work end to end. On the other side, browser agents provide us a flexible execution environment to handle ambiguity in production. So, we know how agents interact with the web and the different types of trajectories we may see and we’re honing in specifically on transactional workflows. Why is it so hard in production? And I think it comes down to a key interaction.

[04:41] Cost accumulation is continuous while value realization is terminal. Each step in your trajectory, you’re incurring some incremental cost. Additionally, you’re incurring some incremental risk of failure. Yet, I only receive value from this browser trajectory when all steps of the task have been completed. That’s all to say that with browser agents, there is no partial credit. And the vast majority of web automations fall into this category. So you say, “Okay, well each step

[05:13] there’s more risk and there’s more cost. If I use a highly capable model, I can sidestep this conundrum.” Take this thought experiment for an example. You have a browser agent where each step has an independent success rate of 99%. If your browser trajectory spans 100 steps, the overall success rate at scale starts to look like 36%. only about a third of the time. That’s not super great and it’s certainly not how we deliver reliable outcomes for

[05:44] customers in production. And so you say, okay, well, we’re continuously accumulating costs, we’re continuously accumulating risk, and the percentage chance of value realization is very low. That would suggest to never use a browser agent. Uh, thankfully, that’s not the subject of my talk today. I think this dynamic is real, but the math isn’t the whole story. And so, it’s time to take a step back. Let’s think about what’s important and how agents actually

[06:17] deliver value. And to illustrate the value that I wish agents to deliver, uh, I will propose a simple equation. Um, perhaps not used enough by many of us. And this equation is profit equals revenue minus costs. Yes, very simple. Um, but perhaps overlooked when thinking about browser agents. And this is all to say that your agent is just another line item and that your agent should give you more than it takes. But when we think about what your

[06:48] agent should give you, that begs the question of what does a browser agent actually give you? And so to answer this question, I like to think about the context of the customer. At browserbase, we help our customers deploy browser automations for their users. Oftent times, they’re not automating the web for their own needs, but instead performing actions on the web on their customer’s behalf. And so, a browser agent actually gives you a task completed for your customer repeatedly.

[07:19] Well, it gives you that ideally. And the question is how you can create a dynamic system that affords the benefit of being able to wade through ambiguous problems while also completing the task repeatedly every time when the environment stays the same. And so we’ll look across three dimensions and in order of importance. First is performance. Second is cost and third is maintainability. And when we think about performance, this is the primary measure

[07:50] of success that we want to focus on. Because once we know a browser agent is performant, it can complete the task we ask it to do. Then cost and maintainability simply become optimization problems. And I like optimization problems because those can be addressed with engineering. So the first thing we need to ask is what success actually looks like. And success in these transactional browser trajectories look like some kind of concrete artifact that the run leaves behind. If you’re paying a bill, that

[08:23] might look like a confirmation email. If you’re placing an order, that may look like an order ID or a receipt. Or if you’re submitting a form, that may look like a new record in a system that you can deterministically query. Second, >> how often is an agent correct? And there’s two ways to measure that. Naively, you may measure the success of an agent on a perr run basis. Assume you have a browser agent. It’s probability

[08:54] of success on any run is 50%. Yet, if you permit that agent to retry for a particular transaction, maybe up to four retries, your per transaction success rate quickly climbs to 94%. And so when you think about what metric matters, again, I’d implore that we ground ourselves in the customer. The customer does not care necessarily how many retries you perform, but rather that the workflow was completed successfully and reliably. In short,

[09:26] permit retries and measure success against a per transaction basis. >> Next, we’ll explore cost and we’ll break cost down into two dimensions. The first is per run, which today is predominantly model costs. But as engineering evolves in the open source landscape for models, there’s an incredible downward price pressure on the cost of intelligence. And I believe over time, model cost will become a smaller and smaller component

[09:57] of deploying browser agent trajectories. Next is infrastructure and compute. What are the real resources you need to run your browser agent trajectories? And last is additional integration and tooling. Then we think about maintenance over time. We need to invest in observability not only in how the agent made decisions but what actually transpired in the browser. Second is developer time. When things break or things are not working optimally, people need to come in and reconfigure the

[10:28] harness or augment its capabilities. And last is re-evaluation. As the problem changes, sites change, models progress, and we need to re-evaluate our point in time solution to last the test of time. So, we talked about performance, we talked about unit costs, we also talked about maintainability. What are the risk factors to the durability of these over time? Well, first and foremost, the

[10:59] environment can fight back. Antibbots and just generally we understand the web as not the friendliest place for your agent. Second, the task changes. The underlying job shifts beneath the a shifts beneath the agent and we ask the agent to wade through ambiguity. Luckily, this also benefits from increased model capability as models are more able to intuitively understand the intention of the user. and therefore in the face of something go wrong course correct and ultimately complete the

[11:30] goal. Third is a better methods better methods appear and this is sort of a canonical conundrum with automating the web. What happens if I’m automating the web today and that same website creates an API tomorrow but for the vast majority of browser agent use cases uh an API isn’t coming anytime soon. And finally the model strays off tasks. models are inherently indeterministic. So from run to run it may not ide follow the ideal path or the critical path to

[12:01] perform the action. So finally we’ve come to the meat of the talk. How do we concretely generate shareholder value? This is the question. Uh we understand that if a model performs well then cost and maintainability are an optimization problem. So let’s explore that in practice together. We’re going to go through a highle architecture of a browser agent for real world tasks. This task is automating an health insurance portal. Every step we take in creating

[12:34] this dynamic system should influence one of these key levers. Cost, performance or maintainability. So first we’ll start with a lowly agent. The goal of this agent is to log in and download an explanation of benefits. A request comes in, the agent performs the action on the browser, and this is the minimum necessary system you need to just do something. Next, you realize that when you go to download that explanation of benefits,

[13:04] that downloading involves programmatically interacting with the page. And then once you perform that download, you need to retrieve that file from storage and bring it into the agent’s runtime. So you create a tool that does this all in one transaction. Instead of the model needing to make decisions on the fly, you encapsulate a complex operation into a single tool call. Next, you want to give the agent an opportunity to verify its work real time. This can be done by giving it

[13:34] another tool. This tool is an OCR tool that deterministically extracts entities from the document and compares that against the system of record. Great. Now the agent knows if it’s did it if it really did its job right or not because it has a deterministic mechanism to verify that. Next, you realize that while this portal may have ambiguity in your business logic that the authentication workflow is never changing and you want to reuse the

[14:05] same authentication mechanism for many business operations on the same portal. So you pull that authentication logic out from the responsibility of the model. Again, we’re reducing the number of steps that the agent has to take to complete the task successfully. This means lower unit cogs, higher performance, and easier maintainability as well as we can reuse this authentication function across multiple business logic workflows on the same portal. Last,

[14:37] we’ve contained the responsibility of the agent to only the area of ambiguity necessary. So, we draft a skill. These skills look very similar to a standard operating procedure that we would have humans use in the past, except this standard operating procedure is for an agent, and it allows the agent to follow the critical path more closely. At the beginning of the talk, we discussed how the output of an agent can be thought of like a probability distribution. So if

[15:08] we introduce the critical path to the agent, it knows it’s at step two and knows that it needs to take step three because we have outlined it in this skill, then it’s more likely to take that step three. It knows exactly where it needs to go and we remove ambiguity from the agents decision process. In the end, this is the final result. We have actually a pretty complex system. A request comes in, a serverless authentication function authenticates the browser. That browser is provided to

[15:39] the agent runtime. The agent navigates the portal using the skill provided, calls a deterministic download function, provides that downloaded file to a verify tool, and can know authoritatively whether its trajectory succeeded or failed. In the end, this system takes steps out of the model’s responsibility that simply do not need to be in the responsibility of the agent. We reduce the number of steps it needs to take while still being able to achieve the

[16:11] desired outcome. Thus, the system’s more maintainable and it’s more performant and we can overcome the browser agent conundrum. So, >> here we are. Welcome to production and congrats. Now you’re on call. Thank you.

[16:46] >> [music]