Hill-climbing de skills: como melhorar agentes sem mudar o modelo — Shubhankar Srivastava, Browserbase

Ver no idioma original →

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: Hill-Climbing Skills: Improve Agents Without Changing the Model — Shubhankar Srivastava, Browserbase · Canal: AI Engineer · 51:22 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Segurança de IA

Resumo

Shubhankar Srivastava apresenta uma abordagem para melhorar a confiabilidade de agentes de navegador sem alterar os pesos do modelo: um loop de autoaprendizado que analisa execuções, registra descobertas em uma skill e as aplica em tentativas futuras. A arquitetura combina um agente executor, que realiza a tarefa, e um agente professor, que avalia os traces e atualiza uma estratégia até encontrar um caminho melhor. O palestrante demonstra ganhos de custo, latência e sucesso em tarefas como pesquisar voos e fazer reservas, e mostra como essas skills podem ser reutilizadas em outros agentes. Para aplicar a técnica, são necessários um ambiente reproduzível e resultados verificáveis; também é preciso considerar segurança, mudanças nos sites e critérios de avaliação.

Pontos-chave

• A confiabilidade de agentes de navegador é tratada como um problema de engenharia, relacionado às ferramentas, ao harness e às skills fornecidas.
• O loop auto browse separa o trabalho entre um agente executor e um agente professor, que aprende com os traces e atualiza um arquivo de estratégia.
• As descobertas são persistidas em uma skill reutilizável, evitando que execuções futuras recomecem do zero.
• O palestrante relata reduções de custo de até 16 vezes em diferentes tarefas, embora os resultados variem conforme o caso.
• Skills podem registrar atalhos específicos de sites, como construir URLs de busca diretamente ou evitar caminhos que acionam bloqueios.
• A técnica pode ser aplicada fora da navegação, inclusive a agentes de código, pesquisa e operações internas.
• Loops eficazes dependem de um ambiente reproduzível e de um resultado verificável ou de uma métrica quantificável.
• O critério de otimização pode priorizar sucesso, latência, número de turnos ou confiabilidade, conforme o uso.
• O palestrante recomenda proteger o sistema contra prompt injection com controles na skill, na infraestrutura, na rede e nas ações permitidas.

Capítulos

Início	Capítulo	Resumo
00:00	Introdução e agentes de navegador	Shubhankar Srivastava apresenta o tema e explica como agentes usam o navegador e ferramentas de controle para interagir com sites.
05:27	O problema de agentes que não aprendem	O palestrante descreve por que execuções que começam do zero dificultam a confiabilidade e introduz a ideia de aprender com traces.
10:19	Demonstração do loop auto browse	A demonstração mostra como o agente registra aprendizados em uma estratégia e os transforma em uma skill reutilizável.
16:06	Resultados e skills para sites	O palestrante apresenta melhorias observadas em custo e confiabilidade e mostra o catálogo de skills browse.sh.
20:30	Aplicações em outros domínios	A abordagem é relacionada a agentes de código, pesquisa e operações, com destaque para ambientes reproduzíveis e resultados verificáveis.
26:52	Convergência, custo e implementação	Na sessão de perguntas, Srivastava discute como ajustar iterações, custos e infraestrutura para diferentes tarefas.
33:54	Harness, evals e armazenamento de skills	As respostas abordam a seleção de skills e ferramentas, a avaliação de estratégias e onde armazenar skills.
37:45	Atualização das skills e critérios de sucesso	O palestrante explica como detectar falhas em produção para atualizar skills e como escolher métricas como latência ou número de turnos.
42:06	Verificação, ambientes e avaliação do agente	A conversa trata de resultados verificáveis, uso de sites reais e da forma como o agente professor avalia os traces.
47:30	Segurança e prompt injection	Srivastava descreve camadas de proteção contra instruções maliciosas, incluindo restrições de rede, URLs e ações.
50:15	Monitoramento recorrente e encerramento	O palestrante sugere usar tarefas agendadas para testar skills e acionar um loop de correção quando houver falhas.

Citações

A confiabilidade é um problema de engenharia. — 03:11

Cada execução do agente começa do zero e não aprende com seus traces de produção. — 05:27

Você deve ter um ambiente reproduzível e algum resultado verificável. — 21:37

No meu caso, o que mais importa é a confiabilidade. — 40:28

Conceitos e entidades

• hill climbing (conceito): Processo iterativo de aprimorar o desempenho de um agente com base nos resultados e traces de execuções anteriores.
• browser agent (conceito): Agente que usa um navegador como ferramenta para interagir com sites e realizar tarefas.
• auto browse (conceito): Loop apresentado na palestra que combina execução de tarefas de navegação e aprendizado a partir dos traces.
• skill (conceito): Artefato reutilizável que registra instruções e aprendizados para orientar execuções futuras de um agente.
• Browserbase (empresa): Empresa para a qual Shubhankar Srivastava trabalha e que oferece infraestrutura e ferramentas para agentes de navegador.
• Shubhankar Srivastava (pessoa): Integrante da equipe de sales engineering da Browserbase e palestrante sobre o uso de skills para melhorar agentes.
• browse.sh (ferramenta): Produto apresentado como um catálogo de skills para tarefas em sites, disponibilizado gratuitamente segundo o palestrante.
• WebMCP (conceito): Abordagem mencionada para tornar sites programáveis por meio de capacidades expostas no navegador.
• prompt injection (conceito): Risco em que conteúdo de sites tenta induzir o agente a seguir instruções maliciosas ou não autorizadas.

Tradução completa (pt-BR)

00:00 Certo. Olá. Obrigado a todos por estarem aqui. Sei que é o último workshop do dia. Agradeço a todos vocês por terem vindo. Sou Sh… estou aqui para falar sobre skills de escalada de encosta, especificamente sobre como melhorar seus agents sem mexer nos modelos, sem mexer nos

00:33 pesos. Também tenho um Slido aqui. Vou mostrar o código QR caso alguém queira enviar perguntas, e podemos respondê-las no final. Um pouco sobre mim: sou Sh. Faço parte da equipe de engenharia de vendas da Browserbase. Basicamente, trabalho com nossos clientes para colocar agentes de navegador em produção. Não sei, talvez possamos fazer uma votação levantando as mãos. Quantos de vocês sabem o que são agentes de navegador?

01:06 Alguém? Certo, alguns. Incrível. Algum de vocês já criou agentes de navegador? Alguém já usou essas ferramentas? Levantem as mãos. Certo, alguns. Incrível. Legal. Talvez eu fale um pouco sobre o que são agentes de navegador antes de entrar no conceito de escalada de encosta para skills, para que fique claro o que estamos fazendo. No final da palestra, também vamos ver como vocês podem fazer isso no domínio e na área de vocês.

01:39 Certo. Uma explicação rápida sobre o que são agentes de navegador. Se você tem um agent que precisa operar um navegador, basicamente chama isso de agente de navegador, certo? O navegador se torna a ferramenta do seu agent. E como você o controla? Você o controla com algum tipo de CLI, algum tipo de MCP, algum método que permita controlar o navegador e dizer: “Ei, clique neste botão vermelho. Clique no botão de atualizar. Faça uma

02:09 captura de tela ou tire uma captura da árvore de acessibilidade deste site.” Certo? Essas são ferramentas de baixo nível às quais seu agent pode ter acesso para controlar o navegador. A Browserbase é basicamente uma plataforma para criar e executar esses agentes de navegador. Fornecemos a infraestrutura, os SDKs, as skills e o CLI usados para criar esses agentes de navegador. Vamos usar todas essas ferramentas para ver como é a escalada de encosta.

02:39 Certo. Quero falar um pouco sobre o maior problema dos agents hoje: a confiabilidade. As pessoas ficam frustradas quando os agentes de navegador travam, se deparam com um problema de CAPTCHA anti-bot, ou talvez simplesmente esquecem ou ficam com preguiça e não concluem a tarefa. E vemos a confiabilidade basicamente como um problema de engenharia. Acho que os modelos recentes, o Opus e o Fable, quando

03:11 foram lançados, durante aqueles três dias, eram realmente muito inteligentes, certo? Mas vemos que boa parte do trabalho necessário para garantir a confiabilidade está no harness em volta deles, nas ferramentas que você fornece, nas skills que você dá a eles. E é isso que vamos analisar: como melhorar a confiabilidade desses agentes de navegador? Queria mostrar alguns exemplos de situações em que esses agents são ruins hoje, certo? Se eu ampliar um pouco, vocês vão ver este agente de navegador tentando acessar o Google Flights e clicar no…

03:47 Ele está tentando arrastar o filtro de horário e não consegue descobrir como fazer isso. Arrastar é uma operação complicada para esses agents, e ele está ficando muito confuso. Não sabe qual é o elemento HTML nem qual é o JavaScript responsável por isso. Não consegue fazer a operação, trava e não consegue reservar minhas passagens. Outro exemplo que queria mostrar é um agente de navegador no OpenTable. Digamos que eu tenha meu OpenClaw ou meu agent Hermes e precise reservar um jantar romântico. Eu digo: “Ei, acesse o OpenTable e…

04:18 encontre alguns lugares para mim”, e veja o bloqueio anti-bot que ele encontra, certo? Ele simplesmente recebe “acesso negado”. Não sei o que acontece aqui. Mas será que meu agente de navegador consegue contornar esses problemas? Será que pode ser mais confiável? E será que consegue reservar os restaurantes para meu jantar romântico? Essa é a grande pergunta que eu queria fazer aqui. É nesse ponto que vamos analisar algumas ideias para melhorar a confiabilidade desses agents. Uma delas… Na verdade, vamos investigar a causa raiz, certo? Por que isso está acontecendo? Temos…

04:52 modelos como esses, o Opus 5.5, que são excelentes para uso geral. Talvez vocês tenham usado o Codex para uso do computador; é muito bom. Mas, quando se trata de sites difíceis e demorados, como o OpenTable ou o Google Flights, fica muito difícil executá-los em produção. O agent não conhece os truques específicos desses sites nem o JavaScript que precisa ser executado no navegador, certo? E o mais importante é que cada execução começa do zero. Não há nenhum tipo de aprendizado incorporado às execuções. Eu…

