Open Operator, Serverless Browsers and the Future of Computer-Using Agents

Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host, swyx, founder of Small AI.

Today, we are very blessed to have our friend, Paul Klein IV.

The Fourth.

The Fourth.

CEO of Browserbase. Welcome.

Thanks, guys. Yeah, I'm happy to be here. I've been lucky to know both of you for a couple of years now, I think, so it's just like we're hanging out, you know?

Yeah.

It's just like we're hanging out with mics in front of us.

Just hanging out with mics in front of us.

With 3 ginormous microphones in front of our faces. This is a totally normal hangout.

Yeah. We've actually mentioned you on the podcast, I think, more often than any other Solaris tenant, just because you're one of the best-performing LLM tool companies, I think, that have started up in the last couple of years.

Yeah. I mean, it's been a whirlwind of a year. Browserbase is actually pretty close to our first birthday, so we are 1 year old. Going from starting a company as a solo founder to having a team of 20 people and a Series A, but also being able to support hundreds of AI companies that are building AI applications that go out and automate the web, has just been really cool. It's been happening a little too fast.

I think, collectively, as an AI industry, let's just take a week off together. I took my first vacation 2 weeks ago, and Operator came out on the first day. Then, a week later, DeepSeek came out, and I'm on vacation trying to chill. I'm like, “We gotta build with this stuff,” right?

Mm-hmm.

It's been a breakneck year, but I'm super happy to be here and talk more about all the stuff we're seeing. I'd love to hear what you guys are excited about, too, and share with you.

Where to start? People, you've done a bunch of podcasts. I strongly recommend Jack Bridger's Scaling Dev Tools, as well as Turner Novak's The Peel, and I'm sure there are others. You covered your Twilio story in the past, talked about Stream Club, which got acquired by Mux, and then you left to start Browserbase. So maybe we just start with: what is Browserbase?

1. Browserbase Runs Browsers For AI

Yeah. Browserbase is the web browser for your AI. We're building headless browser infrastructure, which consists of browsers that run in a server environment that's accessible to developers via APIs and SDKs.

It's really hard to run a web browser in the cloud. You guys are probably running Chrome on your computers, and that's using a lot of resources, right?

Yeah.

If you want to run a web browser, or thousands of web browsers, you can't just spin up a bunch of Lambdas. You actually need to use a secure, containerized environment. You have to scale it up and down. It's a stateful system, and that infrastructure is super painful.

I know that firsthand because, at my last company, Stream Club, I was CTO, and I was building our own internal headless browser infrastructure. That's actually why we sold the company: Mux really wanted to buy the headless browser infrastructure that we'd built, and it's just a super-hard problem.

I actually told my co-founders I would never start another company unless it was a browser infrastructure company. It turns out that's really necessary in the age of AI, when AI can go out and interact with websites, click on buttons, and fill in forms. You need AI to do all of that work in an actual browser running somewhere on a server, and Browserbase powers that.

While you're talking about it, it occurred to me—not that you're going to be acquired or anything—but it would be really funny if you became the Nikita Bier of headless browser companies. You just have one trick: you make browser companies that get acquired.

I truly do only have 1 trick, and I'm screwed if it's not headless browsers, you know? I'm not a Go programmer. I'm in AI Grant, you know? Browserbase was in AI Grant.

Yes.

But we were the only company in that AI Grant batch that used $0 on AI spend. We're purely an infrastructure company.

Ah. Mm.

As much as people want to ask me about reinforcement learning, I might not be the best guy to talk to about that. But if you want to ask about headless browser infrastructure at scale, I can talk your ear off. That's really my area of expertise, and it's a pretty niche thing. Nobody has done what we're doing at scale before, so—

Yeah.

—we're happy to be the experts.

You do have an AI thing, Stagehand, which we'll talk about, but we can talk about the core of Browserbase first and then maybe Stagehand.

Yeah. Stagehand is our—

—which is kind of core, basically—

—web browsing framework.

Yeah.

Yeah. And maybe talk about how you got to Browserbase and what problems you saw. One of the first things I worked on as a software engineer was integration testing. Sauce Labs was kind of the main thing at the time, and then we had Selenium, we had Playwright, and we had all these different browser tools, but it's always been super hard to do.

Obviously, you worked on this before. When you started Browserbase, what were the AI-specific challenges that you saw? There's the usual challenge of running browsers at scale in the cloud, which has been a problem for years. What were the AI-unique things that you saw that traditional products just didn't cover?

2. LLMs Generalize Web Automation

First and foremost, I think back to the first thing I did as a developer, as a kid writing code. I wanted to write code that did stuff for me. I wanted to write code to automate my life, and I'd do that probably by using cURL or Beautiful Soup to fetch data from a website and parse that data.

We all know now that taking HTML and plugging that into an LLM means you can extract insights and summarize. It was very clear that dynamic web scraping became very possible with the rise of large language models, or a lot easier, and that was a clear reason why there was going to be more usage of headless browsers.

Headless browsers are necessary because a lot of modern websites don't expose all of their page content via a simple HTTP request. They actually require you to run JavaScript on the page to hydrate it. Airbnb is a great example. You go to airbnb.com, and a lot of that content on the page isn't there until after they run the initial hydration, so you can't just scrape it with cURL. You need to have some JavaScript run, and a browser is the JavaScript engine that's going to actually run all those requests on the page.

Web data retrieval was definitely one driver of starting Browserbase and the rise of being able to summarize that data with an LLM. I was also familiar with the fact that, if I wanted to automate a website, I could write 1 script, and that would work for 1 website. It was very static and deterministic.

But the web is not deterministic. The web is always changing, and until we had LLMs, there was no way to write scripts that you could write once and run on any website, adapting to changes in the structure of the website. You could click the login button, even though it could mean something different on many different websites.

LLMs allow us to generate code on the fly to actually control that. The rise of writing generic automation scripts that can work on many different websites made it clear to me that browsers were going to be a lot more useful, because now you could automate a lot more things without writing many separate scripts.

If you wanted to write a script to book a demo call on 100 websites, previously you had to write 100 scripts.

Mm.

Now you write 1 script that uses LLMs to generate that script for each website in real time. That's why we built our web-browsing framework, Stagehand, which does a lot of that work for you.

Those 2 things—web data collection and enhanced automation across many different websites—felt like big drivers for more browser infrastructure that would be required to power these features.

Yeah. And was multimodality also a big thing? Now you can use the browser—you can use LLMs to look, even though the text in the DOM might not be as friendly.

Yeah. Maybe my hot take is that I was always kind of skeptical that vision would be as big of a driver for UI automation. I felt like HTML is structured text, and large language models are good with structured text. But it's clear that these computer-use models are often vision-driven, and they've been really pushing things forward.

Being multimodal, like rendering the page, is required to take a screenshot and give that to a computer-use model to take actions on a website. It's just another win for browsers. But I'll be honest: that wasn't what I was thinking early on. I didn't even think that we'd get here so fast with multimodal and vision models.

This is one of those things where I forgot to mention in my intro that I'm an investor in Browserbase.

