Hill-Climbing Skills: Improve Agents Without Changing the Model — Shubhankar Srivastava, Browserbase

A Google Flights agent reaches the time filter and cannot drag it. An OpenTable agent tries to find a date-night restaurant and meets “access denied.” These are the opening problems in Shubhankar Srivastava’s workshop. His work on Browserbase’s sales engineering team involves getting browser agents into production, where a clever attempt is useful only if it completes the job.

A browser agent gives a model tools to operate a browser: click, refresh, capture a screenshot or inspect the page’s accessibility tree. A CLI, MCP interface or SDK exposes those operations. The harness—the software around the model—determines which tools and instructions the agent receives. That makes reliability partly an engineering problem: a model may understand the request while lacking a dependable way to manipulate this particular website.

The recurring waste is that each run starts from zero. A previous attempt may have discovered a useful URL, a calendar bug or a necessary wait, yet the next attempt has to discover it again. Srivastava calls these agents “geniuses that never learn.” Fine-tuning for every new website and task would add another training burden. His alternative borrows the autoresearch idea: repeat a verifiable task, inspect what happened and carry useful lessons into the next attempt without changing model weights.

The live task is concrete: find a business-class flight from San Francisco to New York for “this Saturday,” departing in the morning, with one carry-on bag. A remote browser opens Google Flights, and the agent starts applying the business-class filter. While it works, Srivastava explains AutoBrowse’s two-agent architecture, built with the Claude Agent SDK.

The agents have different jobs:

• Doer: Operate the browser through the Browse CLI, inspect screenshots and collect the requested information.
• Teacher: Read the doer’s traces, screenshots and logs, identify what worked or failed, and write lessons into strategy.md.

That file survives between attempts. A correction such as choosing a different button becomes an instruction available to the next run, rather than an observation lost with the previous conversation.

What crosses the boundary between attempts? The diagram separates the evidence produced by browsing from the instructions produced by teaching. The doer and teacher alternate; the persistent strategy carries information forward. In this demonstration, the prompt does not prescribe an iteration count, target success rate, token budget or time limit. The teacher has broad discretion to decide when further learning is no longer useful.

Iteration one fails, but it produces a useful correction: skip the form and calendar widget by encoding the search in URL query parameters. The change removes repeated UI work. Instead of spending turns locating controls, clicking dates and checking intermediate states, the next attempt can open a prefilled search directly. The recording describes the shortcut without supplying its parameter syntax.

The intended final artifact is SKILL.md, a reusable collection of discoveries from the attempts. For this flight workflow, candidate instructions include requiring a prefilled URL, avoiding a calendar reopening bug and using JavaScript to manipulate the time control instead of dragging it with the mouse. These are distinct corrections: avoid unnecessary interaction, avoid a known bad state, and choose a more dependable interaction method when a control remains necessary.

Does cheaper execution also mean successful execution? The live chart makes that distinction worth inspecting. Iteration two passes, with reported cost falling from $12 to $3—a fourfold reduction. Iteration three uses fewer turns and has better latency, yet fails. Srivastava suspects an overcorrection and waits to see whether the next attempt repairs it. The immediate result is uneven progress: efficiency improves before correctness is stable.

While the flight run continues, an earlier conference-search task shows why optimization can continue after the first pass. The request was to find talks and workshops about hill climbing on the AI Engineer website. Every displayed iteration passed, yet Srivastava reports a 7.4-fold cost improvement. Browserbase replays let him revisit each attempt and inspect how it reached the answer.

The resulting schedule skill records a short route through the task: go directly to the schedule, avoid blindly repeating failed open operations, type the keyword into the session-search input, wait briefly, then read the results. The wait matters because a search interaction and its rendered results need not happen at the same instant. A useful skill preserves timing behavior as well as navigation choices.

The OpenTable example starts with an access-denied page. On the second iteration, the agent finds a working search route using query parameters containing latitude, longitude and a metro ID. Its instructions preserve both positive and negative knowledge: construct the search URL, compute the date, use the known San Francisco location values, avoid the restaurant-detail route described as /r, and do not reload the search route described as /s. What makes this skill useful is the relationship between entry point and outcome: some navigation paths trigger the block, while the demonstrated search path reaches a usable interface.

For that restaurant run, reported cost falls from $6.22 to $0.51 and elapsed time from 189 seconds to 27 seconds. Other examples show different cost reductions, including up to 16-fold. These are task-specific results, with different bottlenecks; they do not establish a general success rate or a guarantee that the same navigation choices will work on another site.