05:27 acho que Darkh falou sobre isso alguns dias atrás: por que o progresso no uso do computador ainda é tão lento hoje? Embora o uso do computador pareça um problema verificável, por que ainda não foi resolvido? Basicamente, não há aprendizado acontecendo. Cada execução de um agent começa do zero, e ele não aprende com os traces de produção. Chamo esses agentes de navegador de gênios que nunca aprendem. Algumas pessoas talvez digam: “Por que vocês não fazem fine-tuning com algo como o OpenTable ou sites de restaurantes?” Mas isso não é…

06:01 realmente escalável, certo? Se você está pensando em criar agents, não pode fazer fine-tuning para cada nova tarefa que surgir. Você quer um método que permita aprender com os traces de produção e melhorar com o tempo. Foi aí que começamos a pensar nisso, há quatro a seis meses, quando Karpathy surgiu com essa ideia de pesquisa automática. Basicamente, é um ciclo, certo? Esse ciclo recebe a descrição de um problema verificável e tenta resolvê-lo…

06:34 repetidas vezes, analisa os próprios traces e tenta se aprimorar. E nos perguntamos: como podemos aplicar isso aos agentes de navegador? Como aplicar isso a esses workflows complicados, a esses sites complexos, que não são determinísticos, mudam todos os dias e exibem CAPTCHAs diferentes a cada vez? Como podemos aprender com eles? Certo? É aqui que quero passar para uma demonstração e mostrar isso ao vivo. Vou começar com…

07:08 um prompt aqui. Quero pedir algo como: acesse o Google Flights e encontre uma passagem de classe executiva de São Francisco para Nova York para este sábado. Quero levar uma mala de mão. E o voo deve ser de manhã. Espero que o meu… Certo, está correto. Vou colar isso e executar. Certo. Iniciando uma sessão do Browserbase aqui.

07:40 O que vocês veem no centro é um navegador remoto que acabou de ser iniciado e acessou o Google Flights. Se eu expandir meu agent aqui, vocês verão que ele está fazendo todas essas coisas. Estes são os traces de raciocínio que vocês podem acompanhar ao vivo, e ele está tentando aplicar o filtro de classe executiva. Então, ele vai fazer o trabalho e voltaremos a isso. Mas queria falar sobre o que está acontecendo aqui e sobre a arquitetura por trás desse ciclo de pesquisa automática.

08:10 Então, iniciamos a tarefa do Google Flights. E a arquitetura aqui é este ciclo de navegação automática, como o chamamos. Pegamos a pesquisa automática e a navegação. Chamamos isso de navegação automática. Esse ciclo consiste essencialmente em dois agents em um loop do SDK do agente de claw. Podemos chamar um de agente executor e o outro de agente professor. O trabalho do agente executor é realmente navegar. Ele tem acesso ao CLI de navegação de que falamos. Ele tem acesso

08:44 no navegador, e ele vai clicando nos botões, olha a captura de tela, tenta obter informações para mim, e o trabalho do teacher é olhar os rastros do doer e aprender o que deu errado e o que deu certo. Eles continuam trabalhando juntos até encontrar uma solução muito boa que converge, certo? Não dizemos quantos ciclos ele precisa executar. Não dizemos qual é o fator de sucesso, a taxa de sucesso que queremos. Não

09:16 dizemos: “Ei, precisamos fazer isso em até X tokens ou X segundos.” Só damos um prompt amplo e deixamos a bitter lesson… abraçamos a bitter lesson e dizemos: “Tudo bem, deixem o doer e o teacher trabalharem.” E o principal que acontece é que existe um arquivo strategy.md, que é essencialmente o artefato compartilhado entre várias execuções. Depois de cada iteração, o teacher pensa no que aconteceu, olha a captura de tela, olha os logs e então

09:46 pensa: “Ah, você não clicou neste botão. Você deveria clicar neste botão, na verdade”, e registra isso no arquivo strategy.mmd. Esse artefato é levado para a próxima iteração, e o desempenho melhora a partir daí. Talvez voltemos à nossa demonstração para ver o que aconteceu. Certo. Então, na iteração número um, houve uma falha aqui. O aprendizado dessa iteração foi ignorar todo o widget de calendário do formulário, porque você pode simplesmente usar um parâmetro de consulta e não precisa ficar clicando por aí, certo? O agent

10:19 foi esperto o bastante, neste caso, para pensar: “Ah, estou gastando tantos tokens e tanto tempo clicando por aí, quando poderia simplesmente usar o parâmetro de consulta do Google Flight.” Isso fica óbvio olhando em retrospecto, mas talvez eu, como pessoa, não tivesse pensado nisso nem escrito esse parâmetro de consulta complicado, certo? Então, esse foi o aprendizado da primeira iteração. Agora, ele está executando tarefas na iteração número dois. Vai continuar até sentir que esgotou todos os truques, que esgotou

10:50 todos os hacks de JavaScript que poderia usar e, então, pensar: “Tudo bem, esta é a skill que posso usar daqui em diante.” Acho que o principal ponto que eu também queria abordar é que, no fim desse ciclo convergente, a saída que quero é um arquivo skill.mmd. Esse arquivo skill.md seria o que eu forneceria aos meus agents no futuro. E teria uma

11:22 coleção de todos os hacks, truques e aprendizados das execuções anteriores. Vamos ver como essa skill poderia ser. Poderia ser algo como: “Ei, uma URL preenchida previamente é obrigatória. Não fique clicando nesses botões e desperdiçando cliques e tokens. Há um bug ao reabrir o calendário. Não faça isso. Se quiser mover o controle de horário arrastando, use injeção de JavaScript. Não tente fazer isso com o

11:53 mouse.” Certo? Esses são os tipos de truques que agora ficam registrados para todas as execuções futuras e me permitem economizar muito mais em desempenho, confiabilidade e custo. Agora, vamos voltar à nossa execução e ver se ela passou. Certo, a iteração número dois passou e, como podem ver, a economia de custo é de cerca de 4x. Este gráfico está sendo criado na hora. Então, começou em US$ 12, e a segunda ficou em US$ 3. E lembrem-se de que meus agents aqui são Opus 48, tanto para o doer quanto para o teacher. A iteração três acabou de chegar. O número de turnos diminuiu. A latência também melhorou. Mas houve uma falha na iteração número três. Parece que ele exagerou na correção de alguma coisa, e a iteração número quatro provavelmente vai aprender com isso. Vamos ver se aprende.

12:23 voar. Então, começou em US$ 12, e a segunda foi US$ 3. E lembrem-se de que meus agents aqui são Opus 48, tanto para quem executa quanto para o professor. Agora, a terceira iteração acabou de chegar. O número de turnos diminuiu. A latência também melhorou. Mas houve uma falha na terceira iteração. Há algo em que ela corrigiu demais, e a quarta iteração provavelmente deveria aprender com isso. Vamos ver se ela faz isso.

12:55 Enquanto ele faz o trabalho, queria mostrar algumas execuções anteriores que fiz para preparar esta demonstração. Por exemplo, fui ao auto browse e pedi: “Ei, acesse o site AI engineers e me diga quais palestras e workshops falam sobre hill climbing”, certo? Ele fez isso em várias iterações, e vocês podem ver a reprodução de cada uma delas. São reproduções fornecidas pelo Browserbase, muito úteis e importantes para a observabilidade. E, como podem ver, ele foi melhorando em

13:28 termos de custo: 7,4x, 4x. Embora tenha conseguido passar em todas as iterações, ainda obtive melhorias de custo. Agora, eu queria ver quais são os aprendizados dessa skill, certo? Como registrar todos esses aprendizados? Ela diz para ir direto à página de agendamento do Shed. Se houver erros em aberto, não tente repetir às cegas. Execute isto. Digite a palavra-chave no campo de busca da sessão. Aguarde um pouco. Então, espere um pouco,

14:00 porque às vezes os sites demoram muito para carregar. Então, você pode ter esse tipo de truque e depois ler os resultados. Há muito aprendizado acontecendo nessas skills. Talvez eu pudesse mostrar alguns exemplos interessantes. Queria mostrar este do OpenTable porque comecei com o bloqueio de acesso negado quando iniciamos esta demonstração. Se formos à captura de tela, este foi o aviso de acesso negado que recebemos na iteração número um. Vamos ver como ele

14:31 aprendeu com isso. Ele percebeu que o bloqueio é ambiental, porque o site não quer que esse agent faça alguma coisa. Na iteração número dois, descobriu que, se eu usar um parâmetro de consulta e incluir latitude, longitude e o ID da região metropolitana, obtenho automaticamente uma interface que funciona. Não abra /r, que está bloqueado, nem recarregue /s. É nesses pontos que os bloqueios entram em ação. Se você não fizer isso e, em vez disso, seguir esta técnica, seu

15:03 agent vai funcionar, certo? E, como podem ver, o custo caiu de US$ 6,22 para US$ 0,51. O tempo passou de 189 segundos para 27 segundos. E a skill que ele criou está aqui: montar a URL de busca e calcular as datas desta forma. Estes são os pins conhecidos das regiões metropolitanas de San Francisco. E seguir estes passos, certo? Nunca chamar /r, porque isso vai retornar

15:34 acesso negado. Esses são os tipos de aprendizados que uma pessoa nunca poderia ter descoberto, mas você simplesmente abraça a bitter lesson e deixa os agents fazerem o trabalho, e eles encontram esses truques para você. Também quero mostrar alguns exemplos do tipo de melhoria que vemos. A razão pela qual esse problema é tão importante para mim é que, do ponto de vista de vendas, estou implantando esses agents de navegador em produção. A

16:06 venda só se concretiza quando o agent de navegador tem sucesso. Então, confiabilidade é o mais importante para mim, e esta é a ferramenta principal que levo aos meus clientes e digo: “É só colocar seus agents para funcionar, deixá-los fazer essa pesquisa automática, e eles terão sucesso em produção.” E estes são os tipos de métricas de sucesso que as pessoas procuram: até 16x mais barato, 12x mais barato, 3x mais barato, em tarefas diferentes. Claro, cada tarefa é diferente. Os gargalos de cada tarefa também são diferentes. Então, vocês podem ver

