Stop Swapping Models: Give Your Agents Memory of What Works

The core claim. Browserbase's Shubhankar Srivastava argues that the fastest route to reliable browser agents is a skill file that learns from every run. His "auto browse" loop, based on Karpathy's auto research, pairs a doer agent with a teacher agent that reads traces and writes lessons into strategy.md. The resulting skill.md carries those tricks into future runs. In a Google Flights demo, the agent learned to use query parameters instead of clicking the calendar.

Why it matters. The credible insight is that agents refresh their memory every run. A frontier model can be brilliant and still get stuck on an OpenTable anti-bot page or fail to drag a Google Flights time filter, because it never remembers what worked last time. Persisting learned workarounds turns reliability into an engineering problem instead of a waiting game for the next model release. That shift has real budget and architecture consequences.

The mechanism. The loop demands two conditions: a replayable environment and a verifiable outcome. Without them, teacher and doer agents cannot grind through enough failures or decide whether an iteration passed. Browserbase infrastructure handles logins, cookies, proxies, and some anti-bot controls at the browser layer. The speaker also applies the loop to coding agents, research agents, and internal operations, as long as those conditions hold.

The trade-off. Generating skills is not free. The speaker puts a complex skill at $30 to $100 in amortized token cost, and websites change, so skills rot. The suggested answer is cron checks or production-failure alerts that trigger a healing loop and open a pull request for a human to review. Teams that adopt this need to own that maintenance lifecycle, or the saved cost will come back as stale automation.

What's missing. Most of the evidence is vendor-generated. The speaker sells Browserbase, the successes are self-evaluated by the loop's teacher agent, and the 16x cheaper numbers are customer anecdotes, not an independent benchmark. Prompt injection is acknowledged but handled by infrastructure limits and a security reviewer agent, with few specifics. Treat the architecture as promising and the numerical claims as marketing until reproduced.

The practical signal. For engineering leaders, the takeaway is to start capturing what works from production traces, even without a vendor. Pick one high-frequency task with a clear success metric, store traces, and let an agent write a strategy file, then review it like a code change. The concept is portable; the sales pitch is not.