Back in the live run, the skill has graduated: the system reports that it applied the instructions end to end without finding further lessons. What did the search actually return? Srivastava reads out a one-way business-class search from San Francisco to New York for July 4, with a carry-on included, and an 8 AM option at $649. The replay provides a way to inspect that result. This demonstrates a completed search, rather than a purchased ticket.

The skill’s preferred fast path is to encode the whole query in the URL. This automates some of the site investigation that customers previously performed by hand, writing scripts and reverse-engineering each website. Srivastava describes customer pipelines that generate skills and pull requests automatically, then start another repair attempt when a production run fails.

Browse.sh packages this idea as “Yellow Pages for browser agents”: a catalog of task instructions that agents can retrieve when needed. An Amazon product-search skill, for example, explains when to use it and how to inspect pricing and availability. The demonstrated catalog also includes skills for AllTrails and weather.gov. At the time of the workshop, Browserbase offers the skills through its CLI for free, absorbing the generation costs, and offers a workflow for requesting a new skill and receiving it by email.

The same repeated discovery appears outside browsing. Coding agents forget repository conventions and linting rules. Research agents repeatedly miss a source the team always uses. Internal-operations agents rediscover which dashboards, databases and tools are preferred. Files such as CLAUDE.md and AGENTS.md can carry those lessons, but improving them through repeated attempts requires two things: a replayable environment and a verifiable outcome or quantifiable metric.

An audience question exposes the difficulty hidden in “verifiable.” A training experiment can compare log loss numerically. A browser workflow may make it straightforward to check whether a ticket was booked, while leaving “Did you find the best flight?” unresolved. The attendee presses on a narrower failure too: a copied URL or number can change by a character and become wrong. Correct task interpretation does not ensure faithful extraction of the data needed to complete it.

The response returns to resilience across attempts: successes can be followed by failures, and the loop should recover without treating one bad attempt as the final lesson. Different loop designs may suit different domains. That is a design direction rather than a demonstrated solution to character-level copying errors; the discussion does not establish an independent check that catches those errors.

Replayability has its own engineering cost. A coding task can start from a Docker image or a particular EC2 environment and repeat from a known point. Knowledge work involving human decisions may be much harder to restore. Srivastava’s term is a “grindable” environment: the agent needs enough repeatable attempts to work through failures. Investing in that environment makes the learning loop possible.

Model choice and iteration count interact. In Srivastava’s experiments, Sonnet can take more iterations than Opus while still completing the task at lower total cost. He estimates a typical AutoBrowse learning run at roughly $30–$40, with very complicated examples reaching about $100. Those are his observed costs, not a pricing bound. The investment makes sense when later uses of the generated skill repay the discovery work.

The teacher role comes from an existing human workflow. Srivastava would sit with customers, inspect failures and reverse-engineer the website until the automation worked. AutoBrowse began with the question of whether an agent could take over that diagnostic role using the autoresearch pattern. The subsequent work involved repeated engineering changes to simplify the loop.

A good strategy still depends on a usable environment. Browserbase can preserve login cookies for future sessions and use supplied proxies, helping repeated attempts resemble the intended workflow without logging in every time. Those infrastructure choices matter especially when anti-bot behavior changes what the agent can reach. Improving the instructions alone cannot replace the environment they depend on.

The implementation’s evaluate.mjs contains the loop, with the doer and teacher running one after the other on every iteration. Returning to the flight example reveals corrections more specific than “use a URL”: include an explicit ISO date, and avoid opening the bare page and spending three turns resolving today’s date. Date resolution itself becomes part of the strategy, reducing repeated work before the search even begins.

What evidence supports those corrections? The reservation example exposes the task prompt, the accumulated strategy.md, screenshots and step-by-step tool outputs. A browse open operation records its output; a subsequent browse snapshot captures the accessibility tree. The teacher can inspect the sequence of actions and page responses, then write an iteration summary. This is richer diagnostic material than a final pass/fail label: it can reveal the particular navigation or observation that needs to change.

An audience member challenges the task-by-task framing: users often ask for something that spans several tasks. A date-night request might require comparing more than one reservation service. Srivastava’s proposed answer is skill selection and composition in the harness. It could retrieve relevant instructions for OpenTable and Resy, then choose tools that serve the larger request. A task-specific skill is useful knowledge, but it does not by itself plan the whole job.

