Chrome shipped an embedded model in 2025. Edge added agent mode shortly after. By mid-2026, every major browser has a built-in agent layer that any web app can opt into. The implications for app developers and existing agent products are bigger than the announcements made it sound.
What "browser-native" actually means
Three new layers, depending on browser:
- On-device model — a small LLM (Gemini Nano in Chrome, Phi-class in Edge) that runs locally with no network.
- Agent runtime — the browser orchestrates a multi-step agent loop, with built-in tool calls.
- Tool surface — DOM access, page inspection, form interaction, and selectively exposed Web APIs.
Together, the browser becomes a local MCP host. Web pages can declare what tools they expose; the user's agent uses them.
The new APIs to know
Prompt API (Chrome)
A window.ai.languageModel interface. Synchronous, on-device, capped output length. Useful for in-page summarisation, classification, transformation.
Writer / Rewriter (Chrome)
Constrained text-generation primitives. Less flexible than Prompt API; better for safety-critical writing.
Page Agent API (proposed)
A standard for pages to expose their actions to the browser's agent. Buttons, forms, and flows declare their semantic purpose.
MCP-over-Web (emerging)
A draft of MCP that runs over postMessage between browser agent and web app. Lets web apps act as MCP servers without a separate process.
What this changes for app developers
Three immediate consequences:
1. Pages become MCP servers
If you ship a web app, expect users to drive it through their browser-native agent. Mark up your actions with the Page Agent metadata so the agent can use them.
2. Local privacy becomes a feature
For tasks the on-device model handles, no data leaves the user's machine. UX writing, content summarisation, light classification — all candidates.
3. Bring-your-own-key SaaS dies for some segments
Why pay $20/month for a tool that summarises if Chrome does it locally? Premium tier reframes around quality, not access.
What survives, what does not
| Pattern | Survives? |
|---|---|
| Heavy reasoning agents | Yes — beyond on-device capacity |
| Document creation tools | Mostly — quality bar matters |
| Data integration agents | Yes — browser cannot reach your backend |
| Coding agents | Yes — IDE-native beats browser-native |
| Light text utilities | Mostly NOT |
| Single-page summarisation | Pure browser |
Building for the new world
Three things to start now:
1. Add Page Agent metadata
<button data-agent-action="export-data" data-agent-args="format,date_range">
Export
</button>
Lets the browser-native agent invoke your action correctly.
2. Detect on-device capability
if ('ai' in window && (await window.ai.languageModel.capabilities()).available === 'readily') {
// use on-device for the easy 70% of tasks
} else {
// fall back to your remote agent
}
3. Ship a hybrid agent
The product runs on-device when possible, escalates to your remote stack for the hard cases. UX is identical; cost shifts. See agent model routing.
Privacy implications
On-device models do not solve privacy by themselves:
- Page content the agent sees can still be exfiltrated by other extensions.
- Tool output the page returns to the agent may travel back to your server.
- Cross-tab access — browser agents can in some configurations read other tabs.
The Page Agent spec includes per-action consent prompts. Use them.
Performance reality
On-device performance varies by hardware:
| Device class | Tokens/sec | Realistic use |
|---|---|---|
| MacBook M3 Pro | 80–150 | Real-time text gen |
| Mid-range PC laptop | 30–60 | Background summarisation |
| Older hardware | < 15 | Text classification only |
Plan UX for the slow case. Server fallback removes the cliff.
Common mistakes
- Assuming on-device == private — page-level privacy needs more than model location.
- Building only for Chrome — Edge, Brave, Arc each have distinct APIs in 2026.
- Ignoring fallback — on-device fails on older hardware; have a server path.
- Marking up too much — exposing every button to the agent creates a discoverability problem; pick the actions that matter.
Where this is heading
Three shifts by 2027: a W3C-blessed Page Agent API, MCP-over-Web stabilises, and consumer products ship "you do not need our SaaS, your browser already does it" comparisons. Either ride the wave or stake out where the on-device model genuinely cannot reach.