Yes.

I remember that, when you pitched to me, a lot of the stuff that we have today wasn't part of the original conversation. But I did have my original thesis, which is something that we've talked about on the podcast before: take the GPT Store, the custom GPT Store.

Every single checkbox and plugin is effectively a startup, and this was the browser one. I think the main hesitation—and I think I actually took a while to get back to you—was that there were others. You’re not the first headless browser startup. It’s not even your first headless browser startup. There’s always a question of whether you’ll be the category winner in a place where there are a bunch of incumbents that, to be honest, are bigger than you.

They’re just not targeted at the AI space. They don’t have the backing of Nat Friedman. You’re here in Silicon Valley; they’re not. I don’t know if that was it, but that was an interesting area.

Yeah. I think I tried all the other ones and was really disappointed. My background is from working at great developer tools companies, and nothing had the Vercel-like experience. Our biggest competitor is actually partly owned by private equity, and they just jacked up their prices quite a bit, and the dashboard hasn’t changed in 5 years. I used them at my last company, and I thought, “Oh man, there really just needs to be something with the experience of these great infrastructure companies—Stripe, Clerk, Vercel—that I use and love, but oriented toward this more specific category, which is browser infrastructure, which is really technically complex.”

A lot of stuff can go wrong on the internet when you’re running a browser. The internet is very vast, and there are a lot of different configurations. There are still websites that only work with Internet Explorer out there. How do you handle that when you’re running your own browser infrastructure? These are the problems that we have to think about and solve at Browserbase, and it’s certainly a labor of love.

But I built this for me, first and foremost. I know it’s super cheesy, and everyone says that about their startups, but it really truly was for me, if you look at the talks I did even before Browserbase. I’m really excited to try to build a category-defining infrastructure company, and it’s rare to have a new category of infrastructure exist. We’re here in the Chroma offices, and vector databases are a new category of infrastructure.

Is it?

Is it? I mean, we can debate that one later. We’re in their office, so we can debate that one later.

Yes, that is one of the industry debates.

I guess we go back to the LLM OS talk that Karpathy gave way back, and the browser box was very clearly there. It seemed like the people who were building in the space also agreed that browsers are a core primitive of the LLM OS that’s going to exist in the future.

Yeah.

Nobody was building something there that I wanted to use, so I had to go build it myself.

Yeah, I mean, exactly that talk. Honestly, that diagram—every box is a startup.

Mm-hmm.

There’s the code box, and then there’s the browser box. I think at some point they will start clashing.

Mm-hmm.

There’s always the question of whether you’re a point solution or the sort of all-in-one. I think the point solutions tend to win quickly, but then the all-in-ones have a very tight, cohesive experience.

Yeah.

Let’s talk about just the hard problems of Browserbase. You have 8 features here on your website, which is beautiful.

Thank you.

Was there an agency that you used for that?

Yeah, Herbë Paris. They’re amazing.

Herbë Paris.

Yeah. It’s H-E-R-B-E. I highly recommend that developer tools founders work with consumer agencies because they end up building beautiful things.

Yeah.

The Parisians know how to build beautiful interfaces, so I’ve got to give props to them.

And chat apps, apparently, are very fast. The Mistral chat one.

Yeah. Le Mistral. Yeah, Le Chat.

Le Chat. And then all your videos were professionally shot as well, right? The Series A video.

Yeah, yeah, yeah.

Yeah.

Nico did the videos. He’s amazing.

Not the initial video that you shot at noon.

The first one was Austin, another big surprise. But when you think about how you talk about your company, you have to think about the way you present yourself. As a developer, you evaluate a company based on the API reliability and the P95, but a lot of developers say, “Is the website good? Is the message clear? Do I trust this founder I’m building my whole feature on?”

So we’ve tried to nail that as well as the reliability of the infrastructure. You’re right, it’s very hard, and there are a lot of footguns that you run into when running headless browsers at scale.

Right. So let’s pick one. You have 8 features here: seamless integration, scalability, fast, secure, observable, stealth—that’s interesting—extensible, and developer first. What comes to your mind as the top 2 or 3 hardest ones?

3. Scaling Browsers In The Cloud

Yeah. I think just running headless browsers at scale is the hardest one.

So, scalable.

And maybe—can I nerd out for a second?

Yeah, go ahead.

Is that okay? I heard this is a technical audience, so I’ll talk to the other nerds. Whoa, they were listening.

Yeah, they’re upset.

They’re ready.

The AGI is angry.

Okay. So how do you run a browser in the cloud? Let’s start with that. Let’s say you’re using a popular browser automation framework like Puppeteer, Playwright, or Selenium. Maybe you’ve written some code locally on your computer that opens Google, finds the search bar, types in “search for Latent Space,” and hits the search button. That script works great locally; you can see the little browser open up.

You want to take that to production. You want to run the script in a cloud environment so that when your laptop is closed, the browser is still doing its work. We use AWS at Browserbase. The first thing I’d reach for is probably some sort of serverless infrastructure. I’d probably try to deploy it on Lambda, but Chrome itself is too big to run on a Lambda. It’s over 250 megabytes, so you can’t easily start it on a Lambda.

You might have to use something like Lambda Layers to squeeze it in there, maybe use a different Chromium build that’s lighter, and get it on Lambda. Great, it works. But it runs super slowly. This is because Lambdas are very resource-limited. They only run with 1 vCPU. You can run 1 process at a time. Remember, Chromium is super beefy. It’s barely running on my MacBook Air.

I’m still downloading it.

Yeah, from the test earlier, right? It’s—

I’m joking.

It’s big, you know? Lambda just won’t work really well. Maybe it’ll work, but you need something faster. Your users want something faster. Okay, let’s put it on a beefier instance. Let’s get an EC2 server running. Let’s throw Chromium on there. Great. Okay, that works well with 1 user.

But what if I want to run 10 Chromium instances, 1 for each of my users? Okay. Well, I might need 2 EC2 instances, maybe 10. All of a sudden, you have multiple EC2 instances. This sounds like a problem for Kubernetes and Docker, right? Now, all of a sudden, you’re using ECS or EKS, the Kubernetes or container solution by AWS. You’re spinning up and down containers, and you’re spending a whole engineer’s time on maintaining this stateful distributed system.

Those are some of the worst systems to run because when it’s a stateful distributed system, it means that you are bound by the connections to that thing. You have to keep the browser open while someone is working with it, right? That’s just a painful architecture to run, and there are all these other little gotchas with Chromium.

Chromium, which is the open source version of Chrome, by the way, requires you to install all these fonts. You want emojis working in your browsers because your vision model is looking for the emoji; you need to make sure you have the emoji fonts. You need to make sure you have all the right extensions configured. Do you want ad blocking? How do you configure that? How do you actually record all these browser sessions?

It’s a headless browser; you can’t look at it, so you need to have some sort of observability. Maybe you’re recording videos and storing those somewhere. It all adds up to this giant monster of a piece of your project when all you wanted to do was run a lot of browsers in production for this little script to go to Google.com and search.