There is no single recommended granularity. Separate skills, a more general skill, specialized tools and generic tools are alternatives to evaluate against common customer requests. The discussion connects the approach to GEPA and DSPy, then returns to the evaluator problem: a verifier also needs evaluation. Srivastava mentions verifier research with Microsoft and raises the choice between human review and an automated judge; he does not give the paper’s method in this recording.

Storage is a separate concern from learning. In the demonstrated repository, generated files live in a local .claude skills folder, including a recipe-search skill. A production agent can incorporate the files into its own loop. For the public Browse.sh catalog, Srivastava says he believes Vercel Blob stores the skills for on-demand retrieval; the talk does not develop a retrieval or ranking design.

Website changes make a successful skill perishable. The working maintenance approach is to trigger AutoBrowse after a production failure, diagnose the problem and generate a pull request for a human engineer. Scheduled sample runs every two or three hours offer another way to discover breakage. The tradeoff is detection speed against the cost of continually checking or relearning behavior; Srivastava describes this monitoring work as still being implemented with a customer.

The teacher also needs an objective. Several goals can lead to different stopping decisions:

• Task success: Stop when the requested job succeeds.
• Latency: Keep looking for a faster route. Srivastava has seen loops discover that an API can replace browser interaction, with some solutions taking 500 milliseconds.
• Turns: Reduce the number of model-tool exchanges and the context needed to complete the task.
• Reliability: Continue investigating beyond the first success when dependable repetition matters most.

The 500-millisecond observation is an example of a discovered fast path, rather than a benchmark for AutoBrowse generally.

For the demonstrated setup, reliability takes priority over cost, and the teacher decides when to stop. That explains why a pass does not immediately end learning—and why the earlier faster-but-failing iteration matters. A system that minimizes turns can prefer a different strategy from one that seeks dependable completion.

WebMCP offers another possible route to fewer brittle UI operations: a website can expose programmable actions through the browser. At the time of the workshop, Srivastava says Browserbase’s SDKs support it, but he does not think the AutoBrowse loop does yet. This distinguishes an available SDK capability from behavior demonstrated in the learning loop.

Asked about ground truth, he describes a typically binary, self-evaluated result: did the agent find the flight or reservation? That remains a model judgment in this setup. Calling a flight the cheapest requires stronger evidence than finding a plausible matching option, just as the earlier discussion distinguished booking a ticket from finding the best one. Graduation should be read within that scope, rather than as an independently measured guarantee.

The environment is deliberately close to live use. In response to a question about mocking side effects such as purchases, Srivastava says the approach favors real websites over replicated training portals. He also places CAPTCHA handling in Browserbase’s infrastructure, at the Chrome binary layer, rather than in the agent’s token-consuming reasoning. He declines to specify which CAPTCHA types it can solve.

The graduation mechanism returns to the same concrete inputs: per-iteration folders contain JSON traces; the teacher reads them alongside the system prompt and previous strategy, then proposes a better strategy. The talk supplies no fixed numerical graduation threshold. Once produced, the skill is a Markdown artifact that can be used with Stagehand, Claude Code or another agent. Srivastava demonstrates that portability with a San Francisco event-search request; it does not require using Browserbase to read the instructions.

Prompt injection creates a failure mode specific to learning from the web: malicious page content could influence an attempt and then become a lesson reused in production. An Amazon listing with hidden instructions is the concrete example. Restricting the agent to a familiar domain does not settle the problem, because malicious content can appear within that domain.

Srivastava describes three places to apply controls:

• Incoming content and requests: Add checks before potentially malicious instructions reach the harness.
• Generated skills: Run a security-review agent over skills before publishing them to Browse.sh.
• Browser infrastructure: Restrict destinations and permitted actions through network controls and Browserbase safe mode, including permission choices such as allowing an action once or persistently.

The layers address different paths to harm: what reaches the agent, what it preserves, and what it can execute. The talk describes the controls without establishing that they eliminate prompt injection.

The final audience question returns to skills that grow and become outdated as the browser, website or development environment changes. The proposed operational check is simple: schedule the skill to perform its job every day at 9 AM; leave a successful run alone, and send a notification on failure to trigger a healing loop. This detects observed breakage and connects it to repair. It does not, by itself, solve skill growth or guarantee that an apparently successful result is still correct. The reusable file therefore needs continued execution checks and the human review described for repair pull requests.