# The three homes of the Agentic Web
> On-site, in-browser, off-browser - where an agent lives decides who holds control, how far a task can travel, and whether a human ever sees your website.
*Published 2026-07-07 Β· 6 min read*
---
When I talk to people about agents interacting with websites, the conversation usually starts with *agent perception*:
> How does an agent "see" your website?
Screenshots vs. DOM vs. accessibility tree - and then the conversation gravitates towards actuation, and addressing challenges related to it, for example by using **WebMCP** π.
It's a very important topic β - in Around the web you can find links explaining how agents can perceive your website, and how WebMCP can help.
Today, though, inspired by [AndrΓ© Bandarra's "The Agentic Web"](https://bandarra.me/posts/the-agentic-web) post I want to ask a different question:
> Where does the agent actually *live*?
I already hinted at the answer in the previous post: some users *"might use agents embedded on the websites, others will delegate that task to co-browsing agents, or OpenClaw-style agents"*.
I like to think about it in terms of three different homes that agents can inhabit: **on-site**, **in-browser**, and **off-browser**.
## The agent lives on your website
You, the site owner, ship the agent: an assistant embedded right into the page. A user can ask your agent *"Find me a winter jacket size 3XL"* directly on the website.
This is the home where website owners have the **most control** over the agent. You pick the model, the tools, the guardrails, the tone.
There is no *perception* problem at all - your agent doesn't need to understand your page on-the-fly or hunt for relevant tools. It ships with all the needed domain knowledge and workflows, which more generic "external" agents may not know.
There is **no additional distribution channel**: Your users don't need to install anything extra (no extension, no special browser) - the agent is right there on the page.
The trade-off is **reach**: an on-site agent is coupled with *your* site. I don't expect it to compare your prices with a competitor or carry the user's journey across the web.
And all that control comes at a price: you build and run the whole thing yourself - the model, the tools, the guardrails - and you carry the complexity and the bills π
.
There is a nuance here - an agent might be embedded on your site, but still be owned by a third party. Convenient, but you hand back some of that control.
I think we've all seen a similar on-site assistant before - the thingy below is a **clickable demo** π, go ahead and try it π
The ones I've observed in the wild differ in their capabilities. I've seen ones that are completely disconnected from the website state, ones that are only able to answer simple questions (like the demo above) and ones that can actively change what the user sees on the screen, be it a separate surface or triggering navigation/action.
I recommend taking a look at the [WebMCP Sports demo](https://googlechromelabs.github.io/webmcp-tools/demos/sport-shop-angular/#/) from the [webmcp-tools repository](https://github.com/GoogleChromeLabs/webmcp-tools/tree/main/demos/sport-shop-angular#webmcp-sports), which showcases an on-site agent calling WebMCP tools:
I'll be researching on-site agents further in future blog posts π. Now let's take a look at another home π .
## The agent lives in the browser
Here the **user brings their own agent** - a browser extension, or an agent built right into the browser. This is **co-browsing**: the human and the agent share the same tab, look at the same page, and either of them can act.
**Let me say that again:** the agent works **inside the user's active session**. It doesn't need to copy passwords or payment methods anywhere - they stay right where they were. The agent simply acts in a browser where the user is already logged in: that cart from last week is just *there*, no "authorize this app" step required. Think of the agent as **an extra pair of hands, not a copy of the keys** π.
**The flip side π:** those hands are logged in. A malicious page with sneaky hidden instructions (prompt injection) is a real hazard, and browser vendors are hardening their agents against it. But this home also ships with the strongest guardrail built in: **the human is looking at the exact same screen**. Ambiguity? The agent asks. Risky step? One-click confirmation (you'll meet one in the demo below). Off the rails? The user takes the wheel back.
There's a nuance here: sharing a screen is the friendly version of co-browsing, the one where that guardrail actually holds. But an agent can also open a tab in the background and work while you're not watching - and the moment it does, the "human one glance away" safety net is gone, and this home starts drifting towards the next one π°οΈ.
For the website it's a decent deal too: pages actually rendered, brand seen, and a real human present at the other end of the journey.
**Another clickable demo π** - you're the user this time: hand your browser agent a task and watch it work inside your session, right on the page you're both looking at:
## The agent lives outside the browser
The third home: the agent runs somewhere else entirely - a cloud service, on someone's server/local machine etc (catch-all for any other agent π
). The user might not even see the website their agent is interacting with (it depends on the agent of course).
With that in mind, off-browser agents reach your business in two ways:
1οΈβ£ **They drive their own browser or connect to user browser** to visit your website - steered by Puppeteer, Playwright or MCP integrations like Chrome DevTools MCP
2οΈβ£ **They skip the browser entirely** and talk to your APIs/MCPs directly
You might wonder how that first path differs from co-browsing - the key is *where the agent lives*: a co-browsing agent rides inside the browser next to a present human, while here the agent sits somewhere else and drives the browser remotely, often with nobody watching π.
And yes - an off-browser agent *can* hook into the user's active browser. But I've yet to see an interaction pattern that recreates the co-browsing feel: a human genuinely present, watching, in the loop π€·ββοΈ.
**One more clickable demo π** - delegate a task to your cloud agent and keep an eye on the right panel: for this browser-skipping agent, the server log is *everything* your website ever sees of this user:
This home is the mirror image of the on-site agent: **maximum reach, minimum control**. The agent can compare you with every competitor, carry a task across the whole web, and work while the user sleeps. And you don't get to pick the model, the tools, or the guardrails.
Remember the *"extra pair of hands, not a copy of the keys"* idea from the in-browser home? Out here there are no spare hands to borrow - there is no shared tab with the user already logged in. To act on the user's behalf, the agent needs actual keys, cut for the occasion π.
**The website has a question of its own:** who is knocking - are we sure it's the user's legitimate agent? I suspect deciding which agents to welcome (and which to show the door) will soon become a deliberate business decision.
## So, what does it change? π€
As the agent moves further away from your site, **website owner control over the agent drops and the agent's reach grows**.
**On-site**: your rules, but only your walls. **In-browser**: shared screen, shared session. **Off-browser**: maximum reach, and your website **might never be seen** by a human user π€·ββοΈ.
Interestingly, a lot of the standards work happening right now looks like an attempt to bend that curve - WebMCP, for example, lets you hand *your* tools to an agent you don't own.
But what if you want both control and reach? π€
## What if the agents start talking to each other? π€
The three homes don't have to work in isolation.
Imagine a website ships an on-site agent that *really* knows the place - every workflow, every edge case, the domain knowledge, first-party access to the APIs. Now a co-browsing agent arrives with the user. Why should it reverse-engineer your checkout flow, when there's a resident expert sitting right there?
The natural move might be a **handoff**: the visiting agent brings the user's intent and context, the on-site agent contributes the domain expertise and execution. The visiting agent arrives as the user's extra pair of hands, and the on-site agent doesn't need any keys - it lives here π .
In plain English, it might go something like this (the real exchange wouldn't be this chatty):
> **Visiting Agent:** *"Hey! My user wants to book a flight to Warsaw on July 10th. Their profile has frequent flyer number `XYZ-1234`."*
>
> **On-site Agent:** *"Welcome! I see July 10th has direct flights. Seat spacing is tight on ABC-123, but since they have frequent flyer status, I can auto-apply a complimentary exit-row upgrade. Should I add it to the cart?"*
>
> **Visiting Agent:** *"Yes, please. User approves the upgrade."*
Which immediately raises a very practical question: **how do you expose your on-site agent to visiting agents?** Two candidate techniques, and they feel genuinely different:
1οΈβ£ **Agent as a tool (WebMCP).** Your page declares something like `askSiteAssistant(...)` right next to `addToCart` and `filterResults`. If you already expose WebMCP tools, this is just one more. The catch: each tool call is a single round-trip - request in, response out. The visiting agent can chain calls to fake a back-and-forth, but there's no built-in task lifecycle to lean on. I'm curious how far that stretches in practice π€.
2οΈβ£ **A2A communication.** A proper agent-to-agent protocol: the on-site agent publishes what it can do, and the conversation has a real task lifecycle - clarifying questions, streaming progress, long-running work. This matches what a handoff actually *is*.
I am genuinely interested how those two will compare in action, demo soon? π
One more thought before we wrap up - **who does the on-site agent work for?** The visiting agent is the user's advocate; the on-site agent is, ultimately, the site's employee. When the two negotiate - is that really a handoff, or a sales conversation? I suspect trust and incentives, not protocols, will be the hard part here. Might be a full post on its own π€.
Exciting! π
More soon. β¨