An agent can click every button correctly and still fail the task. This AMA is about what sits underneath that: persistent identity, stealth that never holds still, and the harder problem of verifying a run actually did what it was supposed to.
Browser automation used to have a simple job. Give a program a browser, define the clicks, keep the selectors alive when the site changes.
Browser agents are making that job description obsolete. Current models can write browser code, recover from their own mistakes, and chain together workflows that used to take real engineering hours.
None of that turns out to be the hard part.
The hard part is what happens after the agent acts. Did it keep the identity it started with? Did the IP change under it mid-task? Did the run actually finish the job, or did it just perform a sequence of actions that looked right?
That split came up again and again in a Reddit AMA with Alexander Yue, who works on evaluations at Browser Use.
As Browser Use's Alexander Yue put it during our recent Reddit AMA:
Its the verifier/reward function that is the missing piece for being able to do reinforcement learning for browser agents.
Yue works on evaluations at Browser Use and on physics and CS research at Stanford SLAC. Browser Use's open source harness has passed 107k GitHub stars, and its newer v4 platform runs agents on hosted, persistent browser sessions instead of throwaway headless instances. He was joined in the thread by Reagan Hsu, Browser Use's founding engineer, though the questions below were answered by Yue.
In our fourth r/WebScrapingInsider AMA, we asked Yue how much of the browser an agent should actually control, what identity survives between runs, why stealth resists a single score, and how anyone proves a run did the job.
Here are the six biggest insights from the discussion.
1. The Browser Agent Is Becoming a Programmer
The easy way to picture a browser agent is an LLM looking at a page and deciding whether to click, type, or scroll. That's the tool-calling model most frameworks still ship: a fixed list of browser actions, and the model picks one.
Browser Use's newer harness drops the list entirely.
It changes the regime from tool calling agents into coding agents
Asked which browser-agent approach he found most interesting, Yue pointed at BrowserCode, Browser Use's own fork of an open source coding-agent harness with one extra tool added: writing raw Chrome DevTools Protocol (CDP) code. Instead of calling click() or type(), the agent writes the low-level instructions that produce those actions itself.
We got complete freedom over how we implement browser functions and can iterate rapidly.
He's candid about the cost of that freedom too: a higher skill ceiling for the agent comes with a higher skill floor for the team running it. Nothing is caught by a predefined action set anymore. If the agent writes bad CDP, that's a bug the team has to catch, not a guardrail the framework already had.
The alternative stays available and genuinely simpler: ask an LLM to write a Playwright script, test it, and feed errors back until it passes. Yue calls that path "severely limiting" next to an agent that works statefully, executing actions one after another and tracking what it's already done, instead of encoding the whole workflow into a single script up front.
The distinction that matters isn't CDP versus Playwright as technologies. It's where the decision-making lives. In a tool-calling agent, the framework decides what "click" means. In a coding agent, the agent decides what code to run to get the outcome it wants.
2. The Next Browser Agent May Be Blind by Design
More context usually sounds like an advantage for an AI system. Browser Use's older architecture treated it that way: a pipeline turning HTML, DOM, accessibility-tree data and screenshots into token-efficient state, handed to the model on every single turn. Yue describes it as built from thousands of contributions, evaluations and test cases to make it robust.
The newer BrowserCode agent throws most of that out.
the agent does not get the page state every turn, it has to extract the information it needs itself by writing custom CDP (low level browser code) for it. It explores the page somewhat "blindly" but is able to extract just the content it needs.
Instead of the browser serializing everything potentially useful and handing it over, the agent decides what to inspect and writes the targeted code to inspect it. Yue adds that newer models increasingly skip screenshots on their own, preferring to read code output instead.
these new agents don't really use the browser like us humans do. But they perform significantly better, often better and faster than human solutions.
That's worth sitting with. It isn't a claim that screenshots or DOM state are obsolete everywhere. It's evidence that comprehensive state on every turn was solving a problem the newer architecture doesn't have: the model no longer needs to be shown the page if it can ask the page a specific question and get a specific answer back.
It also explains why a coding agent can take shortcuts a tool-calling agent can't. It isn't limited to one fixed interpretation of the page, so it can reach for internal APIs, run JavaScript directly, or query only the one element the task actually depends on.
3. The Agent Doesn't Have to Run Forever
The obvious comparison is agent versus script. Yue's answer suggests that's the wrong comparison. An agent can be the thing that writes the script.
A 10 step agent run with Luna you would expect to cost between 1 and 2 cents. If you want to run it again, you can ask the agent to write a script and re-use it on future runs. Then it will cost fractions of a cent.
Read closely, that's a three-stage production pattern rather than a one-time cost comparison: explore a workflow adaptively while it's still unknown, have the agent compile what it found into a reusable script, then run that script cheaply until the site changes enough to send you back to the agent.
Yue backs this up from what the team is seeing in practice, not just from a pricing example:
We see huge shifts to LLM based extraction, especially our agents that write scraping scripts and maintain them, fixing issues as they arise.
He doesn't pretend the script disappears as a category, either. Asked what's still better about hand-written scraping, his answer is blunt:
The only thing scripts are better at now is speed.
That's a real qualification, not a hedge for politeness. Speed still matters for workloads that don't need adaptation: stable pages, high volume, low tolerance for the latency an LLM call adds to every step. The pattern this section argues for isn't "agents replace scripts." It's "agents can be the thing that decides when a script is safe to write."
4. A Persistent Browser Is Not a Persistent Identity
"Persistent browser" sounds like one guarantee. In production it's several, and they don't all move together.
Every "browser profile" you have with us will use the same fingerprint and cookies. The IP we cannot guarantee stays the same but will be in same country.
That's a specific, decomposable claim worth reading slowly. Fingerprint and cookies are tied to the profile and stay put. The network origin is a separate guarantee, weaker than the other two, and the weakest link is exactly the one most likely to get you caught.
One browser profile = 1 fingerprint and all cookies and local storage, etc
By default separate runs will be with separate fingerprints and cookies and different IPs.
Yue is direct about where that leaves you if you need the network layer to hold still too:
We have all the stealth in the cloud browser, use a persistent profile and it will stay logged in a few times. But the IP changes and thats the thing they will catch you on. So if you really want this, you can go to proxy providers and buy a non-shared dedicated residential ip.
He even prices it: expect to pay on the order of $5 a month for one stable, low-fraud-score IP, and to cycle through a few providers before you find one worth keeping.
The broader lesson isn't specific to Browser Use. "Identity persistence" is a bundle of separate guarantees, and a vendor confirming one of them tells you nothing about the others.
5. A Stealth Score Without a Time Dimension Is Incomplete
Stealth gets talked about like a spec sheet: a percentage, measured once, printed on a comparison page. Yue's answer to how the team benchmarks it undercuts that framing directly.
Its hardest to measure browser stealth because captchas and ips change all the time. We have to remeasure constantly
CAPTCHAs change. IP pools change. Detection systems change on their own schedule, not yours. A number measured in March tells you very little about April.
The stealth rate can go back and forth but generally we are doing better and better
That's the guest's own framing: not a fixed score, a trend line he's watching move. Worth flagging as their assessment of their own product, not an independent benchmark.
The AMA also holds a genuine tension worth keeping rather than resolving. Asked where anti-bot is heading, Yue said this:
Anti bot is almost already solved
The context matters more than the line by itself. He's talking about mandatory Google account login specifically: it requires a phone number, ties to a real device, and gets watched closely enough that automating it at scale isn't really feasible anymore. His own next sentence is the reason nobody actually does this everywhere:
if you require google login for every user on your site, you would lose a lot of users
Anti-bot in that narrow sense is close to solved. Sites don't deploy the solution because the cost lands on their own signup funnel, not on the bots.
6. The Harder Problem May Be Knowing When the Agent Succeeded
A browser agent can click the right button, land on the right page, and still fail the task underneath it. Wrong account, stale data, an incomplete result, a state nobody planned for. "Did the model take reasonable-looking actions" is a weaker question than "did the task actually get done."
Yue says that gap is one of the open problems he keeps coming back to with people building agents at the biggest labs:
The question I discuss all the time with Anthropic and OpenAI engineers is how to build the best verifiers for browser agents running on real world, unpredictable websites.
That connects directly to how Browser Use evaluates its own agents day to day:
The best way to measure if browser agents are better is to run them on realistic tasks on the web and then judge them with an LLM over a carefully verified rubric.
It seems a bit high variance but if you run thousands of tasks you get a great measurement by law of large numbers.
Two different sources of noise sit underneath that variance, and they need different fixes. The agent itself can behave differently run to run on an identical task. Separately, the website, the network, and the anti-bot system it's running against can behave differently too, independent of anything the agent did. A handful of deterministic test cases can't tell those apart, which is exactly why a small benchmark can produce false confidence.
Yue also describes what makes catching that possible in the first place: every LLM call's input, output and reasoning, every browser call, screenshot, and worker and control-plane log gets recorded. Without that trace, there's nothing to check the rubric against when a run fails for a reason nobody predicted.
Conclusion: Stop Asking Whether the Agent Can Browse
Every part of this AMA points past that question. Current models can write the browser code, decide what page state they actually need, and turn a one-time exploration into automation that runs without them.
None of that removes the production environment underneath it. A persistent browser profile doesn't automatically mean a persistent network identity. A stealth number measured once tells you nothing about next month. And a benchmark score doesn't establish that any one run, on any one target, actually finished the job it was given.
That's why the AMA's real center of gravity is verification. The agent is getting capable enough that acting is no longer the hard part. Proving what happened, under what conditions, and whether the outcome was actually correct, is.
As Yue put it:
The best way to measure if browser agents are better is to run them on realistic tasks on the web
Apply the same standard to whatever you're evaluating next. Not which agent can browse. Which one you can prove actually finished.