When I see a complex distributed system, I see an opportunity to build a great infrastructure company. We really abstract that away with Browserbase, where our customers can use these existing frameworks—Playwright, Puppeteer, Selenium—or our own Stagehand, connect to our browsers in a serverless-like way, control them, and then just disconnect when they’re done.

They don't have to think about the complex distributed system behind all of that. They just get a browser running anywhere, anytime, really easy to connect to.

I'm sure you have questions. I'll just ask my standard question with anything. Essentially, you're a serverless browser company, and there have been other serverless things that I'm familiar with in the past: serverless GPUs, serverless website hosting. That's where I come from with Netlify.

One question is, you promise to spin up thousands of browsers in milliseconds. I feel like there's no real solution that does that yet, and I'm curious how. The only solution I know is to keep a warm pool of servers around, which is expensive, but maybe not so expensive because they're just computers, just CPUs. So I'm just wondering.

Yeah. You nailed it, right?

Okay.

How do you offer a serverless-like experience with something that is clearly not serverless? The answer is, you need to be able to run many browsers on single nodes. We use Kubernetes at Browserbase, so we have many pods being scheduled. We have to predictably schedule them up or down.

Yes, thousands of browsers in milliseconds is the best-case scenario. If you hit us with 10,000 requests, you may hit us—

You would hit the limit.

—a slower cold start, right?

Yeah, yeah.

We've done a lot of work on predictive scaling and being able to route things to different regions. We have multiple regions at Browserbase where we have different pools available. You can also pick the region you want to go to based on lower latency. Round-trip-time latency is very important with these types of things. There's a lot of requests going over the wire.

For us, having a VM like Firecracker powering everything under the hood allows us to be super nimble and spin things up or down really quickly with strong multi-tenancy. But in the end, these are the complex infrastructural challenges that we have to deal with at Browserbase.

We have a lot more stuff on our roadmap to allow customers to have more levers to pull, to choose between: do you want really fast browser startup times, or do you want really low costs? If you're willing to be more flexible on that—

Yeah, it's a slider.

—we may be able to work better for your use cases.

You seem to use Firecracker. Shouldn't Fargate do that for you, or did you have to go lower-level than that?

We had to go lower-level than that.

I find this a lot with Fargate customers—

Yeah.

—which is alarming for Fargate.

We used to be a giant Fargate customer. Actually, the first version of Browserbase—

Everyone says this.

—was ECS and Fargate. Unfortunately, it's a great product. I think we were actually the largest Fargate customer in our region for a little while.

No. What?

Yeah, seriously. Unfortunately, it's a great product, but I think if you're an infrastructure company, you actually have to have a deeper level of control over these primitives.

Mm.

I think the same thing is true with databases. We've used other database providers, and I think—

Yeah, serverless Postgres.

Yeah. When—

Shocker.

—when you're an infrastructure company, you're on the hook if any provider has an outage. I can't tell my customers, “Hey, we went down because so-and-so went down.” That's not acceptable.

For us, we've really moved to bringing things internally. It's kind of the opposite of what we preach. We tell our customers, “Don't build this in-house.” But then we're like, “We build a lot of stuff in-house.” I think it really depends on what is in the critical path. We try to have deep ownership of that.

On the distributed-location side, how does that work for the web, where you might get served different content in different locations, but the customer is expecting—if you're in the US, I'm expecting the US version, but if you're spinning up my browser in France, I might get the French version?

Yeah, it's a good question. Generally, on localization, there is a thing called locale in the browser. You can set what your locale is if you're in an en-US browser or not. But some things do IP-based routing, and in that case, you may want to have a proxy.

Let's say you're running something in Europe, but you want to make sure you're showing up from the US. You may want to use one of our proxy features. You can turn on proxies to say, “Make sure these connections always come from the United States,” which is necessary, too, because when you're browsing the web, you're coming from a data-center IP, and that can make it a lot harder to browse the web.

We do have this proxy supernetwork where we'll pick the right proxy for you based on where you're going, so you can reliably automate the web. But if you get scheduled in Europe, that doesn't happen, especially if you try to schedule it as close as possible to the origin you're trying to go to.

Generally, you have control over the regions where you can put your browsers. You can specify West 1 or East 1 or Europe. We only have 1 region in Europe right now, actually.

What's harder, the browser or the proxy? To me, it feels like proxying reliably at scale is much harder than spinning up browsers at scale. I'm curious.

It's all hard. It's layers of hard, right?

Well, yeah, yeah, yeah. Of course.

I think it's different levels of hard. The thing with the proxy infrastructure is that we work with many different web proxy providers, and some are better than others. Some have good days, and some have bad days.

Our customers who've built browser infrastructure on their own have to go and deal with sketchy actors. First, they figure out their own browser infrastructure, and then they've got to go buy a proxy. You can pay in Bitcoin, and it just feels a little sus, right? It's like you're buying drugs when you're trying to get a proxy online.

We have deep relationships with these counterparties. We're able to audit them and say, “Is this proxy being sourced ethically? It's not running on someone's TV somewhere.”

Is it free-range? Or what—

Yeah. Free-range, organic proxies, right?

Right.

We do a level of diligence. We're SOC 2, so we have to understand what is going on here. We're able to make sure that we route around proxy providers that aren't working. There are proxy providers where the proxy will stop working all of a sudden, and if you don't have redundant proxying on your own browsers, that's a hard down for you, or you may get some serious impacts there.

With us, we intelligently know, “Hey, this proxy isn't working. Let's go to this one.” You can build a network of multiple providers to really guarantee the best uptime for our customers.

Yeah. So you don't own any proxies—

We don't own any proxies.

Per se.

The team has been saying, “Who wants to take home a little proxy server?” But not yet. We're not there yet, you know?

It's a very mature market. I don't think you should build that yourself. You should just be a super-customer of them. Scraping, I think, is the main use case for that. I guess that leads us into CAPTCHAs and also auth, but let's talk about CAPTCHAs. You had a little spiel that you wanted to talk about CAPTCHA stuff.

4. CAPTCHAs Give Way To Agent Auth

Oh, yeah. I think a lot of people ask—if they're thinking about proxies, they're thinking about CAPTCHAs, too. I think it's the same thing. You can go buy CAPTCHA solvers online, but it's the same buying experience. It's some sketchy website. You have to integrate it. It's not fun to buy these things, and you can't really trust that the docs are good.

What Browserbase does is integrate a bunch of different CAPTCHA providers. We do some stuff in-house, but generally, we just integrate with a bunch of known vendors and continually monitor and maintain these things and say, “Is this working or not? Can we route around it or not?” And really try—

These are CAPTCHA solvers.

CAPTCHA solvers. Yeah.

Not CAPTCHA providers—CAPTCHA solvers. Sorry, CAPTCHA solvers.

Yeah. We really try to make sure all of that works for you. As a developer, if I'm buying infrastructure, I want it all to work all the time, and it's important for us to provide that experience by making sure everything works and monitoring it ourselves.

Yeah.