16:37 variações nisso. Mas a ideia é que vocês podem fazer hill climbing usando essas técnicas. Queria voltar à nossa demonstração ao vivo e ver se houve alguma melhoria. Certo. Temos uma skill consolidada, e ela foi aplicada de ponta a ponta. Não houve mais aprendizado. Os resultados estão sendo exibidos corretamente: classe executiva só de ida, de San Francisco a Nova York, em 4 de julho, com uma bagagem de mão incluída. E há um voo às 8h por US$ 649. Certo? Então, ele conseguiu obter tudo isso, e eu posso

17:11 mais ou menos assistir à reprodução inteira para ver se isso está correto. Ele conseguiu descobrir essa skill inteira, e o caminho rápido é codificar a consulta toda na URL. Prefiro muito essa abordagem. De novo, sei que estou mostrando essas coisas, mas, quando comecei a analisar os resultados aqui, esse foi meu momento de “este é o momento Mythos dos browser agents”, sabe? Fazer engenharia reversa de tudo com muita intensidade. Mostro isso a alguns dos meus clientes, e eles ficam de queixo caído. Antes, eles…

17:45 escreviam scripts para cada um de seus sites. Diziam: “Preciso dedicar tantas horas de engenharia só para fazer engenharia reversa desses sites. Como posso escalar isso para 100, mil sites?” Agora, nossos clientes realmente criaram pipelines inteiros dessas skills, que são geradas na hora, com pull requests criados automaticamente. Se houver uma falha em produção, um agent entra em ação e também começa a corrigir a skill. Então, há…

18:15 muita engenharia que podemos fazer em torno disso para aproveitar essa técnica. Também queria mostrar o que fizemos com isso, certo? Na verdade, criamos este produto chamado browse.sh. Pensamos: se podemos fazer isso para um site, podemos fazer para cinco; por que não fazer para uns 500 sites e disponibilizar gratuitamente para qualquer pessoa? E, se vocês se lembram, lá em 19… ou seja lá quando, antes da internet, havia as páginas amarelas. Elas traziam…

18:49 informações para encontrar pessoas, empresas etc. Isto são as páginas amarelas para browser agents, certo? Traz informações sobre como realizar qualquer tarefa em qualquer site da web. Queria mostrar isso para vocês. Na verdade, vocês podem instalar o browse CLI e usar todas essas skills de graça. Nós mesmos cobrimos os custos de token e estamos disponibilizando isso para vocês. Então, se eu for, por exemplo, pesquisar produtos na Amazon, eu…

19:23 posso ver a skill inteira aqui. Quando você deve usar a skill? Como deve verificar preços, disponibilidade e tudo mais, certo? É assim que você usa isso. Há muitos detalhes sobre a Amazon, as capturas de tela, e eu só passo esse browse skills CLI para o meu OpenClaw, e ele simplesmente sabe quando carregar a skill do alltrails.com e quando carregar a skill do weather.gov, o que facilita muito a minha vida. Essencialmente, estamos executando o mesmo ciclo de auto research…

19:56 nos bastidores e disponibilizando isso para vocês. Na verdade, se quiserem, podem acessar aqui e dizer: “Vá criar uma skill para mim para procurar eventos em San Francisco nesta semana”. Vocês fazem isso, geram uma skill, e ela faz isso por vocês. Ela envia um e-mail, e então vocês podem usar a skill em qualquer agent que quiserem, certo? Fizemos isso para browser agents. E queria falar sobre como…

20:30 vocês poderiam fazer isso para qualquer outro domínio, certo? Acho que os coding agents são um exemplo de situação frustrante que já vi: o agent reaprende as convenções do repo toda vez. Não aplica as regras de linting corretamente, e tenho que avisá-lo sempre. Talvez vocês possam usar seu CLAUDE.md e AGENTS.md e melhorar isso, mas a premissa fundamental é que o agent não deveria ter que reaprender suas tarefas do zero, certo? Já vi isso…

21:04 em agents de pesquisa. Executamos vários agents de deep research em nossos workflows internos, e toda vez eles têm dificuldades e tentam reaprender: “Ah, encontrei estas informações na Wikipedia, mas não as encontrei neste outro site”. E eu pensava: “Por que não? Sempre usamos esse outro site. Você deveria aprender com seus rastros anteriores e buscar as informações”. Em operações internas, vocês têm todos esses dashboards, bancos de dados e ferramentas internas, mas seus agents não sabem quais funcionam nem quais são…

21:37 preferidos. Idealmente, vocês deveriam aplicar essa técnica de auto research. E são necessárias duas condições: primeiro, vocês precisam ter algum tipo de ambiente reproduzível para poder executar esses ciclos; segundo, precisam ter algum tipo de resultado verificável, algum tipo de métrica quantificável para executar esses ciclos. Sim, estou vendo uma pergunta ali.

22:18 Percebi isso, sim. >> Sim. >> Sim. Exatamente. Acho que a pergunta é: como vocês sabem se o ciclo de auto research está correto…

22:51 se está convergindo e se, quando diz que está convergindo, está mesmo convergindo? Quando diz que está bom, está mesmo bom? Quando diz que está ruim, está mesmo ruim? Como posso confiar no que o agent está dizendo e no que o ciclo está fazendo? Acho que é aí que quero falar sobre o resultado verificável. Para Karpathy, era bem fácil, porque ele observava a log loss do experimento enquanto treinava redes neurais, certo? Então, é muito fácil ver se sua log loss diminuiu ou não. Mas, em muitos cenários do mundo real, esse não é o…

23:24 caso dos browser agents. Como expliquei, saber se você reservou uma passagem aérea ou não talvez seja simples, mas saber se encontrou as melhores opções de voo para mim pode ser um pouco subjetivo e talvez não seja o melhor…

24:05 Sim, se entendi corretamente, você está dizendo que um erro no ciclo pode comprometer toda a execução de auto research. E como evitar isso? Já vi algumas iterações falharem. Por exemplo, se olharmos o slide anterior, há falhas depois de sucessos, certo? Então, não é sempre que, depois de ter sucesso, todas as iterações futuras também terão sucesso…

24:38 mas acho que é no desenho do seu ciclo que você pode torná-lo resiliente a falhas, para que não dê peso excessivo a elas e ainda consiga se corrigir e se proteger de qualquer erro ocorrido em execuções anteriores. Acho que estamos tentando evitar o que chamam de cenários em que a loss explode. Acho que dá para fazer isso. Na verdade, Karpathy fala sobre isso: essa é uma forma de fazer auto…

25:10 research. Na verdade, vocês podem fazer auto research sobre diferentes maneiras de fazer o próprio auto research. Por exemplo: o ciclo teacher-doer é o melhor? Deveria haver uma arquitetura multi-agent para fazer isso, ou outra abordagem poderia funcionar melhor para tarefas de pesquisa em redes neurais em vez de browser agents? Certo? Vocês poderiam ter diferentes designs para seus ciclos e evitar situações como essas. E, voltando ao que eu disse, desde que tenham um resultado verificável ou alguma métrica quantificável, acho que deveriam…

25:40 conseguir projetar um bom ciclo aqui. Acho que às vezes se fala pouco sobre ambientes reproduzíveis, mas eles são extremamente importantes. Acho que ele estava falando sobre Darkh e disse que ter um resultado verificável é importante, mas que vocês também precisam de ambientes em que seja possível fazer muitas tentativas, ou de casos de uso que permitam muitas tentativas. Certo? Se o agent não consegue insistir diante das falhas, será difícil fazer várias…

26:15 iterações e se corrigir. Coding agents são um bom exemplo, porque vocês podem começar com uma imagem do Docker ou com uma instância EC2 específica e reproduzir a partir de diferentes partes da stack. Mas talvez o trabalho de conhecimento não seja tão fácil de reproduzir. Talvez haja muitas ações diferentes com participação humana no ciclo, o que torna muito difícil reproduzir a partir de um momento específico. Portanto, investir no ambiente também pode trazer ótimos resultados nesses casos.

26:52 Incrível. Eu só queria compartilhar as URLs do loop de navegação automática que demonstrei hoje. Se vocês escanearem o QR code, poderão acessar o GitHub disso. E o segundo QR code aqui é a própria skill. Basta executar /auto browse no Claude Code ou no Codex e dizer: “Ei, /auto browse, use Opus 4.8 tanto para o teacher quanto para o doer e crie uma skill para eu fazer isso.”

27:25 Estou olhando uma dessas perguntas. E, se algum de vocês tiver ideias de algo que queiramos colocar o agent para fazer, fiquem à vontade para digitar no Slido e podemos testar ao vivo. Mas vamos olhar esta pergunta: existe uma maneira de otimizar a convergência? Acho que é a mesma pergunta de que estávamos falando agora há pouco. O alto custo é interessante, porque talvez vocês pensem que fazer iterações mais longas possa ficar mais caro com o tempo. Já executei muitos evals sobre

27:59 isso, em que posso usar um Sonnet nesse problema, mas executá-lo por mais iterações, em vez de usar um Opus por menos iterações. Acho que dá para concluir o mesmo trabalho usando o Sonnet por um número maior de iterações, mas ainda assim gastando menos no total. Além disso, esse custo é amortizado, certo? Um loop de navegação automática que provavelmente executamos custa talvez US$ 30 ou US$ 40; se for muito complicado, no máximo US$ 100. Então, esse custo é amortizado, desde que faça sentido para vocês implantar

28:31 isso em produção. É só fazer. Mas há muitas coisas interessantes que vocês podem fazer ao avaliar os tipos de loop que estão gerando. Sim, também vou compartilhar os slides. Posso fazer isso no próprio GitHub. Você pode explicar como pensou em passar de auto research para auto browse? Quer dizer, o processo foi bastante simples. Peguei o repo do GitHub que Karpathy publicou e, em seguida,

