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 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
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.
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.
the abstraction level argument is spot on. i've been working on browser automation for AI agents and the biggest lesson has been that exposing Playwright-level primitives to a foundation model is fundamentally the wrong interface. the model burns most of its context reasoning about DOM traversal and coordinate-based clicking instead of the actual task. the natural language intent layer is the right call, it's basically treating the browser interaction as a tool-use problem where the tool itself is agentic.
curious about failure recovery though: when the specialised browsing model misinterprets an intent (e.g. clicks the wrong "Submit" on a page with multiple forms), does the outer agent get enough signal to retry or reframe the instruction? that's been the hardest part in my experience, the error surface between "the browser did the wrong thing" and "I specified the wrong thing" is really blurry.
I agree that there is communication overhead between the agents, although so far it looks like they can communicate very effectively and efficiently. We’re also working on efficient ways to transfer more contextual information
Curious to see how you compare against competitors, any benchmarks to share?
We launched a competitor in the space rtrvr.ai, that when benchmarked is SOTA and beats even OpenAI Operator.
Cool work on the proxying but LinkedIn has really advanced detections for even device/hardware fingerprinting, how advanced are your stealth measures? Because this might be risking account bans.
People in this space even setup consumer hardware in datacenters to get around this actually.
we benchmarked on webvoyager and have a few more benchmarks coming up (see https://docs.smooth.sh/performance), we’ll be publishing the full results shortly
we run headful browsers with a fingerprinting that is as stealth as possible and on top of that we can use your ip
anecdotally, making all requests originate from your own residential address has been a major success compared to other cloud-only solutions
it will be interesting to see how this will play out, having to “hide the agent” feels like a temporary work around until society accepts that agents actually do exist
Few days ago I built something like this for a personal project because it’s just the obvious thing to do - abstract away the gory details of using a browser. I found it was surprisingly easy to build and I soon had a browser agent that worked as you describe Smooth. Just surprised that the other browser agent frameworks like Browser Use and claude —chrome haven’t caught up to this yet, it’s so obvious and easy to do.
I think our main differentiator is that we have been building browser agents for over a year and our technology is today 5x faster and 7x cheaper than browser-use, while also being significantly more reliable
> Smooth offers a “self” proxy that creates a secure tunnel and routes all browser traffic through your machine’s IP address
Can you confirm that you only route the traffic of the one user who owns the machine though the proxy? Or do you use it as residential proxy for other users as well?
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.
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
Cool project guys! Just gave it a spin. One thing I would have wished, was if the browsers would run locally. Since the smooth browser is running in prod, it makes it harder for Claude to test dev apps
It still may not be quite ideal. For example, right now I was building a clone of Counter Strike. There's such large files that tunneling would be cumbersome.
the Claude --chrome command has a few limitations:
1. it exposes low-level tools which make your agent interact directly with the browser which is extremely slow, VERY expensive, and less effective as the agent ends up dealing with UI mechanics instead of thinking about the higher-level goal/intents
2. it makes Claude operate the browser via screenshots and coordinates-based interaction, which does not work for tasks like data extraction where it needs to be able to attend to the whole page - the agent needs to repeatedly scroll and read one little screenshot at the time and it often misses critical context outside of the viewport. It also makes the task more difficult as the model has to figure out both what to do and how to do it, which means that you need to use larger models to make this paradigm actually work
3. because it uses your local browser, it also means that it has full access to your authenticated accounts by default which might not be ideal in a world where prompt-injections are only getting started
if you actively use the --chrome command we'd love to hear your experience!
I am sure they measured the difference but i am wondering why reading screenshots + coordinates is more efficient than selecting aria labels? https://github.com/Mic92/mics-skills/blob/main/skills/browse.... the JavaScript snippets should at least more reusable if you want semi-automate websites with memory files
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?
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).
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.
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.
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.
> agent-browser click "#submit"
> agent-browser fill "#email" "test@example.com"
> agent-browser find role button click --name "Submit"
I appreciate that there’s innovation in the space, we will get closer to the interface that’s most appropriate for models to tool-call. I’m going to check your link out, sounds interesting.
it's interesting to see how things will play out, but I really believe that doing Claude Code (maybe with Opus 4.6) + click tool + move_mouse tool + snapshot page tool + another 114 more tools is definitely not the best approach
the main issue with this interface is that the commands are too low-level and that there is no way of controlling the context over time
once a snapshot is added to the context those tokens will take up very precious context window space, leading to context rot, higher cost, and higher latency
that's why agents need to use very large models for these kind of systems to work and, unfortunately, even then they're very slow, expensive, and less reliable than using a purpose-made system
I wonder if a standardized interface will organically emerge over time. At the moment SKILL.md + CLI seem to be the most broadly adopted interface - even more than MCP maybe
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
frontend QA is exactly where i've seen the biggest ROI with browser agents. the gap with Playwright MCP specifically is that it assumes the agent can reason about CSS selectors and DOM state, which breaks constantly on anything with dynamic rendering, client-side routing, or shadow DOM.
the right abstraction for QA is probably closer to what a manual tester actually does, describe expected behavior, let a specialized system figure out the mechanical verification steps.
but the harder unsolved problem is evaluation: how do you reliably distinguish "the agent verified the behavior" from "the agent navigated to the right page and hallucinated a success report"? visual diffing against golden screenshots helps for regression but doesn't cover semantic correctness of dynamic content.
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
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."
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
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.
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.
Glad I saw this comment.
The product sounds interesting but I am not gonna run this is in the cloud for my use cases.
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
Yeah, give us the OSS.. and sell the SLA's to enterprise
the abstraction level argument is spot on. i've been working on browser automation for AI agents and the biggest lesson has been that exposing Playwright-level primitives to a foundation model is fundamentally the wrong interface. the model burns most of its context reasoning about DOM traversal and coordinate-based clicking instead of the actual task. the natural language intent layer is the right call, it's basically treating the browser interaction as a tool-use problem where the tool itself is agentic.
curious about failure recovery though: when the specialised browsing model misinterprets an intent (e.g. clicks the wrong "Submit" on a page with multiple forms), does the outer agent get enough signal to retry or reframe the instruction? that's been the hardest part in my experience, the error surface between "the browser did the wrong thing" and "I specified the wrong thing" is really blurry.
totally agree on the interface.
I agree that there is communication overhead between the agents, although so far it looks like they can communicate very effectively and efficiently. We’re also working on efficient ways to transfer more contextual information
Hey really unique take!
Curious to see how you compare against competitors, any benchmarks to share?
We launched a competitor in the space rtrvr.ai, that when benchmarked is SOTA and beats even OpenAI Operator.
Cool work on the proxying but LinkedIn has really advanced detections for even device/hardware fingerprinting, how advanced are your stealth measures? Because this might be risking account bans.
People in this space even setup consumer hardware in datacenters to get around this actually.
we benchmarked on webvoyager and have a few more benchmarks coming up (see https://docs.smooth.sh/performance), we’ll be publishing the full results shortly
we run headful browsers with a fingerprinting that is as stealth as possible and on top of that we can use your ip
anecdotally, making all requests originate from your own residential address has been a major success compared to other cloud-only solutions
it will be interesting to see how this will play out, having to “hide the agent” feels like a temporary work around until society accepts that agents actually do exist
Few days ago I built something like this for a personal project because it’s just the obvious thing to do - abstract away the gory details of using a browser. I found it was surprisingly easy to build and I soon had a browser agent that worked as you describe Smooth. Just surprised that the other browser agent frameworks like Browser Use and claude —chrome haven’t caught up to this yet, it’s so obvious and easy to do.
Hello, do you mind open sourcing it ? my email hn@medreda.blog
I think our main differentiator is that we have been building browser agents for over a year and our technology is today 5x faster and 7x cheaper than browser-use, while also being significantly more reliable
> Smooth offers a “self” proxy that creates a secure tunnel and routes all browser traffic through your machine’s IP address
Can you confirm that you only route the traffic of the one user who owns the machine though the proxy? Or do you use it as residential proxy for other users as well?
The docs don't say anything about it.
definitely only your own traffic! will add to the docs for ease of mind
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 built a browser agent that can almost certainly handle that task. Will test and let you know by posting here later.
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
Cool project guys! Just gave it a spin. One thing I would have wished, was if the browsers would run locally. Since the smooth browser is running in prod, it makes it harder for Claude to test dev apps
thanks! it can actually test apps running on your localhost with our tunneling feature (https://docs.smooth.sh/features/use-my-ip)
you should be able to tell it to go to your localhost address and it should be able to navigate to your local app from the remote browser
let us know if you have any questions!
But does the tunnel expose the low level APIs required for Claude Code to write end to end tests and check browser console errors, etc ?
It still may not be quite ideal. For example, right now I was building a clone of Counter Strike. There's such large files that tunneling would be cumbersome.
ah fair point! the tunnel is peer-to-peer so it doesn't add too much overhead, but you can't really beat localhost on latency
I'd be curious to try and see if practically the difference is so little that it doesn't matter
What is wrong with "claude --chrome"?
the Claude --chrome command has a few limitations:
1. it exposes low-level tools which make your agent interact directly with the browser which is extremely slow, VERY expensive, and less effective as the agent ends up dealing with UI mechanics instead of thinking about the higher-level goal/intents
2. it makes Claude operate the browser via screenshots and coordinates-based interaction, which does not work for tasks like data extraction where it needs to be able to attend to the whole page - the agent needs to repeatedly scroll and read one little screenshot at the time and it often misses critical context outside of the viewport. It also makes the task more difficult as the model has to figure out both what to do and how to do it, which means that you need to use larger models to make this paradigm actually work
3. because it uses your local browser, it also means that it has full access to your authenticated accounts by default which might not be ideal in a world where prompt-injections are only getting started
if you actively use the --chrome command we'd love to hear your experience!
I am sure they measured the difference but i am wondering why reading screenshots + coordinates is more efficient than selecting aria labels? https://github.com/Mic92/mics-skills/blob/main/skills/browse.... the JavaScript snippets should at least more reusable if you want semi-automate websites with memory files
claude --chrome works, but as the OP mentions: they can do it 20x faster, by passing in higher-level commands.
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?
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
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
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.
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.
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
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.
Vercel also released a similar tool with a unique interface/dsl - https://github.com/vercel-labs/agent-browser
> agent-browser click "#submit" > agent-browser fill "#email" "test@example.com" > agent-browser find role button click --name "Submit"
I appreciate that there’s innovation in the space, we will get closer to the interface that’s most appropriate for models to tool-call. I’m going to check your link out, sounds interesting.
it's interesting to see how things will play out, but I really believe that doing Claude Code (maybe with Opus 4.6) + click tool + move_mouse tool + snapshot page tool + another 114 more tools is definitely not the best approach
the main issue with this interface is that the commands are too low-level and that there is no way of controlling the context over time
once a snapshot is added to the context those tokens will take up very precious context window space, leading to context rot, higher cost, and higher latency
that's why agents need to use very large models for these kind of systems to work and, unfortunately, even then they're very slow, expensive, and less reliable than using a purpose-made system
I wonder if a standardized interface will organically emerge over time. At the moment SKILL.md + CLI seem to be the most broadly adopted interface - even more than MCP maybe
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
frontend QA is exactly where i've seen the biggest ROI with browser agents. the gap with Playwright MCP specifically is that it assumes the agent can reason about CSS selectors and DOM state, which breaks constantly on anything with dynamic rendering, client-side routing, or shadow DOM.
the right abstraction for QA is probably closer to what a manual tester actually does, describe expected behavior, let a specialized system figure out the mechanical verification steps.
but the harder unsolved problem is evaluation: how do you reliably distinguish "the agent verified the behavior" from "the agent navigated to the right page and hallucinated a success report"? visual diffing against golden screenshots helps for regression but doesn't cover semantic correctness of dynamic content.
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
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