Right now, the world of CAPTCHAs is tricky. I think AI agents, in particular, are very much ahead of the internet infrastructure. CAPTCHAs are designed to block all types of bots, but there are now good bots and bad bots. I think in the future, CAPTCHAs will be able to identify who a good bot is, hopefully via some sort of KYC.

For us, we've been very lucky. We have very little to no known abuse of Browserbase because we really look into who we work with. For certain types of CAPTCHA solving, we only allow them on certain types of plans because we want to make sure that we know what people are doing and what their use cases are. That's really allowed us to try and be an arbiter of good bots, which is our long-term goal. I want to build great relationships with people like Cloudflare so we can agree, “Hey, here are these acceptable bots. We'll identify them for you and make sure we flag them when they come to your website: this is a good bot.”

I see.

Cloudflare said they want to do more of this, so by default, if they think you're an AI bot, they're going to reject you. I'm curious if you think this is something that's going to be at the browser level or, I mean, the DNS level with Cloudflare seems more like where it should belong, but I'm curious how you think about it.

I think the web's going to change. I think the internet as we have it right now is going to change, and we all need to just accept that the cat is out of the bag. Instead of wishing the internet were like it was in the 2000s, where you could have free content online that wouldn't be scraped, it's just not going to happen. Instead, we should think about, one, how can we change the models of information being published online so people can adequately commercialize it? But two, how do we rebuild applications that expect AI agents are going to log in on their behalf?

Those are the things that are going to allow us to identify good and bad bots, and I think the team at Clerk has been doing a really good job with this on the authentication side. I actually think auth is the biggest thing that will prevent agents from accessing stuff, not CAPTCHAs. I think there will be agent auth in the future. I don't know if it's going to happen from an individual company, but actually authentication providers could have a hidden login-as-agent feature.

You put in your email, and you'll get a push notification that says, “Hey, your browser-based agent wants to log into your Airbnb.” You can approve that, and then the agent can proceed. That really circumvents the need for CAPTCHAs or logging in as you and sharing your password. I think agent auth is going to be one way we identify good bots going forward, and I think a lot of this CAPTCHA-solving stuff is really a short-term problem as the internet reorients itself around how it's going to work with agents browsing the web just like people do.

Yeah. Stytch recently was on Hacker News for talking about agent experience, AX, which is something that Netlify is also trying to clone, coin, and talk about. We've talked about this on previous episodes. I actually think that's maybe the only part of the tech stack that needs to be reinvented for agents. Everything else can stay the same: CLIs, APIs, whatever.

But auth—yeah, we need agent auth. It's mostly short-lived. It should be a distinct identity from the human, but paired. I almost think that, in the same way that every social network should have your main profile and then your alt accounts, or your Finsta, every human token should be paired with an agent token. The agent token can go and do stuff on behalf of the human token, but it should not be presumed to be the human.

Yeah, it's actually very similar to OAuth, is what I'm thinking. And, you know, Reed from Stytch, Colin from Clerk, and Okta Ventures are all investors in Browserbase because I hope they solve this, because it'll make Browserbase's mission more possible so we don't have to overcome all these hurdles.

But I think it'll be an OAuth-like flow where an agent will ask to log in as you. You'll approve the scopes: it can book an apartment on Airbnb, but it can't message anybody. Then the agent will have some sort of—

Yeah.

—role-based access control within an application.

Yeah.

I'm excited for that.

The tricky part is that there's one more layer of delegation here, which is like you're authing my user's user or something like that. I don't know if that's tricky or not. Does that make sense?

Yeah, you know, actually, at Twilio, I worked on the login—

Identity—

—identity—

Yeah.

—and access management teams, right? So I built Twilio's login page and SSO.

You were the intern on that team, and then you became the lead 2 years later?

Yeah, yeah, I started as an intern in 2016, and then I was the tech lead of that team 2 years later.

How? That's not normal.

I didn't have a life.

He's not normal. Look at this guy.

Yeah.

I didn't have a girlfriend.

Yeah, you can't call him normal.

I just loved my job. I don't know. I applied to 500 internships for my first job, and I got rejected from every single one of them except for Twilio and then eventually Amazon. They took a shot on me, and I was getting paid money to write code, which was my dream.

I'm very lucky that this coding thing worked out because I was going to be doing it regardless. I was able to spend a lot of time on a team that was growing at a company that was growing, and it informed a lot of this stuff here. I think these are problems that have been solved with the SAML protocol and SSO. I think it's a relationship with WebAuthn, these different types of authentication schemes that you can use to authenticate people.

The tooling is all there. It just needs to be tweaked a little bit to work for agents, and I think the fact that there are companies that are already providing authentication as a service really sets it up well. The thing that's hard is reinventing the internet for agents. We don't want to rebuild the internet. That's an impossible task, and I think people often say, “Well, we'll have this second layer of APIs built for agents.” I'm like, we will for the top use cases, but instead, if we can just tweak the internet as is, which is on the authentication side, I think we're going to be the dumb ones going forward, unfortunately.

I think AI's going to be able to do a lot of the tasks that we do online, which means that it will be able to go to websites, click buttons on our behalf, and log in on our behalf too. With this web-agent future happening, I think with some small structural changes, like you said, it feels like it could all slot in really nicely with the existing internet.

There's one more thing, which is the live-view iframe, which lets you take control.

Yeah.

Obviously, that's very key for Operator now. But is there anything interesting technically there, or will people always want this?

5. Human Control Builds Agent Trust

It was really hard to build. Headless browsers—you don't see them, right? They're running in a cloud somewhere. You can't look at them. It's a weird name. I wish we came up with a better name for this thing, but you can't see them, right?

Customers don't trust AI agents, at least on the first pass. So what we do with our live view is that, when you use Browserbase, you can actually embed a live view of the browser running in the cloud for your customer to see it working, and that's the first reason: to build trust. You have a script that's going to automate a website, and you can embed it into your web application via an iframe. Your customer can watch that thing go.

Then we added two-way communication. Now, not only can you watch the browser being operated by AI, but if you want to pause and actually click around or type within this iframe that's controlling a browser, that's also possible. This is all thanks to a lower-level protocol called the Chrome DevTools Protocol. It has an API called `Page.startScreencast`, and you can also send mouse clicks and button clicks to a remote browser. This is all embeddable within iframes. You have a browser within a browser, yo.

And then you assimilate the screen and the click on the other side.

Exactly, and this is really nice, often for, let's say, a CAPTCHA that can't be solved. You saw this with Operator. Operator actually uses a different approach. They use VNC, so you're able to see the whole window here.

What we're doing is something a little lower-level with the Chrome DevTools Protocol. It's just PNGs being streamed over the wire. But the same thing is true, right? “Hey, I'm running a window. Pause. Can you do something in this window, human? Okay, great. Resume.”

Sometimes with 2FA tokens, like if you get that text message, you might need a person to type that in. Web agents still need human-in-the-loop workflows. You still need a person to interact with a browser, and building a UI to proxy that is kind of hard. You may as well just show them the whole browser and say, “Hey, can you finish this up for me?” Then let the AI proceed afterward.