29:03 há todo esse contexto sobre meus clientes que tenho, em que eu dizia: “Ei, estes clientes enfrentam estes tipos de problemas de confiabilidade. A maneira como resolvo isso para eles é ir ao escritório deles, trabalhar com eles bem de perto, como alguém alocado no local, e tentar resolver na força bruta e fazer engenharia reversa. É isso que eu faço. Então, eu sou o agent teacher. Você pode me tirar do processo e criar um loop inspirado no de Karpathy e construir a

29:33 mesma coisa?” E, claro, houve muitas iterações em cima disso. Também foi necessário bastante trabalho de engenharia para simplificar. Mas, sim, esse foi o processo para fazer essa conversão. Dá para usar isso com um proxy? Dá para estar conectado a um site? Sim. Novamente, isso depende do ambiente que vocês projetarem. A infraestrutura da Browserbase, onde tudo isso está sendo executado, permite entrar em sites, salvar os cookies e reutilizá-los em execuções futuras, então

30:05 vocês não precisam fazer login todas as vezes. Isso facilita muito reproduzir workflows do mundo real. E, sim, também dá para usar proxies. Se vocês tiverem endereços IP específicos, como IPs residenciais, podem incluí-los também. O sucesso depende muito da qualidade da infraestrutura e do ambiente, especialmente nesses cenários adversariais, como CAPTCHAs e sistemas antibot. Portanto, fazer com que a infraestrutura seja a melhor possível

30:35 é definitivamente valioso. Incrível. Alguém tem algum pedido de algo que possamos testar ao vivo? Sim. Pergunta. >> Ótima pergunta, ótima pergunta. Na verdade, eu também queria mostrar o código. Se vocês olharem o GitHub, vão encontrar este arquivo evaluate.mjs. Basicamente, ele lista todo o

31:09 loop. O que está acontecendo aqui? Para responder à sua pergunta, o teacher e o doer trabalham um depois do outro em cada loop. Então, o teacher encontra aprendizados em cada iteração. Talvez, se eu mostrar a demonstração aqui… vamos abrir a que acabamos de fazer. A iteração um teve estes aprendizados, e a iteração dois teve outros aprendizados. Certo? Você deve incluir a

31:40 data ISO explícita neste formato específico. A iteração três teria outros aprendizados. A resolução da data ainda abre a página inicial e clica, desperdiçando três turnos lendo a data de hoje ou fazendo o executor calcular a data de hoje. Então, está descobrindo algo sobre data e hora. A cada iteração, o teacher aprende algo novo e registra isso em strategy.mmd. Talvez eu possa concretizar isso olhando os traces de uma dessas execuções. Então,

32:12 aqui estão todas as minhas execuções. Por exemplo, este foi o exemplo de reserva do OpenTable, e esta foi a strategy.mmd que o teacher acrescentava a cada vez. Então, passo zero: faça isto, e assim por diante. Esta era a tarefa, este era o prompt que dei a ele: “Encontre reservas para o restaurante Big B Bigs”. E estes eram os tipos de traces com os quais ele estava aprendendo. Ele fazia capturas de tela e registrava esse tipo de trace a cada etapa. Está executando browse open; é isso que

32:47 a saída mostra. Depois, turno número dois: browse snapshot. Snapshot basicamente captura a árvore de acessibilidade, e esta é a captura. Então, ele lê tudo isso e, a cada etapa, pensa no que deu certo e no que deu errado. Sim, quer dizer, isso é como código de máquina. Não vou mostrar tudo. Mas este também é o resumo que ele escreve a cada iteração. Então, há muitos ajustes de engenharia que vocês podem fazer para adaptar isso ao seu domínio. E a maneira mais fácil

33:21 de ler isso é que também publicamos em skills.sh, em auto browse, e vocês podem fazer algo assim.

33:54 Ótima pergunta. Pergunta muito boa. Acho que isso volta à questão de como aumentar a confiabilidade dos agents. Confiabilidade é um problema de engenharia. Vocês podem projetar o harness para usar uma skill por tarefa ou podem dizer: “Ei, uma skill para toda tarefa que vocês venham a

34:25 encontrar”. Acho que depende totalmente de como vocês fazem a engenharia do harness; depende inteiramente do caso de uso. Vocês executam evals com todas essas estratégias diferentes e veem qual funciona para vocês. Para nós, foi isso. Sim.

34:55 Sim. >> É. É. E é aqui que, mais uma vez, o harness entra em cena. Se o harness tiver inteligência para trazer skills do OpenTable, do Resi e do Google Reservations — talvez possa trazer todas elas para descobrir qual é a melhor maneira de reservar um encontro à noite. Essa é a solução, certo? O harness deveria ser capaz de descobrir

35:26 quais ferramentas usar para concluir o trabalho. É assim que eu faria: descobrir quais são os casos de uso mais comuns dos clientes. Para esses casos de uso, quais são os melhores arquivos de escala, prompts e ferramentas? Talvez vocês queiram ferramentas específicas para casos de uso específicos, certo? Talvez queiram ferramentas genéricas para todos os casos de uso. O argumento aqui é o mesmo: vocês criam uma skill para cada caso ou uma skill para todos? Avaliem todas essas estratégias e deixem o harness descobrir.

36:01 Sim. >> Sim. É. Quer dizer, é um conceito muito parecido com este, certo? DSPy. >> Sim. Acho que aquelas pessoas estavam no caminho certo com algo muito legal; estavam nisso há uns três ou quatro anos, quando começaram a criar DSPy, Japa e tudo aquilo. Acho que nós também temos feito muita pesquisa nessa linha. A Browserbase trabalha com a Microsoft. Na verdade, publicamos um artigo sobre como criar os verificadores certos para os seus agents. Acho que executar evals é simples até

36:36 Você começa a se perguntar: “Certo, como devo avaliar minha eval? Preciso colocar todos esses humanos para verificar todas essas execuções ou existe um bom verificador que eu possa criar aqui?” E tudo isso também usa os aprendizados desses artigos. Posso compartilhar tudo isso no GitHub também. Vou ver se há novas perguntas aqui. Onde e como essas skills foram armazenadas e recuperadas em escala? No momento, para

37:10 este repo, todas elas ficam armazenadas na minha nuvem aqui. Cada uma delas é um arquivo de skill. Este era meu buscador de receitas. Eu queria preparar um jantar ontem, então pensei: “Ei, encontre algumas receitas para mim.” No momento, todas elas estão na minha pasta local de skills. Mas, se você quiser colocar isso em produção, é claro que pode incorporar isso ao loop do seu agent. Ou, se quiser, acho que, para o browse.sh, as skills públicas disponíveis que nós

37:45 temos, acho que usamos o armazenamento de objetos da Vercel para armazenar todas essas skills e disponibilizá-las sob demanda. Espero que ajude. Os sites mudam com frequência. Qual é a sua estratégia de STR para monitorar isso e manter a skill do site atualizada? Sim, essa é uma ótima pergunta. E é a isso que eu estava me referindo antes: como manter essas skills atualizadas, já que o site vai mudar? A hipótese de trabalho que temos no momento é que você não quer desperdiçar

38:17 tokens executando uma pesquisa automática todos os dias. Provavelmente, você quer acioná-la quando houver uma falha em algum ponto específico da produção, certo? Então, criamos esses loops, ou sistemas, em que, assim que encontramos qualquer falha em produção, executamos um loop de pesquisa automática para descobrir o que deu errado e corrigir o problema. Ele cria um pull request, que vai diretamente para um engenheiro humano, e ele corrige o problema automaticamente. A skill é atualizada. Então, sim, existe essa noção de falha em produção, quando isso pode acontecer. Mas há uma troca a considerar.

38:49 Você pode executar uma pesquisa automática ou uma execução de amostra a cada duas ou três horas para verificar se a skill está funcionando perfeitamente. Há diferentes maneiras de usar tarefas cron para verificar a precisão dessas skills. Na verdade, isso é algo que estou trabalhando ativamente para implementar com um cliente agora. E há todas essas questões, certo? As pessoas não querem 100% de precisão. Talvez queiram um custo dez vezes menor. Então, essa é a questão que

39:23 surge. Quais são os critérios do seu professor neste exemplo? Além de atingir o objetivo, parece que ele também faz algumas otimizações para reduzir o número de turnos. Que outros critérios você usa? Então, novamente, esse é o projeto do loop de pesquisa automática. Há uma maneira de dizer à sua pesquisa automática: “Ei, quero me concentrar apenas no sucesso. Assim que conseguir, está ótimo; é só me entregar.” Normalmente, não é isso que todo mundo quer fazer. As pessoas querem

39:53 minimizar a latência, talvez porque se trate de uma execução em tempo real e o foco seja concluir a tarefa o mais rápido possível. Então, se essa for a métrica de otimização e você se concentrar em fazer isso o mais rápido possível, já vi esses loops de pesquisa automática serem tão inteligentes que percebem que nem precisam do navegador: fazem engenharia reversa da API e a chamam, e essa é a maneira mais rápida possível de chegar ao resultado, certo? Às vezes, já vi situações em que encontram uma solução que funciona em 500 milissegundos.

40:28 Às vezes, a métrica é o número de turnos, certo? Você quer minimizar o loop de contexto e o número de turnos necessários para concluir a tarefa. No meu caso, acho que deixei a decisão de pausar ou convergir a seu critério, quando você quiser. Não estou realmente preocupado com os custos. O que mais me importa é a confiabilidade. Então, continue fazendo isso enquanto achar relevante; cabe ao agent professor decidir quando encerrar.

41:03 Mas, sim, você pode experimentar todas essas estratégias. Se um site oferecer suporte ao WebMCP, isso será usado? WebMCP é muito legal. É essencialmente este conceito. Não sei se todo mundo conhece, mas é o conceito de tornar seu site programável. Isso foi lançado recentemente nesta nova versão do Google Chrome: você informa ao seu site que, se alguém quiser fazer uma reserva, pode executar determinadas ações no site. É mais ou menos como uma API, mas

