The Current State of Browser Agents - Jerry Wu and Wyatt Marshall

Hi guys, um, I'm Jerry. This is Wyatt. Welcome to our talk; we're talking about the current state of browser agents. Wyatt and I are founders of Halluminate. We build realistic environments to help train computer and browser use AI, but that's not as important for today's talk.

Today we are going to talk about three topics, which is: first, we're going to discuss what are browser agents; second, we're going to talk about how good they are currently, and these findings are going to be powered by a benchmark that we actually just published last week.

And lastly, we're going to talk about what it means for you, a listener and AI engineer, trying to build with browser agents today.

So first, very simply, what is a browser agent? Well, our definition of a browser agent is quite simple. It is basically any AI that can control a web browser and execute tasks on behalf of the user. On the left side, you'll see a quick GIF of a browser agent purchasing a power tool by essentially going to a manufacturer and actually ordering it, and going through the checkup process by itself.

It's really cool tech, and it's only really become feasible in the last year with the advancing large language models and infrastructure around it.

Now, explaining a little bit about what's going on underneath the hood. Most browser agents—not all, but most browser agents—are powered by the same loop that you see here, of three key steps. The first is observing, also known as the observation space.

Browser agents essentially take a look at the given context of the browser they're currently operating in and figure out what to do next,right? They do this by either taking a screenshot—this is the VLM approach—or there are some browser agents that also extract the HTML and the DOM.

This is more of like a text-based approach. After figuring out the context, the next thing that they do is they reason through and figure out what the next steps are required to execute the task from the user. For example, if I ask a browser agent to purchase a power tool, maybe it says, "Okay, I need to go and click the search bar," which takes us to the last step, which is: browser agents can take an action,right?

This is also called the action space, where browser agents can either click, scroll, maybe fill in some text, which then takes us back to the first step of the loop, which is a new state of the browser, and then they need to figure out what to do next,right?

So this is called the browser agent loop, and this helps you build some intuition on what's going on underneath all of that action. And there are a few major use cases that browser agents have started to penetrate in the last few months.

These are the most common ones. I won't go into too much detail here, but, like, just the voiceover, the ones that we see most commonly: web scraping involves essentially launching a fleet of browser agents to extract information. For example, a lot of sales teams use this to find data about prospects.

Software QA is using browser agents to essentially click around and test software that's about to be released. Form filling, or a variation of this, which is job application filling, is really, really popular today. A lot of automated job prospecting tools are powered by browser agents today.

And generative RPA is, like, a really catch-all, broad category. This means a lot of things, but a lot of companies are exploring using browser agents to essentially automate traditional RPA workflows that break very often. And you see this with companies like UiPath.

So yeah, that's kind of what browser agents are. I'm now going to pass it off to Wyatt to tell us a little bit about how good they are.

Yeah, thanks, Jerry. Now that we have some context on browser agents, we can move on to the next question, which is: how good are they? So, to answer that, we need to think about what it means to evaluate a browser agent.

At a very high level, it is simple. It is: you give a task to the agent, did it do the task? In practice, this is a lot more complicated. So the first thing is: how do you come up with tasks for your agent to do?

How do you come up with that dataset? We need tasks to be realistic, they have to be feasible. Typically, there are some—there's a domain-specific element to them, and they need to be scalable. You have to create a lot of tasks.

We also need to perform the evaluation. Evaluations can be done automated. If you have, like, a validation function, they can be done manually with human annotators. There's LLM as a judge approaches. There's a lot that goes into that.

And then finally, where is the actual browser agent running? On what infrastructure? As you'll see later, infrastructure is actually a key part of how well browser agents perform, so a big thing to consider when evaluating.

Broadly speaking, there are two types of tasks: retasks and write tasks. Retasks are typically just information gathering and collection, whereas write tasks involve actually interacting with and, like, changing state on a site. So retasks are more of, like, a web scraping, whereas a write task is really taking action—what you would want a web agent to be able to do.