Is there a future where I stream my current desktop to Browserbase?

I don't think so. I think we're very much cloud infrastructure.

Server.

Yeah.

I think a lot of the stuff we're doing, we do want to build tools. We'll talk about Stagehand, the web agent framework, in a second. A lot of people are going desktop-first for consumer use, and I think Claude is doing a lot of this. MCP is really oriented around the Claude desktop app for a reason, right? I think a lot of these tools are going to run on your computer.

I think it's breaking out. People are putting it on a server.

Oh, really? Okay. Well, sweet. We'll see.

I was surprised that was it.

I think The Browser Company's Dia Browser runs on your machine.

What is it?

I used to use Arc.

Yeah.

It died.

I haven't used Arc, but I'm a big fan of The Browser Company. I think they're doing a lot of cool stuff in consumer.

As far as I understand it, Dia is a browser where you have a sidebar where you can chat with it, and it can control the local browser on your machine. If you imagine what a consumer web agent is, it lives alongside your browser. I think Google Chrome has Project Mariner. I almost call it Project Marinara for some reason. I don't know why.

No, I think it's someone who really likes Waterworld.

Oh, I see.

Yeah. Okay. Project Mariner is a similar thing to Dia Browser, as far as I understand it. You have a browser that has an AI interface that will take over your mouse and keyboard and control the browser for you.

It's great for consumer use cases, but if you're building applications that rely on a browser and it's more part of a greater AI app experience, you probably need something that's more like infrastructure, not a consumer app.

I've explored a little bit in this area. Do people want branching? So I have the state of whatever my browser is in, and then I want 100 clones of this state. Do people do that?

People don't do it currently.

Yeah.

But it's definitely something we're thinking about. I think the idea of forking a browser is really cool, but technically hard. We're starting to see this in code execution, where people are forking code-execution processes, forking tool calls, or branching tool calls. I haven't seen it at the browser level yet, but it makes sense.

If an AI agent is using a website and it's not sure what path it wants to take to crawl the website to find the information it's looking for, it would make sense for it to explore both paths in parallel.

A road not taken.

Yeah. Hopefully it finds the right answer and then says, “Okay, this was actually the right one,” memorizes that, and goes there in the future. It's on the roadmap for sure. Don't mock my roadmap, please.

How do you actually do that?

Yeah.

How do you fork? I feel like the browser is so stateful for so many things.

Serialize the state, restore the state. I don't know.

That's one of the reasons why we haven't done it yet. It's hard, you know? To truly fork, it's actually quite difficult.

The naive way is to open the same page in a new tab and hope that it's at the same thing.

Oh, yeah.

That it's at the same thing. But if you have a form halfway filled out, you may have to take the whole container, pause it, duplicate all the memory, and restart from there. It could be very slow.

We haven't found the right approach. The easy thing to fork is just to copy the page object.

The whole thing, yeah.

You know? But I think there needs to be something a little bit more robust there.

Morph Labs has this infinite-branching thing.

Morph Labs, exactly.

They wrote a custom fork of Linux or something that let them save the system state.

Modal Labs, hit me up. I'll be a customer.

I think that's the only way to do it, unless Chrome has some special API for you.

Yeah, there's probably something we'll reverse-engineer one day. I don't know.

Let's talk about Stagehand, the AI web-browsing framework. You have 3 core components: observe, extract, and act. Pretty clean landing page. What was the idea behind making a framework?

6. Stagehand Turns Browsing Into Tools

There are 3 frameworks that are already very popular: Puppeteer, Playwright, and Selenium. Those are for building hard-coded scripts to control websites.

As soon as I started to play with LLMs plus browsing, I caught myself generating Playwright code to control a website. I would take the DOM, pass it to an LLM, and say, “Can you generate the Playwright code to click the appropriate button here?” It would do that, and I was like, “This really should be part of the frameworks themselves.”

I became really obsessed with SDKs that take natural language as part of the API input, and that's what Stagehand is. Stagehand exposes 3 APIs, and it's a superset of Playwright.

If you go to a page, you may want to take an action—click on a button, fill in the form, et cetera. That's what the act command is for. You may want to extract some data. This takes natural language, like, “Extract the winner of the Super Bowl from this page.” You can give it a Zod schema so it returns structured output.

Maybe you're building an agent loop and you want to see what actions are possible on this page before taking one. You can use observe. It will generate a list of actions, and you can guide it: “Give me actions on this page related to buying an item.” It can return “buy it now,” “add to cart,” “view shipping options,” and you can pass that to an LLM or an agent loop to say, “What's the appropriate action given this high-level goal?”

Stagehand isn't a web agent. It's a framework for building web agents, and we think agent loops are actually pretty close to the application layer because every application probably has different goals or different ways it wants to take steps.

I don't think I've seen a generic, really good AI agent framework here. Maybe you guys are the experts. Everyone has their own special sauce, right? I see a lot of developers building their own agent loops, and they're using tools. I view Stagehand as the browser tool.

We expose act, extract, and observe. Your agent can call these tools, and you don't have to worry about generating Playwright code performantly or running it. You can integrate these 3 tool calls into your agent loop and reliably automate the web.

A special shout-out to Anirudh, who I met at your dinner and who I think listens to the pod. So, hey, Anirudh.

Ani's the man. He's a Stagehand guy, you know.

The interesting thing about each of these APIs is that each is a startup. Specifically, extract: Firecrawl is extract. There's Extruct AI. There's a whole bunch of extract companies. They just focus on extract.

I'm curious because I feel like you guys are going to collide at some point. Right now, it's friendly. Everyone's in a blue ocean. At some point, it's going to be valuable enough that there's some turf battle here.

I don't think you have a dog in the fight. You can mock extract to use an external service if they're better at it than you. But it's an observation that, in the same way I see each option or each checkbox in the set of custom GPTs becoming a startup, or each box in the Karpathy chart becoming a startup, this is also becoming a thing.

The way Stagehand works is that it's MIT-licensed and completely open source. You bring your own API key to the LLM of your choice. You can choose your LLM. We don't make any money off extract.

Yeah.

We really only make money if you choose to run it with our browser. You don't have to. You can actually use your own browser, a local browser.

Stagehand is completely open source for that reason. If you're building really complex web-scraping workflows, I don't know if Stagehand is the tool for you. I think it's more for when you're building an AI agent that needs a few general tools, or if it's doing a lot of web-automation-intensive work.

But if you're building a scraping company, Stagehand's not your thing. You probably want something that's going to get HTML content, convert that to Markdown, and query it. That's not what Stagehand does. Stagehand is more about reliability.

I think we focus a lot on reliability and less on cost optimization and speed at this point.

The way Stagehand works is, like, `page.act("click on the Quick Start")`, right? It's the integration test for the code that you would have to write anyway—the Puppeteer code that you have to write anyway.

When the page structure changes, because it always does, this is still the test. This is still the test that I would have to write.

Yeah.

So it’s kind of like a testing framework that doesn’t need implementation detail.

Well, yeah. Puppeteer, Playwright, and Selenium were all designed as testing frameworks, right?