41:35 funciona no navegador. No momento, não acho que nosso loop de pesquisa automática dê suporte a isso, mas não acho que seja muito difícil fazer isso. Na verdade, lançamos recentemente o suporte ao WebMCP nos SDKs que lançamos. Também criamos algumas ferramentas para que os donos de sites implementem WebMCPs em escala. Mas, sim, esse é um caso interessante. Ainda não vimos muita adoção do WebMCP.

42:06 Verdade fundamental para determinar o sucesso. Interessante. Acho que, desde que a tarefa tenha sido concluída — por exemplo, se encontrou os voos mais baratos no Google Flights ou uma reserva no OpenTable —, ele se avalia sozinho. Normalmente, é uma avaliação binária. E, sim, novamente, acredito plenamente na bitter lesson. Tento não colocar muitas restrições nessas avaliações. Você já considerou oferecer um verificador como

42:41 serviço para tarefas de navegação, incluindo algo que nos permita simular certos efeitos colaterais, como compras? Talvez eu precise fazer uma pergunta complementar. O que você quer dizer com verificador como serviço? Ravish, se você estiver aqui. Sim.

43:29 Então, você quer dizer que, se entendi corretamente, há diferentes ambientes que pode usar para treinamento de RL e quer simular o que acontece se, por exemplo, eu estiver replicando a Amazon e clicar em “comprar”? O que acontece depois? Não, porque tentamos nos apoiar mais em sites do mundo real. A Browserbase tem

44:01 o privilégio de conseguir acessar a maior parte da web, graças ao nosso acesso a diferentes sites, a solucionadores de CAPTCHA etc. Então, tentamos imitar o mundo real tanto quanto possível. Mas temos visto muitos desses ambientes de RL em que as pessoas imitam sites para treinar e criar browser agents que são muito bons em navegar pelo Salesforce, muito bons em navegar pelo SAP. Nós tentamos fazer isso em portais do mundo real tanto quanto possível.

44:33 [fungada] É fácil para a skill passar pelos captchas do Edge ou isso exige muitos tokens? Qual é o objetivo dos captchas do Edge para os donos de sites? Se entendi corretamente, o captcha do Edge é um tipo específico de captcha, como o Google reCAPTCHA. Sim, provavelmente falaria disso separadamente. Acho que não podemos falar sobre quais captchas conseguimos ou não resolver. Mas não é um trabalho que consome muitos tokens, por assim dizer, porque é algo feito na camada de infraestrutura, certo? Não precisamos realmente usar uma IA para resolver um captcha. Ele é resolvido na camada do binário do Chrome. E fazemos isso por padrão.

45:04 Como o professor avalia quem executa a tarefa e quando as skills são consideradas prontas? Sim. Ele avalia quem executa a tarefa essencialmente lendo esses rastros. A cada iteração, é criada uma pasta. Há arquivos JSON. Ele lê esses arquivos, tem um loop do Claude Agent SDK e, essencialmente, identifica quais aprendizados vieram desse loop. Na verdade, acho que tenho um slide no final que fala disso. Sim. Este é mais ou menos o prompt para isso. Ele diz que você é um agent de automação de navegador. Você pode usar estas ferramentas, e o strategy.md é inserido a cada iteração. E é assim que o

45:35 executor, o professor, avalia o trabalho de quem executa a tarefa. Então, sim, ele lê os rastros, usa o system prompt e a estratégia anterior, e apresenta uma estratégia melhor. [fungada] Incrível. Espero que tenhamos respondido a todas as perguntas. Há mais alguma pergunta ao vivo sobre a qual queiram conversar? Sim.

46:10 Então, sim, ele lê os rastros, usa o system prompt e a estratégia anterior, e apresenta uma estratégia melhor. [fungada] Incrível. Espero que tenhamos respondido a todas as perguntas. Há mais alguma pergunta ao vivo sobre a qual queiram conversar? Sim.

46:44 >> Sim, pode funcionar com o SDK do Stagehand. Pode funcionar no Claude Code. É essencialmente um arquivo Markdown, certo? Peguei uma skill e pedi ao meu Claude Code: “Você pode encontrar eventos em SF para esta sexta-feira, 3 de julho?” E ele foi lá e fez isso. Então, não precisa usar o Browserbase. Não precisa usar o Stagehand. É essencialmente uma skill. É um artefato portátil que você pode usar em qualquer agent ou SDK.

47:30 Sim. Sim. Ótima pergunta. Acho que, se entendi corretamente, é: como vocês evitam prompt injection? Porque sites poderiam enganar meu loop de pesquisa automática e fazê-lo aprender algo ruim, capaz de provocar algum comportamento malicioso em um ambiente de produção. Há algumas maneiras de fazermos isso. Uma delas é na própria camada de infraestrutura. Temos várias proteções em nossos navegadores. Temos este modo seguro baseado no navegador

48:03 em que você pode controlar, de certa forma, quais URLs ele pode acessar. Você pode controlar que tipo de ações ele pode realizar em diferentes sites. Então, na camada de infraestrutura, no firewall de rede, controlamos essas coisas. Agora, você pode dizer que é possível que a Amazon.com seja hackeada algum dia. Como evitar ações maliciosas também nesses portais? Acho que também tentamos executar as skills geradas com uma espécie de agent revisor de segurança antes de realmente publicá-las em browser.sh. Então, essa é uma

48:37 maneira de fazer isso. Incentivamos nossos clientes a terem uma boa camada de proteção contra prompt injection, com uma área de exposição adequada, se forem disponibilizar isso para consumidores, por exemplo. Alguns de nossos clientes talvez queiram automatizar algo na Amazon. E se alguém publicar um anúncio na Amazon com instruções ocultas? Como evitar esse tipo de coisa? É aí que trabalhamos com nossos clientes para criar as proteções adequadas

49:09 antes mesmo de a instrução chegar ao harness. Então, sim, acho que eu colocaria três camadas aqui. Uma é controlar a consulta assim que ela entra em nossa superfície. Na camada de skill, garantimos que nossa skill não seja enganada; e, na camada de infraestrutura, temos restrições de rede e de ações. Você pode até fazer algo como o que Codex ou Claude Code fazem: “sempre

49:39 permitir”, “permitir uma vez” ou “permitir qualquer ação”. Isso é o que o modo seguro do Browserbase oferece pronto para uso. Sei que o navegador é um vetor de ameaças maluco quando você pensa nisso: ele tem acesso a tudo na web aberta. Levamos isso muito a sério do ponto de vista de prompt injection. Incrível. Vou esperar mais 10 segundos, caso haja outras perguntas. Foi divertido. Gostei muito. Também adoro esse tipo de pergunta. E

50:15 sim, vou colocar o código QR de volta na tela, caso alguém queira pegar isso. Sim. É. >> Sim. Sim. Exatamente. Sim. Acho que conversamos sobre isso há um tempo. O que você

50:49 poderia fazer é o seguinte: usei bastante o Managed Agents da Anthropic. Eu executaria um job do cron no Managed Agents e diria: “Use esta skill todos os dias às 9h para fazer este trabalho. Se der certo, ótimo. Se falhar, envie uma notificação para mim aqui”; isso acionaria um loop de autocorreção. É assim que posso incorporar verificações e contrapesos em relação a mudanças nos sites, mudanças nos sistemas antibot etc.

51:22 Vou ficar por aqui. Também estarei nos estandes do Browserbase durante todos os dias da conferência. Então, se tiver curiosidade e quiser conversar mais, vou adorar. Obrigado. >> [música]

Transcrição original

[00:00] All right. Hello. Thank you everybody for being here. Uh I know it’s the last workshop of the day. I appreciate all of you turning up here. U I am show uh I’m here to talk about hill climbing skills. uh specifically how can you improve your agents without really going into the models without really going in the

[00:33] weights. Uh I have a slido uh up here as well. I’ll just uh flash the QR code in case any of you want to uh put in any questions and we can address them towards the end as well. U a little bit about me. I’m Sh. I’m uh on the sales engineering team at browserbase. Uh I essentially work with our customers deploying browser agents in production. Uh I’m not sure maybe we’ll do a show of hands. Uh how many of you know what browser agents are?

[01:06] Anybody? All right, a few. Amazing. Uh have any of you built browser agents before? Have any of you used these tools? Show hands. Okay, a few of them. Amazing. Nice. uh maybe I’ll I’ll talk a bit about what browser agents are before diving into the whole concept of hill climbing for skills uh so that it becomes clear what we’re doing towards the end of the talk we’ll also look into how you can do this in your domain in your uh field as well.

[01:39] All right. Uh so quick primer on what browser agents are. If you have an agent that needs to drive a browser, you basically call that a browser agent, right? Browser becomes the tool to your agent. And how do you control it? You control it with some sort of CLI, some sort of MCP, some sort of method where you can control the browser and say, “Hey, go and click on this red button. Go and click on the refresh button. Go and uh take a

[02:09] screenshot or take a snapshot of the accessibility tree of this website.” Right? So these are this low-level tools that your agent can have access to to control the browser. Uh and browserbase is essentially a platform for you to build and run these browser agents. We provide the infrastructure and the SDKs, the skills, the CLI that go with building these browser agents. Uh and and we’re going to be using all of these tools to see what hill climbing does

[02:39] look like. All right. Uh I want to talk a bit about the biggest problem with agents today essentially reliability right uh people are frustrated with browser agents getting stuck or getting into an anti-border capture issue uh or maybe just forgetting or being lazy and not completing the task. Uh and we see reliability essentially is an engineering problem. I think the recent models the Opus and the Fable when we

[03:11] when it came out for those three days it was really really smart right uh but we see that a lot of the work that has to be done for reliability is the hardness around it is the tools that you give it it is the skills that you give here u and and that’s what we’re going to be sort of looking at how do we improve the reliability of these browser agents I wanted to give you all a few examples of like where these agents suck today, right? If I zoom in a bit, you’ll see this browser agent is trying to like go on Google flights and click on the uh

[03:47] it’s trying to drag the time filter and it’s unable to figure out how do I drag that. Dragging is a tricky operation for these agents to do and it’s getting super confused. It doesn’t know what the HTML element for that is, what the JavaScript for that is. It’s not really able to do this and it gets stuck and it’s not able to book my flight tickets. Uh, another example I wanted to show uh is a browser agent on open table. Let’s say I have my open claw or my Hermes agent and I need to book a date night and I tell hey go to open table and and