Write tasks are more complicated and more challenging, both

in creating them as well as actually for the agent to perform them.

Now, this brings us to WebBench, which is the benchmark dataset and evaluation that we performed last week. So we created over 5,000 tasks. Open source about half of them. These are both read and write tasks on close to 500 different websites in a bunch of different categories.

You can see in the chart there. As far as we know, this is the largest scale dataset for web use that we've seen, so we're really excited to put this out there for the community.

Now, let's just take a look here at the performance of a few industry-leading web agents on just retasks. And you'll seeright away, this is actually really good. So we have a baseline of OpenAI operator with human-in-the-loop supervision, and that sits at about 80%.

And our leading web agent is actually hittingright around there, 80%, with, you know, several getting close to that, which is great news for information retrieval and data extraction. Agents are pretty good at surfing the web and finding information and getting it, returning it back to you.

As we'll talk later, the failures here that kind of last 20, 25% are typically infrastructure and internet-related and not necessarily agent-related. So here is an example of a retask. So it's just extracting information, but you'll notice it's not necessarily a simple task.

The UX/UI is pretty complicated. There's multiple searching steps and filtering steps. There's a Cloudflare pop-up, and there's a few different scrolling interactions that the agent needs to partake.

Now, let's talk a little bit more about write tasks. Overall performance on write tasks is much, much worse. Drops about 50% or more. You can see that operator baseline there only dropped about 10%. So operator with a human-in-the-loop, just a small dip in performance, whereas fully autonomous agents across the board had a much, much bigger dip.

The question here is: what is causing this? Why are web agents so much better at read tasks, and why do they struggle so much with write tasks? There's a few reasons for this. One of the main reasons is that write tasks typically are a longer trajectory.

So it just takes more steps to perform write tasks than it does to perform read tasks. And the more steps a task takes, the more likely an agent is to make a mistake at one of those steps and overall fail on the task.

This isn't the only reason, though. Write tasks also typically involve interacting with more complicated or difficult parts of the site, and the user interface there is a little bit more challenging for agents. Whereas reading, you're typically searching, maybe filtering, maybe scrolling.

Read—sorry, write tasks, you're going to be doing a lot of data input, you'll be doing data extraction, a lot more complicated forms. Just all around, it's a more difficult interaction. Writing also involves typically login or authentication. So a lot of websites, you can go on without logging in and you can find information, but if you want to update or add information or delete information, you're going to have to log into an account.

Logging in is a very challenging activity for web agents, both from the interactive side of things, the user experience side for the agent, as well as managing credentials for the agent, so having a username and password and an email for the agent.

And managing that is a challenge. And then finally, anti-bot protections are a lot stricter, typically on sites that have a lot of write tasks, as well as performing write tasks can even trigger anti-bot things. Like, you know, you might not hit a captcha until you have to input information, and then you'll have a captcha before you can input that information.

So here is an example of a write task: submitting a recipe on All Recipes. The trajectory you'll see is much longer. It also involves not one, but two steps for logging in. And the UI here is pretty complicated.

It's a dynamic UI. The agent is actually adding new forms to fill out. And ultimately, I believe this task was a failure. The agent was not able to successfully submit the recipe.

So overall, this is combined read and write. Our best agent got about, you know, two-thirds of the tasks successful, whereas the average comes at a little bit over 50%. And again, that OpenAI operator with human-in-the-loop supervision is hitting close to 80%, 75, 80%.

So I think there's kind of two ways to look at this graph. One is pessimistically: wow, these agents aren't that good. But I actually think this graph is more impressive than it is negative. The fact that web agents today are able to achieve results like this on a pretty challenging, comprehensive benchmark shows how well they are actually performing, even though there's been only about, you know, a few years of development on web agents.

So I think there is a long way to go, and obviously at some point you'd hope this graph gets closer to 100%. But overall, these numbers are pretty impressive.