And now people are hacking them together to automate the web. I would say—and maybe this is me being too specific—but when I write tests, if the page structure changes without me knowing, I want that test to fail. So I don’t know if AI is regenerating that. People are using Stagehand for testing, but it’s more for usability testing, not testing whether the front end has changed.

Yeah.

But generally, where we’ve seen people really take off is if they’re using something like Operator or Deep Research. They’re using Stagehand to power that tool calling in their own agent loop.

Okay, cool. So let’s go into Operator, the first big agent launch of the year from OpenAI. Seems like they have a whole bunch scheduled. You were on break, and your phone blew up. What’s your general view of computer-use agents, as they’re calling it? The overall category, before we go into Open Operator—just the overall promise of Operator. I will observe that I tried it once. It was okay, and I never tried it again.

7. Operator Shows The Computer Use Future

That tracks with my experience, too. I’m a huge fan of the OpenAI team. I think that I do not view Operator as the company killer for Browserbase at all. I think it actually shows people what’s possible. I think computer-use models make a lot of sense, and I’m most excited about their ability to really take screenshots, reason, and output steps.

I think using mouse clicks and mouse coordinates has proved to be less reliable than I would like, and I just wonder if that’s the right form factor. What we’ve done with our framework is anchor it to the DOM itself, anchor it to the actual item. So if it’s clicking on something, it’s clicking on that thing. It’s more accurate.

No matter where it is.

Yeah, exactly.

Yeah.

Because it really ties in nicely and can handle the whole viewport in one go, whereas Operator can only handle what it sees.

Can you hover? Is hovering a thing that you can do?

I don’t know if we expose it as a tool directly, but I’m sure there’s an API for hovering.

Yeah.

Move the mouse to this position.

Yeah.

I think you can trigger hover via the JavaScript on the DOM itself.

Yeah.

But no, I think when we saw computer use, everyone’s eyes lit up because they realized, wow, AI is going to actually automate work for people. And I think seeing that happen from both of the labs—and I’m sure we’re going to see more labs launch computer-use models—I’m excited to see all the stuff that people build with it.

I’d love to see computer use power controlling a browser on Browserbase. And I think Open Operator, which was our open-source version of OpenAI’s Operator, was our first take on how we can integrate these models into Browserbase: we handle the infrastructure and let the labs do the models.

I don’t have a sense that Operator will be released as an API. I don’t know. Maybe it will. I’m curious to see how well that works, because I think it’s going to be really hard for a company like OpenAI to do things like support CAPTCHA solving or have proxies. I think it’s hard for them structurally. Imagine a New York Times headline: “OpenAI CAPTCHA solving.” That would be a pretty bad headline.

Mm-hmm.

This New York Times headline: “Browserbase solves CAPTCHAs.”

No one cares. Yeah.

No one cares. And our investors are bored. We’re all okay with this. We’re building this company knowing that CAPTCHA solving is short-lived until we figure out how to authenticate good bots.

Mm.

I think it’s really hard for a company like OpenAI, which has this brand that’s so, so good, to balance that with the icky parts of web automation, which can be kind of complex to solve.

I’m sure OpenAI knows who to call whenever they need you.

Yeah, right.

Yeah.

I’m sure they’ll have a great partnership.

A marketing thing for you? How do you think about resource allocation? You can spin this up very quickly, and now there’s all this Open Deep Research.

Yeah.

There’s Open Operator, Open Deep Research, all these things that people are building.

We started it, you know.

You’re the original Open—

I’m the original Open Operator, you know.

Is it just, “Hey, look, this is a demo, but we’ll help you build out an actual product for yourself”? Are you interested in going more of a product route? That’s kind of the OpenAI way, right? They started as a model provider, and then—

We’re not interested in going the product route yet. I view Open Operator as a reference project. Let’s show people how to build these things using the infrastructure and models that are out there, and that’s what it is.

Open Operator is very simple. It’s an agent loop. It says: take a high-level goal, break it down into steps, and use tool calling to accomplish those steps. It takes screenshots and feeds those screenshots into an LLM with the step to generate the right action. It uses Stagehand under the hood to actually execute this action.

It doesn’t use a computer-use model, and it has a nice interface using the live view that we talked about—the iframe—to embed that into an application. I felt like people on launch day wanted to figure out how to build their own version of this, and we turned that around really quickly to show them. I hope we do that with other things like Deep Research.

We don’t have a Deep Research launch yet. I think David from Morphic actually has an amazing Open Deep Research that he launched; it has 10K GitHub stars now. So he’s crushing that. But I think if people want to build these features natively into their application, they need good reference projects, and I think Open Operator is a good example of that.

I’m actually pretty bullish on API-driven Operator because that’s the only way that you can do it once it’s reliable enough, obviously. And now we’re nowhere near it, but give it 5 years. It’ll happen, you know? Then you can spin this up, and browsers are working in the background, and you don’t necessarily have to know. It just books restaurants for you, whatever. I can definitely see that future happening.

I had this on the landing page here. This might be slightly out of order, but you have three use cases for Browserbase. Open Operator, or just the Operator use case, is kind of the workflow automation use case, and it competes with UiPath in the RPA category. Would you agree with that?

Yeah, I would agree with that.

And then there are agents we talked about already, and web scraping, which I imagine would be the bulk of your workload right now, right?

8. Browserbase Automates More Than Scraping

No, not at all. I’d say actually the majority is browser automation. We’re kind of expensive for web scraping.

Okay.

I think if you’re building a web-scraping product, if you need to do occasional web scraping, or you have to do web scraping that works every single time, you want to use Browserbase. But if you’re building web-scraping workflows, what you should do is have a waterfall.

The first request is a curl to the website. See if you can get it without even using a browser. Then the second request may be a scraping-specific API. There are 1,000 scraping APIs out there that you can use to try and get data.

Ah.

ScrapingBee is a great example, right? Yeah. And then, if those 2 don’t work, bring out the heavy hitter. Browserbase will 100% work, right? It will load the page in a real browser and hydrate it.

I see. A lot of people don’t render the JavaScript.

Yeah.

Okay, cool. I just wanted to get a rough sense.

Yeah, exactly.

That’s true.

So the three big use cases, right? Automation, web data collection, and if you’re building anything agentic that needs a browser tool, you want to use Browserbase.

Is there any use case that you were super surprised by, that people might not even think about?

Oh, yeah.

Anything that you can share?

The long tail is crazy. One of the case studies on our website that I think is the most interesting is this company called Beni. So the way that it works is, if you’re on food stamps in the United States, you can actually get rebates if you buy certain things. Maybe you buy some vegetables and you submit your receipt to the government.

They'll give you a little rebate back, saying, “Hey, thanks for buying vegetables. It's good for you.” The process of submitting that receipt is very painful. The way Beni works is that you use their app to take a photo of your receipt, and then Beni will submit that receipt for you and deposit the money into your account. That's actually using no AI at all. It's all hard-coded scripts. They maintain the scripts. They've been doing a great job, and they've built this amazing consumer app.