[04:18] find me some and and look at the anti-bot that it runs into, right? Uh, and it’s just like access denied. I don’t know what happens here. Uh, but like can my browser agent get around these issues? Can they be more reliable? And can they book my date night restaurants is the biggest question I wanted to ask here. uh and this is where we sort of look at different ideas to improve the reliability of these agents and one of them uh oh actually let’s let’s dig into the root cause here right like why this is happening u we have

[04:52] like these opus models these five five the super nice general purpose you might have used codeex computer use very nice but when you want to sort of do uh longunning tricky websites like the open tables or the Google flights it sort of becomes very difficult to run these in production and these sightspecific tricks or these javascript that you need to run on your browser the agent doesn’t know about them right and the most important thing is it’s every run starts from zero you’re not really having any sort of learning baked into your runs I

[05:27] think Darkh talked about this a couple days ago it’s like why is progress on computer use still so slow today. Uh although computer use seems like a verifiable problem, why is it still not solved? Essentially, there’s no learning happening. Every agent run is a start from scratch run and it’s not learning from its production traces. U and these browser agents, I call them geniuses that never learn. Um and some people might say, oh, why don’t you fine-tune on something some like open table or restaurant websites. Uh but it it’s not

[06:01] really scalable, right? uh if you’re thinking of building agents, you can’t really be fine-tuning for every new task that comes up. You want some you want a a modality where it can learn from its production traces uh and get better over time. This is where we sort of started thinking about and this was like six four to six months ago where Karpadi came up with this idea of auto research. This is essentially a loop, right? Uh and this loop sort of takes a verifiable problem statement and goes at it, tries

[06:34] it again and again, looks at its own traces and tries to improve itself. And we wondered how can we apply this to browser agents? How can we apply this uh to these complicated workflows, these complicated websites which are not deterministic, they change every day, they have different captures every time. Uh how can we learn from these? Right? Uh this is where I want to sort of switch into a demo and sort of show this live. Uh and I’m going to start with uh

[07:08] a prompt over here. So I want to maybe do something like uh go to Google flights and uh find me a business class flight from SF to New York for this Saturday. I want to have one carry-on bag. Uh and this flight should be in the morning. I hope my Okay, this is correct. Just paste this and run this. Right. So starting a browser based session here.

[07:40] Uh so what you see in the center is a remote browser has just spun up and has navigated to Google flights. If I expand my agent here, uh it’s doing all of these things. This is the reasoning traces that you can see live and it’s trying to sort of apply the business class filter. So it it’ll do its job and and and we’ll come back to this. Uh but I wanted to talk about what’s really happening here. Uh u and the architecture behind this auto research

[08:10] loop. So we we fired the Google flights task. Uh and and and the architecture here is this auto browse loop that we call this. We took auto research and we took browsing. We call it auto browse. And this loop essentially is two clawed agent SDK loop uh agents. Uh you can call one as the doer agent and one as the teacher agent. This doer agent its job is to actually go and do the browsing. It has access to the browse CLI that we talked about. It has access

[08:44] to the browser uh and it goes and sort of clicks on buttons, looks at the screenshot, tries to get me information and the teacher teacher’s job is to look at the traces of the doer and learn what went wrong and what went right and they keep working together until they find a very good solution that converges. Right? Uh we don’t tell it how many loops you need to go for. We don’t tell it what’s the success factor success uh rate that we want. We don’t

[09:16] tell it hey we need to do this within x number of tokens or x number of seconds. We just give it a broad prompt and we let the bitter lesson we embrace the bitter lesson and we’re like okay let the doer and teacher go at it. Uh and the key thing that happens is there is a strategy.md file. uh that is essentially the artifact across multiple runs. After every iteration, the teacher thinks about what happened, looks at the screenshot, looks at the logs, and then

[09:46] thinks, “Oh, you did not click on this button. U you should actually click on this button instead, and it puts that in the strategy.mmd file.” And that artifact carries over to the next iteration, and it improves from there. Maybe we’ll go back to our demo and see what happened. All right. So, iteration number one, uh, there was a failure here. Uh, and the learning from this iteration was skip the entire form calendar widget because you can just do a query parameter and you don’t really need to click around, right? The agent

[10:19] was smart enough in this instance to think, oh, I’m wasting so many tokens and I’m wasting so much time clicking around where I could just use Google Flight’s query parameter. Now this is obvious in hindsight but maybe as a human I wouldn’t have thought of this and I wouldn’t have written this complicated query parameter myself right uh so this is the learning from the first iteration now it’s going and doing things in iteration number two it’ll keep going on till it feels like it has maxed out all the tricks it has maxed

[10:50] out all JavaScript hacks that it could do uh and and and then uh think about okay this is the skill that I can use from here. I think the key the key thing uh that I wanted to also talk about is at the end of this converged loop the output that I want is a skill.mmd file. This skill.md file would be what I give to my future agents. Uh and it would have a

[11:22] collection of all the hacks or all the tricks or all the learnings from previous runs. We’ll we’ll look at what that scale might look like. Uh it could look like, hey, a pre-filled URL is mandatory. Don’t go around and waste your clicks and tokens clicking on these buttons. There is a reopen bug in the calendar. Don’t do this. Uh if you want to move the drag uh if you want to drag your time stamp thing, uh use JavaScript injection. Don’t try to do it with the

[11:53] mouse. Right? These are the kind of tricks that are now persisted for every future run and gives me so many more savings uh from a performance, reliability and cost perspective. Now uh we’ll go back to our uh run and see if it has passed. Okay, so iteration number two has passed and if you can see uh the savings in in cost are like 4x. Uh this chart is being created on the

[12:23] fly. Uh so it started from $12 and the second one was $3. And keep in mind my agents here are Opus 48 both for the doer and uh for the uh teacher. Now iteration three just came in. Uh the number of turns decreased. The latency is also better. Uh but there was a failure in iteration number three. there’s something that it sort of overcorrected on and iteration number four should probably be learning from that and we’ll see if it does that.

[12:55] Uh while it’s doing its own thing, I wanted to show some previous runs that I did uh just in preparation for this uh demo. U so for example, I went to uh auto browse and I was like hey go to the AI engineers website and tell me which talks and workshops are talking about hill climbing, right? uh and it did that across multiple iterations and you can see the replay of each of these. These are replays that are coming from browserbase super helpful important for uh observability perspective and as you can see uh it sort of uh got better in

[13:28] ter in terms of cost 7.4x 4x uh even though it was able to pass in all the iterations, I still got improvements in cost. Now I wanted to actually see what are the learnings from this skill, right? Uh how do you sort of uh persist all of these learnings? It says go straight to the shed schedule page. If there are open errors, don’t try retry blindly. Run this. Uh type the keyword into the session search input. Wait briefly. So like have these weights

[14:00] because sometimes websites take a lot of time to load. So you you can have these kind of tricks uh and then read the results. Uh you know like there there’s a lot of learning that is happening in these skills. Maybe I wanted to show some interesting ones. I wanted to show this open table one because I started with this blocker of like access denied when we started this demo. Uh and if we go to the uh screenshot, this was the access denied thing that we got right in in iteration number one. Let’s see how it

[14:31] learned from there. Uh it realized that the uh block is environmental because the website doesn’t want this agent to do something. uh in iteration number two, it figured that if I do a query parameter and if I put a latitude longitude metro ID, I automatically get that uh UI that works. Do not open /r that’s blocked and do not reload / s. These are the places where the blocks kick in. If you don’t do that and you follow this technique instead, your

[15:03] agent will work, right? Uh and as you can see, uh it sort of went from $6.22 22 to 0.51. The time taken went from $189 seconds to 27 seconds. Uh and the scale it came up with was here. Uh build the search URL, do the date math like this. Uh this is the known metro pins for San Francisco. Uh and and follow these steps, right? Never call / r because that will return

[15:34] access denied. Now these are the kind of learnings where a human could never have done but you just sort of embrace the bitter lesson and a let agents do the job uh and they will find these uh tricks for you. I want to uh also show uh a few examples of like the kind of improvements we see. Uh the reason why this problem is so close to my heart is because I from a sales perspective am deploying these browser agents into production. uh the

[16:06] sale is only done when the browser agent is successful. So reliability is like the most important thing for me and this is what I this is the key tool that I take to my customers and I’m like just fire your agents let them do this auto research thing and your agents will be successful in production. Uh and these are the kind of u success metrics that people are looking for up to 16x cheaper 12x cheaper 3x cheaper uh on different tasks. Of course, every task is different. The bottlenecks on each task are different. So, uh you might see

[16:37] variance there. But the idea is you can hill climb on these uh techniques. I wanted to go back to our live demo and see if there’s any uh improvement. All right. So, we have a graduated skill u and the skill applied end to end. No further learning. The results are showing correctly. one-way business class, San Francisco to New York, July the 4th, one carry-on bag included. Uh, and there is 8 a.m. $649. Right? So, it was able to get all of this and I can

[17:11] sort of watch the entire replay to see if that is accurate. Uh, it was able to sort of figure out this entire skill and the fast path is encode the whole query in the URL. strongly preferred the again like I know I’m I’m showing these things but when I first started looking at the the results here this was like my moment of like this is the mythos moment for browser agents you know like just reverse engineering the hell out of things uh I I look at this with some of my customers the customers are mind-blown uh earlier they would be

[17:45] writing scripts for each of their websites they would be like hey I need to spend so many engineering hours on like just reversing these websites. How can I scale this to 100 a thousand websites and now our customers have actually built these entire pipelines of uh these skills that get generated on the fly pull requests that get created automatically. If there is a failure in production, an agent kicks in and starts healing the skill as well. So there’s a

[18:15] lot of uh engineering that we can do around this to make leverage to leverage this technique. Uh I wanted to also show what we’ve done with this right we actually went ahead and created this product called browse.sh uh we were like if we can do this for one website we can do this for five why not do this for like 500 websites and give it for free for anybody to do this. Uh and like if you remember in the 19 or wherever like in the ’9s before internet you had the yellow pages uh you had