Now, let's talk a little bit more about some of the failure patterns that we saw. So here are a couple examples of situations where the agent was responsible for the failure. On the left side, you can see there's an example of a pop-up that the agent isn't able to interact with.

It's not able to close, and so the agent isn't able to complete its task because that pop-up is blocking it from interacting with the site in the way it needs to. Now, on theright side, you can see there's just a timeout issue.

The agent took too long and ultimately failed because it timed out. So we call these agent failures because a more intelligent, more capable agent should be able to do these tasks. There's nothing blocking the agent from performing these tasks other than the agent's own abilities.

This is contrasted with what we call infrastructure failures. So infrastructure failures are more related to the framework or infrastructure that the agent is running on, rather than the agent itself. So this isn't an issue of the agent not being intelligent enough or not having the capabilities.

Rather, it's something underneath that, where the agent is actually prevented from doing what it needs to do because of the infrastructure it's running on or the framework that it's implemented in. You can see on the left side, the agent searches for the site.

It's blocked. Like, it's flagged as a bot and it's blocked from even entering the site. On theright side, the agent is logging in. It is required email verification. The agent in this framework has no ability to access that, so the agent is unable to log in.

Looking at the performance of our agents that we benchmarked overall, you can see here we have success, agent and infra failure, and then agent failure. So again, agent failures are—it's primarily the fault of the agent. It was—it should have been able to perform the task, but it wasn't.

Agent and infra, we couple together. There's some times where those things are intertwined. It's a little bit hard to tell if it was purely an infra failure or not. But broadly speaking, that agent and infra is something along the lines of a CAPTCHA, proxy, login, auth, something like that.

And you can see that kind of agent and infra chunk, if we can improve infra, that's a huge bump to the overall performance of our agents.

Finally, the probably biggest across-the-board flaw with agentsright now is they are very, very slow. So you can see here, this is the average task execution length. Now, it's a little bit skewed because when agents fail, they typically go down a, like, death spiral where they're not able to recognize that they can't do the task, so they just keep trying and trying and trying until they hit a timeout.

But even with that said, we see that agents just take forever to do things. This is typically because of the agent loop. They have to observe, they have to plan and reason, break the task down, they make mistakes or they fail in their tool calls, they'll have to retry actions, and it just takes them a long time to actually interact with the site, to click around, to navigate the site.

I think the takeaway here is that if you're going to have an async set and forget application, you might be okay with some of this latency. However, for anything that's real-time, this is a huge problem, and the latency issue really needs to be figured out for any applications to be effective in real-time.

Awesome. So those are the findings that we've discovered while benchmarking agents on a wide variety of tasks. Now, taking a step back, we want to discuss, like, what do these results really mean for you, the AI engineer trying to build with a browser agent,right?

And I think there are three, like, big takeaways that we would like to really impart on you, which is, first, as Wyatt really alluded to, picking your use case is extremely important,right? And I think the real question you need to ask yourself is, are you building a read or a write use case?

As we saw from the results, read use cases today are already pretty performant out of the box,right? Not perfect, but if you're creating, like, a deep research tool or some sort of system that uses browser agents to retrieve information en masse, out-of-the-box products work pretty well here.

Now, on the other hand, if you're trying to build a product that involves more write functions, such as filling in forms or actually doing work and, like, changing the state of some software, just be aware that, like, out-of-the-box browser agents might not be as accurate as you want them to be.

And it's not that they can't get there. It's that you're going to have to test them pretty rigorously before releasing them in some sort of production capacity. And this leads to just building a lot of internal evals for your agents,right?

And this is important whether you're building read or write products, but I think it's especially important if you're trying to create agents that take write-based actions.

The second key takeaway to really hammer home is browser infrastructure matters a ton. Again, this is the second time you've seen this chart, and that's because you can see very apparently that, like, the browser infra you choose can have pretty strong performance swings,right?

