Shubhankar Srivastava builds browser-agent tools at Browserbase and previously co-founded Houseware, a warehouse-native product analytics company acquired by LaunchDarkly. His AutoBrowse project explores how agents can improve between attempts without changing model weights: inspect what happened, preserve lessons in a strategy file, and give the next attempt those instructions.
Houseware brought product analytics to the cloud data warehouse. In his writing on its open architecture, Shubhankar describes how APIs let customers build custom dashboards, automated reporting, and predictive applications while retaining data governance and query observability in the warehouse. This architecture addressed two needs together: convenient analysis for product teams and visibility into the underlying data and queries for data teams.
In 2024, the Houseware team built an analytics copilot that decomposed a user's question into smaller tasks, used SQL agents to query Snowflake, and generated charts and summaries from the results. The work brought agent orchestration into a concrete analytics workflow: translating a question into database operations, then turning their outputs into an answer a product team could use. LaunchDarkly subsequently acquired Houseware.
Shubhankar’s June 2024 account of the agent stack separates shared capabilities—runtime, tracing, permissions, and model access—from decisions application developers must make about tools, instructions, human intervention, and the intended experience. He also argues that memory, execution histories, and feedback should inform future planning. AutoBrowse makes that last idea concrete.
Learning through reusable browser skills
AutoBrowse separates execution from reflection. A doer agent attempts a browser task; a teacher examines screenshots, traces, and results, forms a hypothesis about what should change, and updates a strategy file. Subsequent attempts read the accumulated lessons. A final run exercises the resulting skill, which can be exported as a SKILL.md file for reuse in Claude Code or Codex. Shubhankar’s implementation builds on an inner agent from Browserbase’s shared skills repository.
A flight-search example illustrates what the loop can learn: a URL can encode the search directly, avoiding repeated calendar clicks and an awkward time filter. The useful result is a navigation method another agent can follow, preserved alongside site-specific constraints and waiting behavior.
Several engineering choices define the approach:
Improvement has a budget. In the AutoBrowse article co-authored with Kyle Jeong, the loop uses limited iterations and early stopping to seek a sufficiently reliable, inexpensive path. Traces let developers inspect how it reached a result. A successful attempt can still be followed by a failure; accumulated instructions do not guarantee steady progress.
The verifier defines what improves. Shubhankar identifies replayable environments and verifiable outcomes as prerequisites for applying the approach elsewhere. Finding an acceptable flight is easier to judge than finding the best flight. The choice of optimization objective—and the quality of the verifier—therefore matters alongside the teacher’s ability to revise instructions.
Skills require maintenance and scrutiny. For changing websites, he describes monitoring and failure-triggered repair loops that propose changes for human review. Generated skills also need inspection for prompt injection, alongside controls on inputs, permitted actions, and destinations.
Choosing when a browser is necessary
Shubhankar also argues for matching the tool to the task. In a guide co-authored with Harsehaj Dhami, he distinguishes three operations: Search locates relevant pages, Fetch retrieves content that needs no interaction, and a browser handles clicks, login, and dynamic behavior. This gives developers a concrete decision before optimizing a browser workflow: determine whether the request requires a browser session at all.
AutoBrowse turns browser runs into reusable instructions. Its flight and restaurant examples show what the teacher learns, why faster runs can still fail, and what verification and maintenance must supply.
AutoBrowse carries learning between attempts through strategy.md: the doer produces browser evidence, and the teacher converts that evidence into instructions.
Cost, latency and correctness can move in different directions. The live flight run passed on iteration two and failed on iteration three despite using fewer turns and less time.
Reusable skills need ongoing checks, failure-triggered repair and review. Learning from web content also requires controls on inputs, saved instructions and permitted browser actions.
▶ Watch ↗