[18:49] details about accessing people, businesses etc. This is yellow pages for browser agents right it has details about how to do any task on any website on the web. U I wanted to actually show this to you all. uh you can actually install browse CLI and use all of these skills completely for free. We’ve eaten up the token costs ourselves and we’re making this available for you all. Uh so if I go to let’s say search products on Amazon uh I

[19:23] can see the entire scale is over here. When should you use the scale? How should you look at like pricing and availability and whatever right? uh this is how you use this lot of details about Amazon the screenshots u and I just give this browse skills CLI to my openclaw and it just knows when to pull the alltrails.com skill when to pull the weather.gov skill and and this makes my life so much easier. uh we essentially are running the same auto research loop

[19:56] behind the scenes uh and making this uh available for you all. In in fact if you would want to you can go here and you can be like hey go and make a skill for me to uh look up this uh events in San Francisco for this week. Uh you do this generate a skill and this will sort of do this for you. This will send you an email and you can then use your skill uh in whatever agent you want to, right? Uh so we’ve done this for browser agents. Uh and I wanted to talk about like how

[20:30] can you potentially do this for any other domain, right? Uh I think coding agents is like one place where I have seen this frustration where the agent is relearning the repo conventions every time. it’s not applying the linting rules correctly and I have to tell it every time and maybe you can have your cloud MD and agents MD and improve that but the the fundamental premise is like the agent should not be relearning your tasks from zero right uh I’ve seen this

[21:04] in research agents we run a bunch of like deep research agents for our internal workflows uh and every time it struggles and it tries to relearn oh I pulled this information from Wikipedia IA uh but I did not pull it from this other website. Uh I was like why not? Uh like we always do this other website you should learn from your previous traces. Uh and you should pull information. Uh internal ops you have all these dashboards all these databases all these internal tools but your agents don’t know which ones work and which ones are

[21:37] preferred. Ideally you should be applying this all research technique. Uh a and the two conditions that are required is that a you should have a replayable environment of some sorts so that you can run these loops and b you should have some sort of verifiable outcome some sort of quant quantifiable metric for you to run these loops. Yes, I see a question there.

[22:18] I realized that Yeah. >> Yeah. >> Yeah. Exactly. Uh so I think the question is like how do you know that the auto research loop is accurate

[22:51] whether it is converging and when it says it’s converging it’s actually converging. When it says it’s good it’s actually good. When it says it’s bad it’s actually bad. like how do I have confidence uh on what the agent is saying and what the loop is doing. I think that’s where I want to sort of talk about the verifiable outcome here. Uh for Karpathi, it was quite easy because he was looking at the log log loss of the experiment when he was training neural networks. Right? So it’s very easy to see whether your log loss has gone down or not. Uh but in many real world scenarios that is not the

[23:24] case for browser agents. As I explained, uh, whether you book a flight ticket or not, that might be straightforward, but did you find the best flight options for me might be slightly fuzzy uh and might not be the best uh

[24:05] Yeah, if if I understand this correctly, you’re saying like one mistake in the loop can sort of throw off the entire auto research run. Uh and how do you prevent against that? I I I have actually seen where some uh iterations actually fail. uh for example if we uh look at the previous slide uh there’s like failures happening after there have been successes right uh so it’s not always that once you succeed all the future iterations will always be

[24:38] successful but I think it’s the design of your loop where you can make it resilient to u failures uh where it doesn’t overindex on those uh and still sort of correct protects itself uh from any mistake that happened in previous runs. Uh I think we’re trying to sort of prevent like uh what do they call like exploding sort of loss sort of scenarios. Uh I think you could do that. Uh in fact Karpathi talks about this like this is one way of doing auto

[25:10] research. You can actually auto research on different ways of doing auto research itself. Uh it’s like is the teacher doer loop the best? Should there be a multi-agent architecture to do this or is there any other approach that might actually work better for research tasks in neural networks versus browser agents? Right? You could have different designs of your loops to prevent situations like those. Uh and I think going back to my point, as long as you have a verifiable outcome or some quantifiable metric, I think you should

[25:40] be able to design uh a good uh loop here. uh replayable environment I think sometimes is under discussed uh but extremely important. I think he was talking about Darkh he said having a verifiable outcome is important but also you should have uh extremely grindable environments or extremely grindable uh use cases as well. Right? If your agent cannot uh grind through failures, it will be difficult for it to uh go for multiple

[26:15] iterations and fix itself. Uh so do you have like coding agents is a good example because you can start from a docker image or you can start from uh a particular EC2 and and you can replay from different parts of the uh stack. Uh but maybe uh knowledge work is probably not that easy to replay. uh maybe there’s like a lot of different human in the loop actions that make it very hard to replay from a particular point in time. So investing in your environment also can be super uh rewarding in these cases.

[26:52] Amazing. Uh I just wanted to share the uh URLs of uh the auto browse loop that I uh demoed today. So if you scan the QR you’ll be able to pull the uh GitHub for that. Uh and also the second QR here uh is the skill itself. You can just do /auto browse on your claude code or codeex and be like hey /auto browse use opus48 on both of these uh teacher and doer and go create a skill for me to do this. Uh

[27:25] I’m looking at one of these questions. Uh and also if any of you have ideas of something we want to sort of put the agent against feel free to type it in the slido and we can actually try it live. Uh but let’s look at this question. Is there a way to optimize for convergence? Uh I think this is the same question that we were just talking about. Uh high cost is interesting because you might think that u doing longer iterations might become costlier over time. Uh I have run a bunch of evals on

[27:59] this where I can throw a sonnet at this problem but run it for longer iterations versus throwing opus for lesser iterations. I think you can get the same job done by throwing sonnet larger number of iterations but still cheaper overall. Uh also this cost is amotized right like one auto browse loop that we probably run is like maybe $30 $40 if it’s super complicated $100 at most. Uh so this is amotized as long as those costs make sense for you uh to deploy

[28:31] this in production uh just go for it. Uh but there’s a lot of interesting things uh that you could do uh with evaling the kind of loops that you’re generating. Uh yes I will share the slides as well. Uh I can do this on the GitHub itself. Uh can you share how you thought about uh auto research into auto browse? Uh I mean the process was fairly straightforward. Uh took the GitHub repo that Karpathi put out uh and then

[29:03] there’s all this context about my customers uh that I have uh where I was like hey these customers face these kinds of reliability problems uh the way I solve it for them is I go into their office I sit with them very forward deployed uh and I try to sort of just brute force and reverse engineer this. This is what I do. So I am the teacher agent. Uh can you automate me out of the process and create a loop borrowing from uh Karpathi and and and and build the

[29:33] same thing? And of course there’s a lot of iterations on top of that. Uh there’s a lot of engineering as well uh to simplify this. Uh but yes, that was the process of converting this. Can you use this in a proxy? Can you be logged into a site? Yes. Uh again this goes back to the environment that you design. Uh browserbased the infrastructure that all of this is running on uh gives you the ability to log into websites uh save the cookies uh reuse those cookies in future runs so

[30:05] you don’t have to log in every time. Uh makes it super easy for you to uh replicate real world workflows. Uh and yes you can use proxies as well. If you have uh particular IP addresses, residential IP addresses, you can bring those in as well. Uh a lot of success is definitely how good your infrastructure and environment is, especially in these adversarial scenarios, uh like captures and antibots. Uh so making the infrastructure as good as possible is

[30:35] definitely of value. Amazing. any any asks for something that we might want to run live? Yes. Question. >> Great, great question. Actually, I wanted to sort of show the code as well. Uh so if you uh look at the GitHub, you’ll be able to find this evaluate.mjs file. Uh essentially, it lists out the entire

[31:09] loop. Uh what’s happening here? Uh but to answer your question, the teacher and the doer are u working one after the other for every loop. So the teacher is finding learnings in every iteration. Uh maybe if I show the demo uh over here uh let’s go to the one we just did. Iteration one had these learnings and then iteration two had some other learnings. Right? you should include the

[31:40] explicit ISO date in this particular format. Iteration three would have some other learnings. The date resolution still opens the bare page and clicks wasting three turns uh reading today’s date uh or having the executor compute today. So it’s figuring out something about the date time. So in every iteration the teacher is learning something new and putting this back into the strategy.mmd. Maybe I’ll make this real by looking at the traces for one of these runs. Uh so

[32:12] over here these are all my runs. Uh so for example this was the open table reservation example u and uh this was the strategy.mmd that the teacher sort of appended to every time. So uh step zero you should do this so on and so forth. Uh this was the task this was the uh prompt that I gave it. Find me reservations for the big B bigs restaurant. uh and these were the kind of traces that uh it was sort of learning from. It would take screenshots would take these sort of traces at every step is doing browse open this is what

[32:47] the output is. Then turn number two browse snapshot. Snapshot essentially takes the accessibility tree and this is the snapshot. So it’s reading this entire thing and at every step thinking of like what went right and what went wrong. U yeah I mean this is like machine code. uh I won’t show this entire thing. Uh but yeah, this is the summary that it also writes uh at every iteration. Uh so yeah, this there’s a lot lot of like engineering tweaks that you can do to suit this to your domain as well. U and uh like the easiest way

[33:21] to uh read this is we put it out here on skills.sh as well uh in auto browse u and you can sort of do something like this.

[33:54] Great question. Such a good question. I think that goes back to like how do you increase the reliability of your uh agents. Uh reliability is an engineering problem. Uh you can design your harness to sort of go for one skill for each task or you can be like hey one skill for every task that you will ever

[34:25] see. Uh I think it entirely depends how you do the harness engineering entirely depends on the use case that you have u and you run evals with all these different strategies uh and see which one works for you. for us. This was Yeah.

[34:55] Yes. >> Yeah. Yeah. And this is where again the harness comes into the picture. If the harness has the intelligence to bring in skills from Open Table and from Resi and Google res Google reservations, maybe it can bring all of those in to figure out what is the best way to book me a date night. That’s your solution, right? Like the harness should be able to uh figure out

