My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for a while, I didn't find a single mention of security anywhere (as far as I could tell!)
The only thing that I did find was zero data retention, which is mentioned as being 'on request' and only on the Enterprise plan.
I totally understand that you guys need to train and advance your model, but with suggested features like scraping behind login walls, it's a little hard to take seriously with neither of those two things anywhere on the site, so anything you could do to lift up those concerns would be amazing.
Again, you seem to have done some really cool stuff, so I'd love for it to be possible to use!
Update: The homepage says this in a feature box, which is... almost worst than saying nothing, because it doesn't mean anything? -> "Enterprise-grade security; End-to-end encryption, enterprise-grade standards, and zero-trust access controls keep your data protected in transit and at rest."
We take security very seriously and one of the main advantages of using Smooth over running things on your personal device is that your agent gets a browser in a sandboxed machine with no credentials or permissions by default. This means that the agent will be able to see only what you allow it to see. We also have some degree of guard-railing which we will continue to mature over time. For example, you can control which URLs the agent is allowed to view and which are off limits.
Until we'll be able to run everything locally on device, there must be a level of trust in the organizations that control the technology stack, passing from the LLM all the way to the infrastructure providers. And this applies to every personal information you disclose at any touch point to any AI company.
I believe that this trust is something that we and every other company in the space will need to fundamentally continue to grow and mature with our community and our users.
We love these tools but they were designed for testing, not for automation. They are too low-level to be used as they are by AI.
For example, the playwright MCP is very unreliable and inefficient to use. To mention a few issues, it does not correctly pierce through the different frames and does not handle the variety of edge cases that exist on the web. This means that it can't click on the button it needs to click on. Also, because it lacks control over the context design, it cannot optimize for contextual operations and your LLM trace gets polluted with incredible amount of useless tokens. This increases cost, task complexity for the LLM, and latency
On top of that, these tools rely on the accessibility tree, which is just not a viable approach for a huge number of websites
again (see other comment), you are not listening to users and asking questions, you are telling them they are wrong
You describe problems I don't have. I'm happy with Playwright and other scraping tools. Certainly not frustrated enough to pay to send my data to a 3rd party
have you tried any other AI browser automation tools? we would be curious to hear about your use cases because the use cases we have been working on with our customers involve scenarios where traditional playwright automations are not viable, e.g. they operate on net new websites and net new tasks for each execution
I'm unwilling to send my data to a 3rd party that is so new on the scene
Consider me a late adopter because I care about the security of my data. (and no, whatever you say about security will not change my mind, track record and broader industry penetration may)
Make it self-hostable, the conversation can change
I'm working on building a personal assistant concept. One test I've been running is asking different AI assistants to use a browser to check available appointment slots for my hairstylist. None of them has managed to do it successfully yet, but I'm going to keep trying.
There are pros and cons to running the browser on your own machine
For example, with remote browsers you get to give your swarm of agents unlimited and always-on browsers that they can use concurrently without being bottlenecked by your device resources
I think we tend to default to thinking in terms of one agent and one browser scenarios because we anthropomorphize them a lot, but really there is no ceiling to how parallel these workflows can become once you unlock autonomous behavior
I appreciate that, but for the audience here on HN, I’m fairly certain we understand the trade offs or potentially have more compute resources available to us than you might expect the general user to have.
Offer up the locally hosted option and it’ll be more widely adopted by those who actually want to use it as opposed to tinker.
I know this may not fit into your “product vision”, however.
Curious how this compares to https://sentienceapi.com/. My understanding is that Sentience uses deterministic "semantic snapshots" to try and give agents a more reliable browser interface.
Our approach is actually very cost-effective compared to alternatives. Our browser uses a token-efficient LLM-friendly representation of the webpage that keeps context size low, while also allowing small and efficient models to handle the low-level navigation. This means agents like Claude can work at a higher abstraction level rather than burning tokens on every click and scroll, which would be far more expensive
are your evals / comparisons publicly/3rd party reproducible?
If it's "trust me, I did a fair comparison", that's not going to fly today. There's too much lying in society, trusting people trying to sell you something to be telling the truth is not the default anymore, skepticism is
This is a good idea. Do you use something like browser-use or Fara-7b behind the scenes? Or maybe you don't want to give up your secrets (which is fine if that's the case).
How does your approach differ from BrowserOS, not in the product sense(their product is ane enterprise browser based off chrome). but in how they designed the interface between the browser and the models?
Interesting approach. Exposing high-level goals rather than UI actions definitely reduces token overhead, but reproducible comparisons with open-source setups would strengthen the claim. Also, remote browsers introduce a new attack surface—sandboxing helps, but I’d like to see clear isolation guarantees against malicious pages or rogue scripts.
Interesting idea as an open source tool I could hack locally, but no way in hell am I adding yet another bill and using a web browser of all things as SaaS. I'll make my own web-specialized subagent.
Frontend QA is the final frontier, good luck, you are over the target.
The amount of manual QA I am currently subjected to is simultaneously infuriating and hilarious. The foundation models are up to the task but we need new abstractions and layers to correctly fix it. This will all go the way of the dodo in 12 months but it'll be useful in the meantime.
agent-browser helped a lot over playwright but doesn't completely close the gap.
It's amazing how agents like Claude Code become very much more autonomous when they have the ability to verify their work. That's part of the reason why they work much better for unit-testable work.
I think this paradigm was very visible in yesterday's blog post from Anthropic (https://www.anthropic.com/engineering/building-c-compiler) when they mentioned that giving the agents the ability to verify against GCC was the key to unlock further progress
Giving a browser to these agents is a no brainer, especially if one works in QA or develops web-based services
Thanks for asking! There are a few core differences:
1. we expose a higher level interface which allows the agent to think about what to do as opposed to what to do
2. we developed a token-efficient representation of the webpages that combines both visual and textual elements, heavily optimized for what LLMs are good at.
3. because we control the agentic loop, it also means that we can do fancy things on contextual injections, compressions, asynchronous manipulations, etc which are impossible to achieve when exposing the navigation interface
4. we use a coding agent under the hood, meaning that it can express complex actions efficiently and effectively compared to the CLI interface that agent-browser exposes
5. because we control the agent, we can use small and efficient LLMs which make the system much faster, cheaper, and more reliable
Also, our service comes with batteries included: the agent can use browsers in our cloud with auto-captcha solvers, stealth mode, we can proxy your own ip, etc
Totally agree! The web for agents is evolving very fast and it's still unclear what it will look like
Our take is that, while that happens, agents today need to be able to access all the web resources that we can access as humans
Also, browsers are a really special piece of software because they provide access to almost every other kind of software. This makes them arguably the single most important tool for AI agents, and that’s why we believe that a browser might be all agents need to suddenly become ten times more useful than they already are
i believe agent native sites will stand up and the incumbents will be forced to adapt
such as agent native shopping platforms whereby a human will bring you something from walmart or what not could spring up and disrupt your instacart of the world
this of course is just one simple example, when it works better for the clawdbot or whatever comes next what are the users going to choose they'll say 'get me some apples from walmart using instacartforbots' because they know the agent success rate will be higher
Instacrats primary resource is not the website, it's the network of shoppers. You cannot replace that with Ai
I stopped using these services very quickly because the person (or machine) on the other side will never pick the same way I do. They don't care about quality, they care about time & money. My use of Ai is not going to change their incentives
Ahah, indeed that's true... That's why we've just released Smooth CLI (https://docs.smooth.sh/cli/overview) and the SKILL.md (smooth-sdk/skills/smooth-browser/SKILL.md) associated with it. That should contain everything your agent needs to know to use Smooth. We will definitely add a LLM-friendly reference to it in the landing page and the docs introduction.
Look this is cool idea, but subscribing to anything these days is a hard sell, we are all tired of subscription plans. You probably would be more succesful if you could find this to package in a way that is not subscription.
This looks really interesting!
I _would_ be curious to try it, but...
My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for a while, I didn't find a single mention of security anywhere (as far as I could tell!)
The only thing that I did find was zero data retention, which is mentioned as being 'on request' and only on the Enterprise plan.
I totally understand that you guys need to train and advance your model, but with suggested features like scraping behind login walls, it's a little hard to take seriously with neither of those two things anywhere on the site, so anything you could do to lift up those concerns would be amazing.
Again, you seem to have done some really cool stuff, so I'd love for it to be possible to use!
Update: The homepage says this in a feature box, which is... almost worst than saying nothing, because it doesn't mean anything? -> "Enterprise-grade security; End-to-end encryption, enterprise-grade standards, and zero-trust access controls keep your data protected in transit and at rest."
Thanks for bringing this point up!
We take security very seriously and one of the main advantages of using Smooth over running things on your personal device is that your agent gets a browser in a sandboxed machine with no credentials or permissions by default. This means that the agent will be able to see only what you allow it to see. We also have some degree of guard-railing which we will continue to mature over time. For example, you can control which URLs the agent is allowed to view and which are off limits.
Until we'll be able to run everything locally on device, there must be a level of trust in the organizations that control the technology stack, passing from the LLM all the way to the infrastructure providers. And this applies to every personal information you disclose at any touch point to any AI company.
I believe that this trust is something that we and every other company in the space will need to fundamentally continue to grow and mature with our community and our users.
Curious: what are people using as the best open source and locally hosted versions to have agents browse the web?
Playwright, same thing we use when doing non-ai automation
Fun fact, ai can use the same tools you do, we don't have to reinvent everything and slap a "built for ai" label on it
We love these tools but they were designed for testing, not for automation. They are too low-level to be used as they are by AI.
For example, the playwright MCP is very unreliable and inefficient to use. To mention a few issues, it does not correctly pierce through the different frames and does not handle the variety of edge cases that exist on the web. This means that it can't click on the button it needs to click on. Also, because it lacks control over the context design, it cannot optimize for contextual operations and your LLM trace gets polluted with incredible amount of useless tokens. This increases cost, task complexity for the LLM, and latency
On top of that, these tools rely on the accessibility tree, which is just not a viable approach for a huge number of websites
again (see other comment), you are not listening to users and asking questions, you are telling them they are wrong
You describe problems I don't have. I'm happy with Playwright and other scraping tools. Certainly not frustrated enough to pay to send my data to a 3rd party
have you tried any other AI browser automation tools? we would be curious to hear about your use cases because the use cases we have been working on with our customers involve scenarios where traditional playwright automations are not viable, e.g. they operate on net new websites and net new tasks for each execution
I'm unwilling to send my data to a 3rd party that is so new on the scene
Consider me a late adopter because I care about the security of my data. (and no, whatever you say about security will not change my mind, track record and broader industry penetration may)
Make it self-hostable, the conversation can change
Is this essentially a cloud-managed specialized subagent with an LLM-friendly API?
Seems like an interesting new category.
yes that's right! I think this might be the way AI agents adoption plays out more broadly
Agents that start using subagents rather than humans using the subagents directly
The new SaaS is subagent as a service?
indeed! there is no reason why tooling for AI agents shouldn't use AI when tooling for humans is shifting towards AI
I'm working on building a personal assistant concept. One test I've been running is asking different AI assistants to use a browser to check available appointment slots for my hairstylist. None of them has managed to do it successfully yet, but I'm going to keep trying.
https://n694923.alteg.io/company/656492/personal/menu?o=
I was actually very interested until I realized that this doesn't run on my computer…
I get the sandboxing, etc, but a Docker container would achieve the same goals.
There are pros and cons to running the browser on your own machine
For example, with remote browsers you get to give your swarm of agents unlimited and always-on browsers that they can use concurrently without being bottlenecked by your device resources
I think we tend to default to thinking in terms of one agent and one browser scenarios because we anthropomorphize them a lot, but really there is no ceiling to how parallel these workflows can become once you unlock autonomous behavior
I appreciate that, but for the audience here on HN, I’m fairly certain we understand the trade offs or potentially have more compute resources available to us than you might expect the general user to have.
Offer up the locally hosted option and it’ll be more widely adopted by those who actually want to use it as opposed to tinker.
I know this may not fit into your “product vision”, however.
I agree it would be really cool to run this locally, it's definitely something on our radars
Curious how this compares to https://sentienceapi.com/. My understanding is that Sentience uses deterministic "semantic snapshots" to try and give agents a more reliable browser interface.
Way too expensive, I'll wait for a free/open source browser optimized to be used by agents.
Our approach is actually very cost-effective compared to alternatives. Our browser uses a token-efficient LLM-friendly representation of the webpage that keeps context size low, while also allowing small and efficient models to handle the low-level navigation. This means agents like Claude can work at a higher abstraction level rather than burning tokens on every click and scroll, which would be far more expensive
If a potential user says it is too expensive, better to ask why than to tell them they are wrong. You likely have assumptions you have not validated
Definitely! Making Smooth as cost-effective as possible it's been a core goal for us, so we'd really love to hear your thoughts on this
We'll continue to make Smooth more affordable and accessible as this is a core principle of our work (https://www.smooth.sh/images/comparison.gif)
are your evals / comparisons publicly/3rd party reproducible?
If it's "trust me, I did a fair comparison", that's not going to fly today. There's too much lying in society, trusting people trying to sell you something to be telling the truth is not the default anymore, skepticism is
That's a great point, we'll publish everything on our docs as soon as possible
This is a good idea. Do you use something like browser-use or Fara-7b behind the scenes? Or maybe you don't want to give up your secrets (which is fine if that's the case).
Thanks for asking! We developed our browser agent that uses a mix of custom and frontier models for different parts of the system
How does your approach differ from BrowserOS, not in the product sense(their product is ane enterprise browser based off chrome). but in how they designed the interface between the browser and the models?
Interesting approach. Exposing high-level goals rather than UI actions definitely reduces token overhead, but reproducible comparisons with open-source setups would strengthen the claim. Also, remote browsers introduce a new attack surface—sandboxing helps, but I’d like to see clear isolation guarantees against malicious pages or rogue scripts.
I'm a bit curious. Why did you link the docs instead of the site in this post?
Our website does not dive as deep as the docs on the Smooth CLI yet
Interesting idea as an open source tool I could hack locally, but no way in hell am I adding yet another bill and using a web browser of all things as SaaS. I'll make my own web-specialized subagent.
Frontend QA is the final frontier, good luck, you are over the target.
The amount of manual QA I am currently subjected to is simultaneously infuriating and hilarious. The foundation models are up to the task but we need new abstractions and layers to correctly fix it. This will all go the way of the dodo in 12 months but it'll be useful in the meantime.
agent-browser helped a lot over playwright but doesn't completely close the gap.
It's amazing how agents like Claude Code become very much more autonomous when they have the ability to verify their work. That's part of the reason why they work much better for unit-testable work.
I think this paradigm was very visible in yesterday's blog post from Anthropic (https://www.anthropic.com/engineering/building-c-compiler) when they mentioned that giving the agents the ability to verify against GCC was the key to unlock further progress
Giving a browser to these agents is a no brainer, especially if one works in QA or develops web-based services
Congrats for shipping.
How does it compare to Agent Browser by Vercel?
Thanks for asking! There are a few core differences: 1. we expose a higher level interface which allows the agent to think about what to do as opposed to what to do 2. we developed a token-efficient representation of the webpages that combines both visual and textual elements, heavily optimized for what LLMs are good at. 3. because we control the agentic loop, it also means that we can do fancy things on contextual injections, compressions, asynchronous manipulations, etc which are impossible to achieve when exposing the navigation interface 4. we use a coding agent under the hood, meaning that it can express complex actions efficiently and effectively compared to the CLI interface that agent-browser exposes 5. because we control the agent, we can use small and efficient LLMs which make the system much faster, cheaper, and more reliable
Also, our service comes with batteries included: the agent can use browsers in our cloud with auto-captcha solvers, stealth mode, we can proxy your own ip, etc
typo: what to do as opposed to how to do it
i can see a new token efficient mirror web possibly emerging using content type headers on the request side
forms, PRG, semantic HTML and no js needed
Totally agree! The web for agents is evolving very fast and it's still unclear what it will look like
Our take is that, while that happens, agents today need to be able to access all the web resources that we can access as humans
Also, browsers are a really special piece of software because they provide access to almost every other kind of software. This makes them arguably the single most important tool for AI agents, and that’s why we believe that a browser might be all agents need to suddenly become ten times more useful than they already are
seems unlikely, you're asking the entire internet to update their software for dubious improvements
I believe this shift will actually happen organically over time
there will be demand for AI-first online services as people continue to delegate more and more tasks to agents and this will drive implementation
If it's machine-machine comms, just use an API
Seems dumb to create some other representation when we have an ubiquitous machine readable format that Ai understands quite well
i believe agent native sites will stand up and the incumbents will be forced to adapt
such as agent native shopping platforms whereby a human will bring you something from walmart or what not could spring up and disrupt your instacart of the world
this of course is just one simple example, when it works better for the clawdbot or whatever comes next what are the users going to choose they'll say 'get me some apples from walmart using instacartforbots' because they know the agent success rate will be higher
> disrupt your instacart
Instacrats primary resource is not the website, it's the network of shoppers. You cannot replace that with Ai
I stopped using these services very quickly because the person (or machine) on the other side will never pick the same way I do. They don't care about quality, they care about time & money. My use of Ai is not going to change their incentives
Ironically, the landing page and docs pages of Smooth aren't all that token-efficient!
Ahah, indeed that's true... That's why we've just released Smooth CLI (https://docs.smooth.sh/cli/overview) and the SKILL.md (smooth-sdk/skills/smooth-browser/SKILL.md) associated with it. That should contain everything your agent needs to know to use Smooth. We will definitely add a LLM-friendly reference to it in the landing page and the docs introduction.
Look this is cool idea, but subscribing to anything these days is a hard sell, we are all tired of subscription plans. You probably would be more succesful if you could find this to package in a way that is not subscription.
would love to hear what pricing model would work best for you
our current model is a subscription plan that determines the number of browsers available + credits top-ups for increased usage