In this interview, Magnus Müller, CEO of Browser Use, discusses how autonomous AI agents are reshaping daily workflows, moving from users constantly prompting AI to AI proactively prompting users with contextual information. He outlines a practical approach to building browser automation agents using Playwright for control, screenshots fed to LLMs for visual decision‑making, and highlights the myriad edge cases—cross‑origin iframes, pop‑ups, 2FA, file uploads, site changes—that challenge reliability. To address variance, Browser Use records a single non‑deterministic agent run and converts it into a deterministic automation script that can be replayed until the website changes, after which the agent is rerun to generate a new script. He describes an ongoing continuous evaluation system that runs thousands of tasks, automatically inspects results, fixes bugs, and iterates, costing roughly $100‑200 K per month. Finally, Müller shares hiring insights: his team’s average age is 23‑24, favoring very young engineers (19‑year‑olds) who quickly adopt new AI tools and demonstrate high agency, while viewing traditional university degrees as less critical compared to demonstrated ability and ownership.
Chapters
How do you think our everyday life will change if we truly have these autonomous agents running around doing stuff for us?
Google said something similar in the past that the only problem with Google is you need to know before what you will search. You need to type, you need to search first because you— so you need to know what you're looking for before you can type. And I think we will see this year a change. Where you will stop prompting AI, but AI will prompt more and more you. In the last year, I thought sometimes before I have a meeting like this. So now I basically prompted my agent and said, okay, every morning at 6 AM, check my calendar with whom I have a meeting today, do web search about each of them, send me a Slack message with the context. And now every morning my agent pings me with context about each meeting. You see, this is now a transition, right? I prompted basically only once with my high-level goal, and now the agent prompts me every morning. And like, you see how the kind of the distribution shifts, right? From me prompting all the time to, okay, the agent prompts me all the time.
I was thinking about if I were to build a browser automation agent from scratch. So I'm thinking of using the Playwright to control the browser. And take a screenshot, feed that screenshot to, to an LLM and ask it to identify which button to click on the image and then send maybe the coordinates of that image to Playwright again and repeat until the task is done. So, so that's my general thought process of building something like this from scratch without browser use.
It makes a ton of sense. Yeah. You have to base LLM. Screenshot, maybe some tools to interact. That's all you need.
That's all I need? What more can I get?
The thing is always the edge cases, right? Oh, suddenly there's a cross-origin iframe. Oh, there's a popup popping up which blocks. Oh, you want to upload a file. Oh, the site doesn't really load. Oh, you need to scroll inside this container on the screen. Or you need to sign suddenly a field. So it's mainly all the edge cases where, and there are many of them, like every single task we see has some form of an edge case. Oh, let's say you want to buy something on Amazon. Okay. Oh, suddenly you need 2FA confirmation. Oh, you need to log in. Oh, you need to have persistent login. Oh, LinkedIn, Amazon thinks you're a bot and they block you. And then, oh, when you do the checkout process, you want to add your credentials in a secure way without giving it to the LLM. And for often checkout flows, you don't really interact with the actual site, but it's like a cross-origin iframe. Edge cases like this in a simple checkout process in Amazon, there can be many. Our library, we just always get the most recent state of the website. We interact with it like a human. Traditional frameworks like Playwright or Puppeteer, they often struggle with this a lot. Maybe you have a flow to do Amazon checkout, but then Amazon updates its website and your flow breaks. But the problem is it's less reliable, right? Because every time an LLM processes the website, people who traditionally do like scraping, they are very used to like a deterministic workflow. And now you can give them browser agents, which solves some problems. But suddenly browser agents have much more variance. They can, you run them again, maybe they do something different. And so what we, for example, built out is that if you run your agent once, we can convert this agent into a deterministic flow. And then you can rerun the deterministic flow until it breaks. And then you can run the agent again.
You're saying that you're turning the non-deterministic flow into the deterministic flow after one use. How do you do that?
People are complaining about three things. People are complaining about consistency, which is exactly this determinism, that it works once, they run again and it does something different. Second thing is speed and third thing is cost. So what we ended up building is we try to convert this agent which does and does interaction, clicks, interacts with the website. We try to record that and then convert that into a normal automation script. So that when you then decide, oh, I want to rerun this over and over again, you can do it until the website changes. And when the website changes, you just come back and run the agent again. You get the new script.
Do you think you can, you can show us like what it looks like?
Let me open. So you see, basically those are the last 10 hours. Okay. And I did like 10 runs here. You can see here different developers. This, for example, me. You see, for example, 40 minutes ago, I started my last run. And here you see in here, we have, for example, now like almost 100 tasks in this one eval set.
And these tasks is from the users or dataset or something?
We mainly do evals on like real user tasks or tasks which people tell us which we should fix. And then we put them in evals and we optimize over them. What I do instead is I go inside, I use Superset. It's like, here I have many different Claude code agents. Okay, you see every single of those tabs here on the left is basically like a different branch. And each of those has a different agent, a different coding agent running. And so for example, this agent here, You see it has like an MCP tool to interact with my eval platform. It can start new evals, it can inspect last evals. So for example, here it just started a new eval with cycle 10, it's called. And what I then tell to the system is wait 10 minutes and in 10 minutes inspect the results, see what are the biggest problems, fix those problems, start a new run, and 10 minutes later, inspect again and keep going. And you see, while we are having right now this interview, this agent is already in cycle 10. Like while we are right now talking, this agent is working for me. You see right now it's in the waiting phase. So you see here, okay, the runtime is like almost 100 hours of this agent. So I had this run over the entire last 3 days. And this agent basically right now waits for 10 minutes. Then will inspect the newest results and then inspect, did it actually work what it wanted to do or not? Does a new branch, submits a new experiment. And then like this keeps on going. And then I check in like every 10 hours to see what are the actual bugs, whether it found out, whether they did stupid stuff. But most often it finds some really, really real bugs, which I can then just take over and put into main and say, okay, this was clearly a real bug. Great that we have fixed that.
Do you have strategy of operationalizing these experiments or maybe at this stage the cost is so low that it's, it's, it's okay. It's negligible.
Yeah. Currently we pay around $100K to $200K per month on a LEMP cost for this stuff, which, I mean, this is a good place where our funding can go, right? Where we can use those $17 million to just experience faster, experiment faster, like more agents running. More experiments to just find any faster bugs to explore different approaches faster.
AI is changing the gap between senior and junior engineers. What are you seeing at BrowserUse?
Yeah, so my average team age is maybe 23, 24. So I hired some people who are like 19. And which I prefer much more over like all senior people, just because they're just so quick learner. They want to learn a lot. They want to take ownership. They, you know, like if you see a new AI tool on Twitter or even me, I think, oh, this looks cool, but I don't want to set it up like this for sure takes me long, right? But as young people, because they are so young and don't know much, they're just so much faster. You know, all those new tools they know perfectly. And so they move very, very quickly and they find solutions to problems. And that's why I think they do great work. Like they do as great work as like senior people. If I see like correct 19-year-old people, I would definitely hire them. So I think they're like, I want to hire them from like their first semester in university. And so I feel if you have like, if you're a person with very, very high agency, who wants to get stuff done and also shows, okay, you build like constantly projects because you want to have a lot of ownership. Like, I'm extremely happy to consider this over people who are like 30, 40, who have a lot of experience, but yeah, who are maybe have it harder with like new things.
Is university degree important to you?
Based on my past hiring decisions? No. Like I have like half of the team who don't have university degree, who dropped out. Me myself, I dropped out of the master. But of course, you, like I studied in ETH in Zurich and there you meet like many correct people, right? Like for me, my co-founder, right? Super correct guy. You just meet them at those places where ambitious people come together.
