Three ways to let AI drive a web page
A browser extension that acts for the user. WebMCP tools a page declares. An agent embedded in the application through an SDK. They solve different problems, they cost different things, and the honest answer to which one is best is that it depends on whose page it is.
The short answer
- Browser extension. Best when the agent has to work on sites you do not own, when the user should carry the model cost, and when seeing the screen matters more than speed.
- WebMCP. Best when you want outside agents to act on your pages reliably, through a standard, and you can live with browser support that is still spreading.
- In app agent. Best when you want speed, actions beyond what the screen shows, control of the interface, and the conversation data in your own hands.
They are not exclusive. The same underlying functions can back all three, and most teams will end up using more than one.
Same page, same task, three ways to drive it
A customer wants a refund on order 8412. Same task, same page, three surfaces. Each one can do something the other two cannot.
The agent arrives with the user
An extension or an agentic browser reads the page your users see and acts in their session. Nothing to build on your side, the model subscription is theirs, and the agent brings the context of everything else they have open.
- 1The user brings their own agentAn extension or an agentic browser. You ship nothing, and the model bill is theirs.
- 2It sees the page the way the user doesScreenshots and DOM, so a greyed out button or an error banner counts, even if no API exposes it.
- 3It picks a target and clicksIn the user session, with their rights, and with what it learned in their other tabs.
- 4A modal appears, it reads againEvery change of screen costs another read. This loop is what makes the approach slow.
- 5The task completes, outside your wallsIt worked. You never saw the conversation, the wording, or what the user was really after.
What each approach is good at, and where it stops
Every one of the three wins on something the other two cannot offer. Here is the case for each, and the price that comes with it.
Browser extension and agentic browser
A browser extension or an agentic browser runs beside the page, reads what is rendered, and acts inside the user session. Chrome, Edge, Comet and Atlas all ship a version of this.
- Works on any site, including every site you do not own
- Nothing to build, nothing to change on the page
- The user brings the model and pays for it
- Carries the user context, their preferences and the other tabs of the task they are on
- Screenshots let the model see what the user sees, including states no API ever exposed
- Slow, because every step needs a fresh read of the screen
- Only reaches the users who installed an extension or switched browser
- The conversation never reaches you, so you lose both the insight and the say in what is said about your product
- Sensitive to interface changes, since the target is a rendered element
WebMCP tools declared by the page
WebMCP is a proposed web standard that lets a page declare typed tools an agent can call, instead of making it click. It is a W3C Web Machine Learning Community Group draft dated 28 July 2026, with a Chrome origin trial from Chrome 149.
- Much faster than driving pixels, one typed call per action
- A standard, so a single declaration serves every agent that speaks it, the browser model included
- You choose the actions, so an outside agent cannot go further than you allowed
- Reaches visitors who have no account and no session with you
- Early, a draft spec and an origin trial rather than a shipped browser feature
- In August 2026 it covers the browsers that opted in, not your audience
- The conversation still belongs to the browser or agent vendor, not to you
- Bounded by the tools you declared and by what the page itself can do
An agent inside your JavaScript app
An SDK embeds the agent in your own application, where it runs your code behind your authentication. It never looks at the screen: every message carries a structured snapshot of the session, the current route, the page state you registered and the last actions taken, and the agent replies with a call to a function you described. The AGO SDK is one of these, and so is anything you build yourself on a model provider.
- Fast, because it reads a structured snapshot rather than screenshotting and re reading the page
- Actions are not limited to what is on screen: a page absent from the menu, an endpoint with no interface, a batch with no button
- You control the interface, so the agent renders the right view, or hands a form or a confirmation to your own components, instead of clicking through one built for humans
- Any call can be held until the user approves it, function by function
- You control the business logic, the rules, the permissions and the audit trail
- Every conversation is yours, with the product insight that comes with it
- You build it and you maintain it
- Bounded by the tools you declared and by what the app itself can do
- The model cost is on you, not on the user
- Nothing happens on the sites you do not own
The nine questions that actually separate them
Speed, cost, reach and control, on the same row, so the trade you are making is visible before you commit to one.
| Browser extension | WebMCP | In app agent | |
|---|---|---|---|
| Changes needed on your site | None | Tool declarations in the page | An SDK and the functions you expose |
| What the model perceives | Screenshots and the DOM | The tools the page declares | Your data, state and functions |
| Speed of one action | 🐢 Slow, read and act on every step | ⚡ Fast, one typed call | ⚡ Fast, a direct call to your code |
| Who pays for the model | The user | The user, through their agent | You, per conversation |
| Who sees the conversation | The extension vendor | The browser or agent vendor | You |
| Actions available | Whatever is on the screen | Whatever you declared | Anything your code can do, on screen or not |
| Control over what is displayed | None, it clicks your interface | None, the agent renders the answer | Full, you render the view |
| Works on sites you do not own | Yes | No | No |
| Reach in August 2026 | Users who installed one | Chrome origin trial from Chrome 149 | Every user of your product, any browser |
Start from whose page it is
The three approaches are not competing for the same job. The owner of the page, and the user you are trying to help, decide the answer faster than any feature list.
The page belongs to someone else
Research, form filling, moving data between two tools that will never expose an API to you. Nobody is going to ship WebMCP tools or an SDK for your convenience, and an extension does not need them to.
You want outside agents to use your pages
Public pages where somebody else's assistant does the shopping, the booking or the comparison. Declaring tools is how you make that reliable, and how you stay in control of what those agents can trigger.
You want to help your own signed in users
People stuck inside your product, on your data, with your business rules. This is where speed, actions beyond the screen, and knowing what users actually ask are worth the build.
Where AGO fits, and where it does not
We build the third one, so here is the bias stated plainly rather than hidden in the comparison above.
The SDK is the surface, not the product. Putting an agent in your page is the easy half. The moment it works you have thousands of conversations a week to keep accurate, safe and improving, and that is the half teams underestimate. Owning the conversation, the row in the table above, is only an advantage if you have somewhere to put it and something to do with it.
AGO is the system around that conversation:
- Agents connected to your documentation, your databases and your APIs, so the answer comes from your own truth
- An agent lab to replay real conversations and test a change before a customer sees it
- Access control over who may talk to which agent, and which systems each agent may touch
- Automatic quality scoring on every conversation rather than a sample, with the knowledge gaps it uncovers
- A handoff into Zendesk, Intercom or your own tool when a human is genuinely needed, context attached
- Forward deployed engineers who build and tune the agents alongside your team
That is the reason we build on the third surface: it is the only one where the conversation reaches a place you can operate. The agent in the page is what your users touch, the rest is what keeps it worth touching a year later.
It is the wrong tool for the rest. If your agent has to book a flight on a site you do not own, an extension or an agentic browser is the answer, and we will say so. If you want outside assistants to act on your public pages, declare WebMCP tools. The good news is that these are the same functions: what you expose to your own agent is what you register as a tool the day the browsers are ready, and the hard part, deciding which actions an agent may perform at all, is done once.
Try an in app agent on your own app
The whole SDK documentation is published as a single file written for coding agents. Paste this prompt into Claude Code, Codex or Cursor and let it wire the agent into your codebase. You get a working chat panel first, then you decide which of your functions it may call.
Read https://raw.githubusercontent.com/useago/ago-sdk/refs/heads/main/llms-full.txt
and integrate the AGO chat SDK into this app.Questions about AI driving a web page
Extensions, WebMCP and in app agents, and what each of them can really do in August 2026.
What are the ways an AI agent can control a web page?+
Three, as of August 2026. A browser extension or agentic browser reads the rendered page and acts in the user session. WebMCP lets the page declare typed tools that a supporting browser calls directly. An in app agent, embedded with an SDK, lives inside the product, where it uses your routes, your state and the functions you expose. They coexist, and a single page can be reachable by all three.
Which approach is the fastest?+
WebMCP and an in app agent are both fast, because a typed function call replaces the screenshot, reason, click and re read loop. Extensions and agentic browsers are the slowest of the three for the same reason, since every change of screen costs another read.
Is WebMCP available in browsers today?+
Partly. WebMCP is a draft published by the W3C Web Machine Learning Community Group, dated 28 July 2026, and Chrome opened an origin trial from Chrome 149 with a local testing flag at chrome://flags/#enable-webmcp-testing. Treat it as a bet on the next few years rather than a way to reach every user this quarter.
When is a browser extension the better choice?+
When the agent has to work on a site you do not control, when you want the user to bring and pay for their own model, or when the task depends on visual state that no API exposes, such as a greyed out button or a banner. It is also the only approach that carries the user's context across several sites in one task.
Which approach lets me keep the conversation data?+
Only the in app agent. With an extension or with WebMCP, the exchange happens in a product you do not own, so you see the resulting action but never the question, the wording or the hesitation behind it. If understanding what users ask is part of the point, that gap is the deciding factor.
Why do extension based agents break on real applications?+
They rebuild their understanding of the page on every turn. A modal, a lazy loaded list or a renamed button changes what they read, so the agent has to look again and can pick the wrong element. Nothing is wrong with the model, the target simply moved.
Can I ship WebMCP tools and an in app agent at the same time?+
Yes, and the two share most of the work. The in app agent serves the users you have today in any browser. WebMCP tools serve the agentic browsers that arrive later. Both can be backed by the same functions, so the expensive part, deciding which actions an agent may perform, is done once. See how the AGO SDK exposes functions
How do I control what an agent is allowed to do?+
You expose actions one at a time. With WebMCP you register a tool per action, with an SDK you describe a function and its schema, and in both cases the agent can only call what you declared. An SDK goes one step further: a call marked as requiring approval pauses until the user accepts or rejects it. An extension is the exception, since it can reach anything the user can reach on screen and you are not the one deciding.
Ready to reimagine your customer experience?
Deploy AI agents that truly understand your customers and your business. Book a demo with our team to see Ago in action.