It's an example of all these tedious workflows that people have to do to go about their day-to-day lives. I had never known about food stamp rebates or the complex forms you have to fill out for them. The world is powered by millions and millions of tedious forms and visas. Lighthouse is a customer, right? They do the O-1 visa. Millions and millions of forms are taking away humans' time, and I hope that Browserbase can help power software that automates away the web forms that we don't need anymore.

Yeah, I'm very supportive of that. I hate forms. I do think the government itself should embrace AI more to do more human-friendly form filling. But I'm not optimistic. I'm not holding my breath.

Mm-hmm.

Okay. I think I'm about to zoom out. I have a brief thing on computer use, and then we can talk about founder stuff. I tend to think of developer tooling markets as impossible triangles, where everyone starts in a niche and then starts to branch out. I already hinted at a little bit of this, right? We mentioned Morph, E2B, Firecrawl, and then there's Browserbase.

There's all this stuff where you have a serverless virtual computer that you give to an agent and let it do stuff with. There are various ways of connecting it to the internet. You can just connect to a search API, like SerpAPI or whatever other one—Exa is another one. That's where you're searching. You can also have a JSON/Markdown extractor, which is Firecrawl. Or you can have a virtual browser like Browserbase, or a virtual machine like Morph, and then there's also maybe a virtual code environment like Code Interpreter.

There's just a bunch of different ways to tackle the problem of giving a computer to an agent, and I'm just wondering if you see everyone happily coexisting in their respective niches. As a developer, do I just go and pick a shopping basket of one of each, or do you think that eventually people will collide?

I think that currently it's not a zero-sum market. We're talking about all of the knowledge work that people do that can be automated online—all of these trillions of hours that happen online where people are working—and I think there's so much software to be built that I tend not to think about how these companies will collide. I just try to solve the problem as best as I can and make this specific piece of infrastructure, which I think is an important primitive, the best I possibly can.

I think there are players that are actually going to launch over-the-top platforms—agent platforms that have all these tools built in, right? Who's building the Rippling for agent tools that has the search tool, the browser tool, the operating system tool, right?

Exactly.

There are some, right? I think in the end, what I have seen in my time as a developer, and I look at all the favorite tools that I have, is that for tools and primitives with sufficient levels of complexity, you need to have a solution that's really bespoke to that primitive. I am sufficiently convinced that the browser is complex enough to deserve a primitive. Obviously, I have to say that—I'm the founder of Browserbase, right? I'm talking my book.

Maybe I can give you one spicy take against just having a whole OS running. When I look at computer use when it first came out, I saw that the majority of use cases for computer use were controlling a browser.

Mm.

Do we really need to run an entire operating system just to control a browser? I don't think that's necessary. Browserbase can run browsers for way cheaper than you can if you're running a full-fledged OS with a GUI. I think that's just an advantage of the browser. Browsers are little OSes, and you can run them very efficiently if you orchestrate them well. I think that allows us to offer 90% of the functionality and platform needed at 10% of the cost of running a full OS.

Yeah, I definitely see the logic in that. There's a Marc Andreessen quote—I don't know if you know this one—where he basically observed that the browser is turning the operating system into a poorly debugged set of device drivers, because most of the apps have moved from the OS to the browser, so you can just run browsers.

And there's a place for OSes, too. I think there are some applications that only run on Windows operating systems. Eric from PIG.dev in the last YC batch—he's building a way to run tons of Windows operating systems for you to control with your agent. There are some legacy EHR systems that only run on Internet Explorer and Windows.

PIG.dev.

Yeah. I think that's it. I think there are use cases for specific—

Well.

…operating systems for specific legacy software, and I'm excited to see what he does with that.

I just wanted to give a shout-out to the PIG.dev website. The pigs jump when you click on them. It's great.

Yeah.

Yeah, I love that.

Eric—he's also the former co-founder of Banana.dev.

Ah, that Eric.

He's chief of product. Yeah.

Yeah, that Eric. Okay. Well, he abandoned Banana.dev for PIG.dev, so I hope he doesn't—

Well, I hope he doesn't start going hog wild with pigs now, like he was going bananas.

A little toy pig. Yeah, I love that.

What else are we missing? I think we covered a lot of the Browserbase product history.

What do you wish people asked you?

Yeah.

9. Software Will Use Software

I wish people would ask me more about what the future of software will look like, because I think that's really where I've spent a lot of time thinking about why I do Browserbase. For me, starting a company is a means of last resort. You shouldn't start a company unless you absolutely have to. I remain convinced that the future of software is software where you're going to click a button and it's going to do stuff on your behalf.

Right now, software—you click a button, and it maybe calls a backend API and computes some numbers. It modifies some text, whatever. But the future of software is software using software.

So I may log into my accounting website for my business, click a button, and it's going to load up my Gmail, search my emails, find the thing, upload the receipt, and then comment it for me, right? It may do that using APIs, maybe a browser. I don't know. I think it's a little bit of both.

But that's completely different from how we've built software so far, and that future of software has different infrastructural requirements. It's going to require different UIs. It's going to require different pieces of infrastructure. I think browser infrastructure is one piece that fits into that, along with all the other categories you mentioned.

I think it's going to require developers to think differently about how they've built software at the application level so far, and I'm excited to explore more what that means. I think we've seen from the customers that use Browserbase so far some really innovative ways to take software and really reimagine it for AI: build things that have chat interfaces, build things that have human-in-the-loop flows, build things that are more asynchronous because AI is slower. Those are patterns that are still emerging, and I don't think we have all the best practices yet.

I don't have much to—

All right, sweet.

…to feedback on that. That's true.

Paul's right.

Paul's right.

Quoted by—

You heard it here first.

…by swyx. Yeah, amazing. I'm framing that.

It is not specific enough to be wrong.

That means Paul's right to me still. I don't know if I'm hearing that wrong.

I always try to prompt people for falsifiable predictions because you can predict that things will be better generically, but how? Those are the things where you put a little skin in the game…

Yeah, I can predict that Browserbase will be a billion-dollar company one day. So let's check back in 5 years, and if I'm a PM at Coinbase, then something went wrong.

Yeah, yeah, yeah. Oh, boy. We picked out a couple of your tweets. I think you're a pretty building-in-public kind of guy. The main thing I want to highlight as well is that you emphasized this at the start of your intro, which is that you're a solo founder.

I think that there's a movement toward more solo founders in the Valley more generally, but people who are hearing this for the first time have no idea. They're like, “What do you mean? YC forces me to get a co-founder. What is this?” I've heard you talk about this before, but maybe you want to recap your spiel for folks who haven't heard about it.

10. Solo Founders Move Faster

Yeah. I've had co-founders in my past company. I love my co-founders. They're at my wedding. I think if you want to move extremely fast as a company, one of the hard parts about having co-founders is that you have to do the co-founder alignment and then the company alignment. Then there are people on the team who probably tell things to one co-founder because they have a favorite, and that co-founder has to represent their interests.

