BrowserAct
Web browser automation for AI agents
1.6K followers
Web browser automation for AI agents
1.6K followers
BrowserAct is built for agents using the web. It gives agents a browser layer for real websites, so they can pass blocked pages, adapt to real scenarios, run multiple tasks safely, and return clean web data for reasoning. Use BrowserAct when an agent needs to browse, click, extract, fill forms, upload files, work inside logged-in sites, handle verification, or run repeatable browser workflows.
Giving agents a dedicated browser layer with session isolation is a smart shift from treating the web as just an API to treating it as an environment agents actually live in.
@ilko_kacharov Exactly. That is very close to how we think about it.
For many real workflows, the web is not just an endpoint to call. It is a stateful environment with login state, sessions, dynamic UI, verification, and interruptions.
BrowserAct is built to give agents a browser layer they can operate in: isolated sessions, real browser state, clean data, verification handling, and human handoff when needed.
Dune
As someone focused on building physical interfaces to trigger agentic workflows, I know that the hardware trigger is only as good as the execution layer behind it. The web is messy, and broken workflows or verification blocks completely ruin the seamless experience users expect.
Love the focus on giving agents a secure browser layer. I'm curious—how does BrowserAct handle unexpected UI changes or random pop-ups on a site to ensure the agent doesn't get stuck in a loop during a repeatable workflow? Brilliant utility, congrats on the launch!
@dhanrajchoudhary Thanks! That is exactly the kind of workflow BrowserAct is designed for.
For unexpected UI changes, BrowserAct does not rely on a fixed recording or stale selectors. The agent can call `state` to read the current interactive elements, act on the current indexes, wait for the page to stabilize, and then call `state` again if the page changes.
For random pop-ups or dialogs, BrowserAct also has tab and dialog commands, plus screenshots when visual inspection is needed.
And if the workflow hits something the agent should not guess on, like verification, 2FA, or a manual confirmation, it can use `remote-assist` so a human takes over the same browser session and the agent continues afterward.
So the goal is not to loop blindly, but to re-check state, handle what can be handled, and hand off when human input is needed.
Mom Clock
I’m happy to hunt BrowserAct today.
Anyone building AI agents knows how easily things break when they run into real-world web friction like dynamic pages, CAPTCHAs, or complex login flows.
After trying the product myself, it offers a practical, open-source solution to this problem. It provides a solid browser layer using real Chrome sessions, ensuring proper session isolation. Most importantly, the human-in-the-loop handoff lets agents pause for manual verification and then resume exactly where they left off without breaking the workflow.
@justin2025 Thanks for hunting us, Justin!
The handoff/resume piece is the real product surface here. Browser agents need clear failure artifacts: what state was preserved, what the human changed, and where the agent picked back up. That is what turns a demo into an operating tool.
BrowserAct
@krekeltronics This is exactly the framing we keep coming back to. A demo that completes the happy path isn't useful — an agent you can hand off to and resume from is. We're building toward three things specifically: a session state snapshot the user can actually read (not just a log), an explicit diff between agent actions and human edits, and resume from a named checkpoint rather than 'start over.' Still rough in places, but you've put your finger on the work that matters most. Curious what you've seen work elsewhere.
Browser automation always looks easy in demos, then dynamic pages and CAPTCHAs make it messy. Curious if BrowserAct exposes failure reasons clearly enough for an agent to decide retry vs ask a human, instead of just timing out.
great do you use proxies to not get banned?
BrowserAct
@marc_vuit Great question! Proxy support goes beyond just avoiding bans — it's essential for use cases like monitoring product prices across different countries in e-commerce, or extracting region-specific data. By routing through proxies in different locations, you get much more accurate, localized results that reflect what real users in those markets actually see
Scaling and isolation are usually an afterthought until they bite you. Nice to see them handled from day one.
BrowserAct
@shirley_hsia Thanks! Honestly, we learned this one the hard way on earlier projects — retrofitting isolation into something already in production is brutal. Way easier to bake it in from day one. Appreciate you noticing 🙏