BrowserAct

Web browser automation for AI agents

Productivity

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

hey! Browser automation for agents is genuinely exciting, the fact that it handles blocked pages and session isolation means agents can finally work on the real web, not just clean APIs.

One thing I'm curious about though, how does BrowserAct handle sites that fingerprint browser behaviour to detect bots? Because the hardest part of real-web automation isn't blocked pages, it's sites that let you in but silently serve you degraded or misleading data once they detect non-human patterns.

Is there any layer that makes the agent's browsing behaviour look more human at the request level?

The stale-position issue David raised is the thing I hit most. I do browser automation and every element ref I grab dies the moment the page navigates. I just re-find everything before each click, but it adds a round trip every time. Does BrowserAct batch that re-anchoring under the hood, or does the agent still need to request a fresh page state manually?

BrowserAct is one of those things I kept wishing existed, so happy to see it. The part that grabs me is letting agents actually drive a real browser instead of fighting with brittle scrapers or half-baked APIs. Curious about reliability though, when a site changes its layout, does the agent recover on its own, or do you end up babysitting the flows? Either way, nice work.

Congrats on the launch.
I currently use agent-browser, which is also OSS and agent first.
Why should I think about switching to this?

The detail that stands out to me is returning clean indexed data instead of raw DOM. On my own scraping agents half the token bill goes to dumping messy HTML into the model, so that part alone is worth a look.

What I'd actually worry about in prod is the CAPTCHA side. Auto-solving Turnstile and DataDome looks great on day one, but those vendors ship updates constantly and solve rates tend to rot fast. How do you keep that holding up over time, and when a job does fall back to a human, who eats that cost on a bulk run?

A lot of sites explicitly disallow automated access in their ToS, especially the ones with login walls or verification steps. Where does BrowserAct draw the line on which sites it'll automate against, is that left entirely to the user's judgment, or are there categories you won't touch regardless of what the agent's trying to do?

The human-in-the-loop fallback mechanism here is incredibly smart. Most browser agents fail completely the second a CAPTCHA or a complex MFA prompt pops up, wiping out the entire context and session state. @wendyba, how exactly does BrowserAct handle the handoff UX? When the CLI pauses for a human sign-off, does it spin up a secure, sandboxed VNC stream or proxy browser window where the user can manually clear the blocker, and how does it ensure the agent re-authenticates the DOM changes cleanly afterward? Congrats on the launch!

I’ve run into the same brittle-browser-step problem when testing agent flows. The e2e recording angle is interesting — curious how you handle flaky DOM changes after a site redesign?

This solves one of the biggest pain points for AI agents—actually interacting with the real web instead of just reasoning about it. The combination of browser automation, session isolation, and clean outputs is really impressive. Excited to experiment with this!

How does BrowserAct handle verification flows, like does it pause for a human or have any built in solve options?

If you had to pick one feature that makes BrowserAct outperform existing browser automation tools for AI agents, what would it be? I'd love to understand the biggest practical difference before giving it a spin.

BrowserAct feels like a missing infrastructure layer for AI agents. A lot of agent demos break the moment they hit real-world web complexity — logins, dynamic pages, CAPTCHAs, messy DOMs, or session handling. Giving agents a reliable browser layer that can extract clean data and take actions safely makes the whole “AI agent” idea much more practical. Excited to see how teams use this for research, workflow automation, and data ops. Congrats on the launch!

Seems like a much needed tool I'd definitely want to check out. Curious how this interacts with parallel agent sessions that may or may not have overlapping browser needs? Will each agent have their own isolated browser layer, do they share a browser layer, are they able to cross-coordinate across the same browser if needed?

selector stability breaks more agent runs than the reasoning does. do you lean on the accessibility tree or visual grounding when the dom shifts?

Excited for this! I've noticed that some CAPTCHAs are getting stricter on datacenter IP addresses, do you solve this for the toughest CAPTCHAs?