But Browserbase is a benevolent dictatorship. If I want to make a change, I work with the team, we all decide together, and we move quickly. We don't have an extra layer of buy-in within the co-founder layer. Frankly, especially with dev tools companies, if you're able to talk about your product and talk with customers, and you can build product, you don't need to have a business guy or a business side. I'm a developer first and foremost. I was raised by 2 salespeople, so I guess that's why I can talk to customers or something.

What kind of sales?

My mom and dad did semiconductor and pharmaceutical sales.

Oh, very different.

Yeah, very different.

But also very enterprise. Good.

Yeah. It rubbed off on me in some way. I was just trying to play WoW as a kid, and they made me play sports, so I don't know how it worked out the way it did.

But it does all come back to, as a solo founder, you need to be willing to go out there and talk about your product, go talk to customers, go convince people to work for you, but then also have core principles of how you want to build this company and what product you want to build. Thankfully, if you can do all of that, you can be a solo founder. You just have to hire fast and put the right team around you, and I'm lucky to have the team that we do surrounding me and lifting the whole company up.

There's the decision-making, and then there's the culture of a company. Obviously, as a solo founder, you have huge influence on everybody. Apple is maybe the usual example.

Well, not solo.

Jobs and Wozniak.

Okay.

No, no. You can have 2 co-founders who are each polarizing in their own—

There was a third co-founder, by the way.

Yeah.

Who's the third co-founder? I don't know. He sold his shares very early on. Nobody talks about him, but he always has a bit of regret.

But anyway, have you thought about building the culture? Startups are super intense, but you're also going to just run yourself into the ground all the time. Any insight on doing it solo?

Yeah. I talked about how it's easier for me to make decisions as a solo founder. The real cheat code is having a great team that you give a lot of agency and ownership to. A lot of people make the little, tiny decisions that go into everything that makes Browserbase great, like the website, for example. I had some involvement with that, but a lot of that was the team, right? And the product.

I think the team really has ownership of a lot of these day-to-day decisions that add up to make a cohesive product experience. Culturally, we're fully in person. Maybe that's one crazy take that we have. But we're also not too in person. Our first meeting's at 10:00 AM. People leave around 5:00 or 6:00. We work Monday to Friday in person, and that's the expectation, right? I think people have gone too far with in-person work, where they're 7 days a week in the office, 9:00 AM to 9:00 PM. That's too much.

Just an anecdote: I just visited an office. I'll keep them anonymous for now, but to my face, we are 9/9/6.

Yeah.

For those who don't know, 9/9/6 is 9:00 AM to 9:00 PM, 6 days a week.

I think we've taken it a little too far. For some teams, I know another anonymous company that does something like 9/9/6, and they're crushing it right now, right? It does get results, but I think for our culture, we gather in person, we put pants on every day, and go to the office so that we can all work together.

Okay.

Or shorts, I guess, right?

Okay.

We all know we're going to work outside of the office. We're going to work at home sometimes, and we might come in on a weekend. The weekends are for fun work, and that's really where we get to let people work on stuff that's not on the roadmap. That empowers them to build something and bring it back to the team on Monday and say, “Look what I built. This is cool.”

Culturally, we're a lot of former YC CTOs, ex-founders, or future founders. I've just found that those people tend to be really great early hires for a company. They get it. I think for them, especially the ex-YC people who maybe didn't find PMF, coming in and being at a company with PMF is such a refreshing thing for them because they can just come in and execute. There are so many clear things we have to go build. If you're a talented engineer, being able to go build and make an impact every single day is super fulfilling.

My question, on the other hand, is that you also talk a lot about recruiting, especially on the podcast. How come there's no Browserbase recruiting agent?

That's a good question. I think it's because I don't do that much outbound. I do message people, but a lot of it is now through referrals. It's very targeted. If I see somebody working on something really cool, I just message them.

Okay.

I don't want something trawling the web and messaging every Kubernetes or Firecracker expert. I try to look for them in my passive web browsing, and when I find somebody, I want to take the time personally to say, “Hey, I love what you're doing. I think it's really cool, and let's have a conversation.”

Yeah, off of Hacker News and other stuff.

Yeah. I love to hire off of Hacker News.

Yeah. I'll let you plug at the end. My attempt at this failed because I really hate LinkedIn Sales Navigator. I think that it is just grifting on top of people doing data entry for LinkedIn, and I hope that Browserbase will someday help to kill LinkedIn Sales Navigator. That's my—

I don't know if we will directly, but one of our customers definitely is trying to do that. I think there's a couple that are on it. These AI SDR companies are crushing it.

Yeah. The 9/9/6 company was an AI SDR company. Very classic.

There we go.

This was great. Anything—did we miss? You got the run clubs too. What other things do you mix in, like building the company culture—

Mm-hmm.

—and the community culture? I know you bring people together—

Yeah. I think we try to build in public, and you can see a lot of the Browserbase people on Twitter. Every Monday, we have a run club. People go running together. We don't run very fast, but it's a good way to spend time together.

I just look back fondly on my time being in person at my first company. We have people with a mix of backgrounds: people who are just early in their careers and people who've been in the workforce for 20 or 30 years. So it's not just a young-people company; it's a huge mix.

But when you make people make a polarizing decision of, “I will come to an office 5 days a week,” people then end up making more similar decisions that are aligned with the culture. It's almost like if you can make your culture binary—you're in or out—it becomes easier to assimilate and keep a cohesive culture. I think that starts with being in the office for us, but for other people it could be moving, using Discord versus Slack, or other binary decisions that people may have to make.

One thing I like asking founders is: you're famously not an AI company. You serve AI companies, but you're not yourself an LLM-consuming company. But if you were, what company would you start? What's obviously a good idea?

I had this tweet forever ago: there's so much money to be made in taking proprietary research and turning that into an automation, which is obviously a very Browserbase-inspired one. Listening to all the city hall or town hall meetings in little towns, knowing when they're going to approve a new Walmart or something, and then buying up real estate around the Walmart because that will go up when they install this thing.

It's really interesting to think about how you can find new channels for data that will allow you to make high-alpha decisions and benefit you financially.

So I think there's some interesting stuff there: just a bunch of conversations that happen in real life, that are recorded, that are online, that you can go find using a web browser, of course, and then making some interesting decisions off of that.

Yeah.

I don't know, I like—

That's a very—

—the browser stuff. It's on brand, right? I have to. I'm consistent, at least.

Do not look at it on your phone—

Yeah.

—or a native app. Only look at it through the browser.

My favorite part of one of his videos was that they had these guys holding a bee behind them while they were doing the demo. It was a real Easter egg–type thing.

Yeah.

That was Stagehand, right?

Yeah, the Stagehand video. They're not holding it; they're actually wearing these bee boxes on their heads. We shot it 5 times, and poor Sean and Sahil are bobbing their heads back and forth with these bee boxes on because, hey, we can't afford special effects, man.

This is a business.

We're on a serious schedule.

Good detail. Good eye for detail there. Yeah, thank you so much. Congrats on all your success.

Yeah. Thanks, pal. Thanks for having me, guys. It's been a really good time.

Yeah, I'm sure we'll have you back again.

Yeah, I'd love to come back.