[35:26] which tools to use to get the job done. That’s like how I would go about it. uh figure out what are the most common use cases that your customers have for those use cases. What’s the best scale files, prompts, tools, maybe you want to do like specific tools for specific use cases, right? Maybe you want to do generic tools for all use cases. Like that’s the same argument here is like do you do one skill for each or one skill for all uh and eval across all of these strategies and and let the hardness figure it out.

[36:01] Yes. >> Yes. Yeah. I mean it’s a very similar concept as this, right? Uh so DSPY. >> Yeah. I I think those guys were on to something really cool like they were around like 3 four years ago where they started building DSP and Japa all of that. I think uh we have been doing a lot of research uh along these lines as well. Browserbase works with uh Microsoft. We actually released a paper uh about how to build the right sort of verifiers uh for your agents. Uh I think running evals is straightforward until

[36:36] you start questioning okay how should I eval my eval right like do I need to put all these humans to verify all these runs or is there a good verifier that I can build here and all of that u uses the uh learnings from uh these papers as well. I can share all of that in the GitHub as well. I’ll also see if there’s any new questions here. Where and how were these skills stored retrieved at scale. Uh right now for

[37:10] this repo uh all of these get stored in my cloud over here. So each of these is a scale file. This was my recipe searcher. Uh I wanted to build some I wanted to cook some dinner yesterday. So I was like, “Hey, make me some recipes.” Uh, so all of these are currently in my local uh skills folder. Uh, but if you want to ship this uh in production, of course, you can uh bake this into your agent loop. Uh, or if you want to I think for browse.sh the public uh publicly available uh skills that we

[37:45] have, I think we use versel blob storage to store all these skills uh and make them on demand. Hope that helps. Uh, websites change frequently. What’s your STR strategy for monitoring that and keeping the website skill updated? Yeah, this is such a great question. Uh, and this is what I was alluding to earlier is like how do you keep these skills up to date because the website’s going to change. The the current working theory that we have right now is you don’t want to waste

[38:17] tokens running auto research every day. you want to probably trigger or if it’s failing at any particular point in production, right? So, we build these loops or like systems where as soon as we run into any production failure, we run an auto research loop to see what went wrong to heal it, create a pull request, that goes directly to a human engineer and they fix it automatically. The skill gets updated. Uh so yes there is that notion of like production

[38:49] failure when this might happen. Uh but it’s a trade-off. You can run an auto research or you can run a sample run every 2 hours every 3 hours to see if the skill is working uh perfectly. So there’s different ways of having the uh cron jobs uh check for the accuracy of these skills. This is actually one thing that I’m actively working on with the customer right now to implement. And there’s all these questions, right? People don’t want 100% accuracy. People might want like 10x cheaper cost. So like uh that’s the uh question that

[39:23] comes up. What’s your teachers criteria here in the example? Separate from reaching the goal seems to do some optimizations for turns. What other criteria do you use? Uh so again this is the design of the auto research loop. Uh there’s one way of telling your order research that hey I want to focus on just success. As soon as you get me success I’m fine just give that to me. Uh that’s typically not what everybody wants to do. Uh people want to

[39:53] minimize on uh latency. Uh because maybe this is a real time run where you’re focused on how quickly can you get the job done. U so if that is the optimizing metric and you focus on getting it as fast as possible. What I’ve seen sometimes these auto research loops are so smart they realize that browsers are not needed at all and they just reverse engineer the API and they fire the API and that’s the fastest that you’ll ever get to. Right? Uh so sometimes uh I’ve seen situations where uh it finds a solution that works in 500 milliseconds.

[40:28] U sometimes it is the number of turns, right? you want to minimize your context loop uh and you want to minimize the number of uh turns it takes to complete the task. Uh in my instance, I think what I have done is it’s your decision to pass or converge whenever you want to pause it. I’m not really concerned about the costs. Uh I care most about reliability. So keep doing it as long as you feel it’s relevant and then it’s the teacher agent’s job to uh call it day when it wants to.

[41:03] But yeah, you can uh try all different strategies. Uh if a website supports WebMP, will this use it? WebMCP is so cool. U it’s essentially this concept. I don’t know if everybody knows this, but it’s this concept of like making your website programmable. It’s it’s come out in this new Google Chrome release recently where you tell your u website that if anybody wants to book a reservation they can do xyz on the website. It’s kind of like an API but

[41:35] it’s on the browser. Uh right now I don’t think our oral research loop supports this. Uh but I don’t think it would be uh too hard to do that. Uh in fact we recently shipped support for WebMCP with our SDKs that we launched. Uh we also made some tools for website owners to ship web MCPS at scale. Uh but yeah this is an interesting one. We’ve not really seen a lot of adoption with Web MCP as yet.

[42:06] Uh ground truth for pass. That’s interesting. Uh I think as long as the job was done as long as for example in Google flights uh if it found the cheapest flights in open table if it found a reservation uh so it it evaluates itself. It’s typically a binary uh and yeah again I I I fully embrace the bitter lesson. I try not to put many guardrails in uh these evaluations. Uh, have you considered a verifier as a

[42:41] service for browsing tasks, including something that allows us to mock certain side effects like purchases? Uh, I might have to ask uh a followup on that. What do you mean by verifier as a service? Ravish, if you’re here. Yes.

[43:29] Uh so uh do you mean that yeah if I understand this correctly like you have like different environments that you can use for RL training and you want to like mock what happens if I am replicating Amazon if I click on purchase what happens after Uh no because uh we try to rely more on real world websites. Uh browser base we

[44:01] have the privilege of being able to access most of the web with our uh access to different websites uh and capture solvers etc. Uh so we try to mimic the real world as much as possible but we’ve been seeing a lot of these RL environments where people are mimicking websites to train uh and build browser agents that are uh really good at like browsing Salesforce, really good at like browsing SAP. Uh we try to do that on real world portals as much as possible.

[44:33] [snorts] Are edge captures easy for the skill to move past or is it token incentive? uh what is the point of edge captures for website owners? Edge capture if I’m understanding this is like a particular kind of capture. It’s kind of like Google recapture etc. uh yeah I would probably talk about this separately. Uh I don’t think we can talk about like what it what captures we can solve or not. Uh but it’s not a token inensive job per se because it’s an inf like it’s thing that’s done at the

[45:04] infrastructure layer, right? uh we don’t really need to use an AI to solve a capture. Uh it’s solved at the Chrome binary layer. Uh and we do that out of the box. How does the teacher evaluate the doer and when is the skill markers graduated? Yes. So uh it evaluates the doer by essentially reading these traces. Uh for every iteration there is this folder that gets created. uh there are these uh

[45:35] JSON files. Uh it reads these uh it has a clawed agent SDK loop uh and it essentially figures out what the learnings from that loop are. Uh actually I think I have a slide that talks about this at the end. Yeah. Uh this is kind of like the prompt for this uh where it says that you’re a browser automation agent. You can use these tools uh and the strategy.md gets injected at every iteration and this is how the uh

[46:10] uh doer the teacher evaluates the doer’s job. Uh so yeah it reads the traces it has the system prompt it has the previous strategy and it comes up with a better strategy. [snorts] Amazing. Uh I hope we’ve covered all the questions. Uh any other questions live that we might want to talk about? Yes.

[46:44] >> Yeah, it can work with the stage hand SDK. It can work in your cloud code. Uh it’s essentially a markdown, right? Uh I took uh a skill and I told my clot code, can you find events in SF for this Friday, July the 3rd? and went on and did this. So it it need not use browser base. It need not use stage hand. It is essentially a skill. It is a portable artifact you can use in any agent or any SDK.

[47:30] Yeah. Yeah. Great question. I think if I understand this correctly, how do you prevent against prompt injection? Uh because websites could trick my auto research loop in learning something bad that can do some malicious behavior in in a production setting. Uh there’s a few ways we do that. One is at the infrastructure layer itself. Uh we have a bunch of uh protections around our browsers itself. Uh we have this browserbased safe mode

[48:03] where you can sort of control which URLs it can go to. You can control what kind of actions it can take on different websites. So at the infrastructure layer, at the network firewall, we control things. Now you might say that it is possible that Amazon.com gets hacked someday. How do you prevent against like malicious actions on those portals as well? Uh I think we also try to uh run our skills that are generated against some security uh reviewer agent of sorts uh before we actually publish this on browser.sh. Uh so that’s like

[48:37] one way of doing it. uh we encourage our customers to have uh a good level of uh prompt injection guardrail uh surface area uh if they’re sort of giving this out to c consumers uh for example some customers of ours uh might want to automate something on Amazon and what if somebody puts uh a listing on Amazon which has some hidden instructions and how do you prevent against those kind of things uh and that’s where uh we work with our customers to build the right

[49:09] kind of uh guardrails before the uh instruction even reaches the hardness. Um so yeah I think I would put like three layers here. One is as the as the query is even entering our surface area we control that at the skill layer we make sure that our skill is not uh tricked and at the infrastructure layer we have network restrictions and action restrictions. You can even do something like what codeex or plot code does u like always

[49:39] allow or allow once or allow any action. Uh you can this is what like browserbased safe mode offers out of the box. I know browser is a crazy threat vector when you think about it like it has access to anything on the wild web. Uh and take that super seriously from a prompt injection POV. Amazing. I’ll wait for 10 more seconds if there’s any other questions. This was fun. I really enjoyed this. I love the kind of questions as well. Uh

[50:15] and yeah, I will put the QR code back on screen in case any of you want to grab this. Yes. Yeah. >> Yeah. Yeah. Exactly. Yeah. I think we talked about it a while back. What you

[50:49] could do is like I used uh entropic managed agents quite a bit. Uh so I would run a chron job on managed agents where I would say use this skill every day at 9:00 am to do this job and if this is a success all good if this is a failure send me a notification here that will trigger a healing loop uh so that’s how I sort of can bake in uh checks and balances around websites changing antibbots changing etc.

[51:22] I’m going to hang around here. Uh also uh I’ll be at the browserbased booths all days of the conference as well. So uh in case you’re curious and want to chat more uh love to do that. Thank you. >> [music]