Show HN: Rover – Embeddable web agent (rtrvr.ai)

32 points by arjunchint ↗ HN
Rover is the world's first Embeddable Web Agent, a chat widget that lives on your website and takes real actions for your users. Clicks buttons. Fills forms. Runs checkout. Guides onboarding. All inside your UI.

One script tag. No APIs to expose. No code to maintain.

We built Rover because we think websites need their own conversational agentic interfaces as users don't want to figure out how your site works. If they don't have one then they are going to be disintermediated by Chrome's or Comet's agent.

We are the only Web Agent with a DOM-only architecture, thus we can setup an embeddable script as a harness to take actions on your site. Our DOM-native approach hits 81.39% on WebBench.

Beta with embed script is live at rtrvr.ai/rover.

Built by two ex-Google engineers. Happy to answer architecture questions.

11 comments

[ 2.8 ms ] story [ 28.9 ms ] thread
We have seen people hire consultants to build RAG pipelines, maintain them only to be QA Agent when the world is shifting losing traffic to the likes of ChatGPT and Google comes up with a protocol that makes you do more work with WebMCP essentially maintain a lot of APIs for your UI and DBs. Rover is the answer to these painpoints. No RAG pipelines, just one script tag your users engage, retain, get work done on your website without ever leaving it and fully conversational.
Essentially, are you saying 'dont give data to Google, but give to us'? I can't see how the merchant websites own anything given that the script points to your website and everything else is a blackbox. Just wondering...
Code written by LLMs, website copy written by LLMs trashing competitors, Hacker News post written by LLMs, as if it were for LinkedIn. AI images everywhere. I dunno man, this is really sloppy.
(comment deleted)
This isn't a ______. This isn't a ______. This is ______.

The message is clear: ______ isn't a nice-to-have. It's a ______.

But here's what nobody's talking about: ...

I can't force myself to spend more thought reading than was spent writing.

"Simple, Transparent Pricing" => vibe coded product

  "Sync your logged-in browser sessions from the Extension to Cloud browsers. Access authenticated sites at scale."
Genuine question, have you seen 'cookie syncing' before (google, perhaps)? If so, what was it used for? I could understand if it they were cookies for your service only. It sounds like a security nightmare waiting to happen.
So with the rise of cloud browser agents, identity management is a critical problem.

There are a lot of users on our rtrvr.ai/cloud platform wanting to automate sites where they have to login to and right now are resorting to including usernames/passwords in prompts (presumably these are non critical sites that they dont really care about). We are offering a more secure option of just syncing cookies from our Chrome Extension to our cloud browsers so the agents will always be logged in without any credential exposure.

You choose the specific domains for the cookies you want synced so its not like all your cookies are syncing.

Originally called Retriever, based on the domain. Trademark issues?

So it's a bunch of tools that Gemini can call, but the tools involve low-level interactions with the page structure in the end-user's browser.

What is the moat? What is an "agent" when you take away the powerful LLM?

    Rover lives inside your website
Rover does not just live "inside" my website, because you are using Gemini 3 Flash to do all the heavy lifting.

Who is the audience here? It sounds like you're addressing people who don't know how the technology works, but the cutesy concept is borderline misleading.

Also, can you back up this claim with a human-written response? (emphasis mine)

    When rtrvr.ai interacts with a webpage, there is zero automation fingerprint:

    No navigator.webdriver flag
    No CDP-specific JavaScript objects
    *No detectable automation patterns in network requests*
    *Identical timing characteristics to human interaction*
Thanks for taking a look!

So our core technical moat is building up an agentic harness that can represent and take actions on any webpage without any screenshots. With this approach we even beat custom trained models like OpenAI Operator and Anthropic CUA: https://www.rtrvr.ai/blog/web-bench-results

Everyone else in the space just takes a screenshot and asks a model what coordinates to click, our core thesis is that LLMs understand semantic representations fundamentally better than vision. But with this DOM approach there is a long tail of HTML/DOM edge cases to cover that we have built out for with the 20k+ users bringing these edge cases.

Soon you will be able to record demonstration tasks via our partner Chrome Extension as well as setup knowledge bases scraped by our Cloud browsers to provide additional context to the agent. So there is a platform moat as well.

The audience is website owners who want to increase visitor engagement and conversion via a conversational interface for users.

This is more for our cloud browser platform where we launch cloud browsers for vibe scraping controlled via a custom extension instead of CDP. You can try it out at rtrvr.ai/cloud, where we can get back some strong antibot detection sites like google.com

The DOM-native architecture is a clever way to bypass API integration, but it introduces significant operational risk regarding state management. Since this agent executes checkouts and form fills, a hallucination here isn't just wrong text—it’s potentially an erroneous charge or data loss. How do you handle liability or remediation if the agent misinterprets a UI element and executes an unwanted transaction? Does the script enforce a "human-in-the-loop" confirmation step for high-stakes actions like payment submission, or is the goal full autonomy regardless of confidence levels?