And so this just means, like, really test the browser infrastructure that you're trying to build on top of. Try multiple providers. A great thing about these browser infrastructure providers today is that they're extremely interoperable. You can switch them in and out to test which ones do better.

It is all really use case dependent. Like, different browser infrastructure systems might have better CAPTCHAs for your use case or might have proxies that are or aren't blocked for certain sites that you're trying to access. A great tip is if you're building on a specific set of sites and you feel like you're getting proxy blocked, just, like, shoot your browser infrastructure provider a message and they'll usually be able to unblock you, like, with some capacity on their side.

So just really make sure you try different providers before you go all in on building some sort of production use case. And I think the last key takeaway here really is try a hybrid approach. So, like, the report really showed us that although browser agents are good at a lot of things, they're not good at everything, and there's still some room to grow,right?

And when we talk to a lot of our customers and a lot of people building browser agents at scale, one of the big techniques that people utilize, especially for production-scale use cases, is using a mix of browser agents for tasks or workflows that are more long tail, more dynamic, or change often, and mixing that with more deterministic workflows such as Playwright that we know are reliable at scale and that can be, you know, more accurate for a large volume,right?

And you can kind of think of this as, like, laying train tracks for the steps that need constant movement and accuracy, but using the agent for the more long tail, diverse, you know, roads and trails that require a little more nuance and capability.

I think, like, looking ahead, we fully anticipate the industry to improve a lot of these problems. I think a few key areas where we're excited to see development on are, first, just better long-context memory. As you saw from Wyatt's stats, like, some write tasks take almost three times the amount of steps as re-tasks,right?

So having longer-term context on how to execute those tasks will be incredibly important for accuracy. Second is, I think there is still a massive opportunity to just build more, like, browser infrastructure primitives. We talked about this, but, like, login and auth remains one of the biggest blockers to write-based actions.

Along with that, payments is also a huge issue that we haven't even really started touching yet. And I think people who can build these tools to enable browser agents to take these, like, primitive actions on the browser will unlock a huge amount of value.

And the last thing is that the models that power these browser agents are just going to get better. And something that actually we're working on is essentially, like, training environments and, like, sandboxes to help essentially train models within a browser or computer-use environment setting to make them better at, for example, tool calling or write actions, things like that,right?

So if you want to talk about that, you know, shoot us a ping. But yeah, that's really the crux of this talk. The last thing we want to wrap up with are some really cool examples of browser agent actions that we saw while executing this benchmark that we thought were cool and also a little scary.

The first is we asked a browser agent to do some actions on GitHub. It got stuck, and it ended up actually talking with GitHub's virtual assistant, AI, to unblock itself. And this is a little bit of, like, AI agent inception that we thought was really comical to watch as it conversed back and forth.

Here is a really cool example where we asked a browser agent to post a comment on a medium article, and that comment ended up being the top-liked post. And this was, like, a really funny nod to the Turing test and, like, really makes you question whether or not we've actually passed this moment.

This is a fun example of we asked browser agents to book us some reservations at restaurants, and we kept getting, you know, notifications on our phone of restaurants being booked on our behalf by our browser agent. We went back and canceled those reservations, but it was just a funny, like, externality of real-world browser agent testing.

And finally, the last one that we actually thought was probably one of the scariest examples, I think this was browser use, was blocked by Cloudflare when trying to execute a task, and instead of just giving up, it went and actually searched for ways on Google to bypass Cloudflare verification.

And this was a little bit of a, like, whoa, these things are perhaps doing emergent behavior that we couldn't predict without testing it in some robust capacity. So yeah, that's our talk. We hope you enjoyed and really excited for this space.

Lots of development happening very rapidly, and we wanted to give you guys a current snapshot on what we think the current capabilities are so you guys can build better. And we hope to do this on a recurring basis every few months because everything is moving so fast.

Thanks for your time. Have a great day.

Thanks, everyone.