AI ON THE PAGE

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.

See the demo Compare side by side

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.

THE THREE SURFACES

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.

What happens

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.

At a glance

Speed: Slow, a read and act loop per step
The model perceives: The page as the user sees it
Who pays the model: The user, with their subscription
Who sees the conversation: The extension vendor, not you

STRENGTHS AND LIMITS

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.

APPROACH 1

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.

Strengths

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

Limits

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

APPROACH 2

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.

Strengths

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

Limits

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

APPROACH 3

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.

Strengths

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

Limits

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

SIDE BY SIDE

The ten 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.

Criterion	Browser extension	WebMCPPROVIDED BY THE AGO SDK	In app agentWHAT AGO BUILDS
Changes needed on your site	None	Tool declarations in the page	An SDK and the functions you expose
Setup with AGO	Outside what AGO does	Provided by the SDKone setting to switch on	Provided by the SDKyou add your functions
What the model perceives	Screenshots and the DOM	The tools the page declares	Your data, state and functions
Speed of one action	Slowread and act on every step	Fastone typed call	Fasta 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

HOW TO CHOOSE

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.

Browser extension

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.

WebMCP tools

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.

In app agent

OUR POSITION

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.

Automatically WebMCP compatible

Set webmcp: true and the functions you register for your AGO agent become WebMCP tools. No second integration, and the tools stay inactive in browsers without support.

Analytics on your agent and on WebMCP

The conversations with your AGO agent, and the calls outside agents make through WebMCP: which tools they use and with what result. Resolution, escalation, knowledge gaps and quality scores sit alongside, in the platform.

A platform to build the agent

Connect your knowledge, your APIs and your functions, decide what the agent may do, and test every change in the agent lab before a customer sees it.

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.

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.

See the whole platform Read the SDK page

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

PUBLIC DEMO

Try AGO in your app without an account

Run a command in your project to let your coding agent read the SDK docs and connect a chat to the public demo agent. No signup or API key is needed. You then choose which routes and functions to expose.

Pick your coding agent

your terminal

claude "Read https://raw.githubusercontent.com/useago/ago-sdk/refs/heads/main/llms-full.txt and integrate @useago/sdk into this app. Use the public demo agent: baseUrl https://playground.api.useago.com, agent generic-guide. No signup or API key is needed. Start with a working chat, then ask which routes and functions to expose."

1Run the commandAt the root of your app, in the coding agent you already use.

2It reads and wiresThe agent pulls llms-full.txt and installs the SDK where it belongs.

3You take it from thereDescribe one route, expose one function, and watch the agent use them.

Read the docs See the SDK page

FAQ

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. With the AGO SDK, setting webmcp: true makes the functions you registered WebMCP tools automatically, and AGO analytics show which of them outside agents call. 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.

GET STARTED

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.

Book a demo Explore the platform