Agent Mode: The Agent-Native Web

A straw man proposal so in-agent browsers can tell websites who they are, websites can talk back, and you can hand your agent work without leaving the page.

TL;DR

• Agents browse the web now through in-agent browsers (Codex, Claude Code, Cursor), but to every site they look like a human with a mouse: pages cannot tell, cannot adapt, and cannot talk back. Every tool that needs the bridge hacks its own.

• Agent Mode is a straw man proposal in two layers. Layer 1: the browser announces the agent (an Agent-Mode header plus navigator.agentMode) and the site answers with a discovery file of affordances (CLI, MCP server, a skill to install). Layer 2: the page hands the agent work ("draft a reply to this email") behind per-site permissions and the agent's own approval loop, and the response lands back in the page.

• The ask: agent makers ship Layer 1 (a sprint of work), app makers publish their discovery files, tool makers converge on the shared surface.

1. The weird relay

If you have followed Dan Shipper's Codex-native apps, you have seen the direction: apps that run inside the agent rather than beside it. If you have tried it yourself, building your own app and running it inside Codex, Claude Code, or Cursor, you have also met the seam. It shows up small.

You have probably done this in the past week. An agent is building your app, and its in-agent browser, the one it drives from inside Codex or Claude Code or Cursor, is pointed at the page it just changed. You are looking at the same page. The spacing under the pricing card is wrong, so you switch to the terminal and type "the spacing under the pricing card is off, the second one, below the button" at a model that has a screenshot of those exact pixels open in a browser it controls.

Two parties are looking at the same thing, and you are describing it to one of them in prose. The agent has eyes. The page has structure. There is no handshake between them, so the human plays telephone.

The relay is not a niche irritation, because the in-agent browser is becoming a default surface. Claude Code drives one. Cursor drives one. Codex opens your app to check its own work. And to every page they visit, these agents are indistinguishable from a person with a mouse: the page renders its human UI, the agent screenshots it, clicks by coordinate, scrolls, screenshots again. It is a machine pantomiming a human for no one's benefit.

The tools have started to notice. Most harnesses now ship some kind of design-annotation mode: point at an element in the in-agent browser, type a note, and the feedback lands in the agent's context. Those features work, and they work for exactly the reason the relay hurts: you interact with the content instead of describing it. But each one is a single vendor's build, wired into a single browser, for a single job, design feedback. There is far more behind that door.

I think the fix is a mode with a standard behind it: the browser announces that an agent is driving, and the page gets a channel to answer. Annotation stops being a per-vendor feature and becomes one use of a shared surface. The rest of this piece is the proposal.

2. Five tools, zero shared wire

If you want evidence that people need the page-to-agent path, look at how many are hand-building it right now.

• DialKit (Josh Puckett) puts a live tuning panel on your page: adjust springs, easings, and color in the browser, then carry the values back by copying a prompt into your agent.

• Agentation (Benji Taylor) is an annotation toolbar for the live page: click an element, type feedback, get markdown with real CSS selectors an agent can grep for. It ships an optional MCP server for real-time sync.

• Impeccable (Paul Bakaus) is a design-quality harness whose live mode injects a script into your page, so you can click any element and request a change in plain language.

• RiffRec (mine) records a product session: screen, narration, clicks, console errors, network outcomes, written to local files an agent digests afterward.

• ui.sh (the Tailwind CSS team) installs design taste into the terminal where the agent lives, and drops a feedback widget into your running app so you can point at the design from inside it.

Count the transports: copy-paste, a per-tool MCP server, an injected localhost script, files on disk, an embedded widget. None shared, none standard. No tool on this list can detect that an agent is viewing the page, and none can push a message to one; everyone is building the same bridge alone. This is what an ecosystem looks like the year before a standard.

3. Two standards, and the gap between them

You would think this was already covered. Two serious efforts sit nearby.

Web Bot Auth is identity at the HTTP layer. A Cloudflare-led set of IETF drafts, backed by OpenAI, Amazon, and Akamai, with verification already running at Cloudflare's edge: agents cryptographically sign outgoing requests (RFC 9421 message signatures; a Signature-Agent header points at the signer's public key directory), so a server can verify "this really is OpenAI's agent" instead of trusting a spoofable user-agent string. It is passport control at the border, real and running, and invisible to the page: the signature is verified at the edge or origin, and by the time your JavaScript runs, the identity is gone. DialKit cannot ask the CDN who is browsing.

WebMCP is capability at the page layer. A W3C proposal from Google and Microsoft engineers, in Chrome origin trial now: your page calls navigator.modelContext.registerTool() to expose structured tools ("search_flights", "add_to_cart": a name, a JSON schema, an execute callback), and an in-browser agent calls those tools instead of screenshot-clicking your UI. A service counter inside the shop. But the direction is fixed: the agent calls the page. The page does not learn an agent is present until a tool fires, and it has no way to start a conversation.

Different layers, different standards bodies, no references to each other. And between them, uncovered, sits the workflow every tool in section 2 is hacking toward:

1. No page can detect an agent client-side.Identity lives in headers the server sees; page JavaScript gets nothing.
2. No page can send a request to the agent.The agent can call registered tools; the page can never initiate.

(The adjacent conventions do not cover it either: llms.txt points crawlers at content, AGENTS.md briefs a coding agent about a repo. Files an agent reads, not a channel a live page can use.)

4. Layer 1: the browser admits it

So here is the straw man. Agent Mode has two layers, and the first is deliberately small: identity and discovery. In practice it looks like this:

Agent Mode is opt-in, per session. Not always-on, so it cannot be turned into a blocking regime; the human, or their harness policy, chooses it. When it is on, three things happen:

• The request carries a header. Something as plain as Agent-Mode: on; agent="claude-code"; interactive=true. It can ride alongside a Web Bot Auth signature when cryptographic proof matters; the point here is not proof, it is declared context a server can adapt to.

• The page gets a signal. A navigator.agentMode property (agent name, version, whether a human is co-present) plus a change event. Front-end code can finally branch: the identity from the border reaches the shop floor.

• The site gets to answer. A discovery file, say /.well-known/agent-mode.json, where the site declares its agent affordances: here is our CLI, here is our MCP server, here is a skill your agent can install, here is the path that skips the marketing tour. The agent reads it on arrival instead of inferring everything from pixels.

What would sites do with this on day one? Drop the cookie banner and the onboarding tour and render the dense view instead of the animated one. A staging app could hand a visiting agent test credentials. A docs site could offer a skill instead of a README: browse DialKit in Agent Mode and your agent leaves already knowing how to wire it up.

Two fears, priced honestly. Could sites use the signal to block agents? They already try, with user-agent sniffing and bot heuristics; an honest mode does not add much blocking power, it mostly ends the pretending. Could it become surveillance? It identifies a mode the agent chose to announce, not a person; there is nothing here to fingerprint a human with. The real trade is that agents in Agent Mode give up stealth, and stealth was never a foundation you could build tooling on.

Layer 1 is boring on purpose: a header, a navigator property, a JSON file. A vendor could ship it in a sprint, which is the point.

5. Layer 2: the page gets a voice

Detection alone does not delete the relay. The page can now greet the agent; it still cannot say anything useful. Layer 2 is the channel: the page sends structured requests to the agent driving it. The flow, before the details:

The straw man API is one call:

const reply = await navigator.agentMode.request({
  intent: "draft-reply",
  summary: "Draft a response to this email thread",
  context: { thread, tone: "brief" }
});

with a JavaScript and React SDK (useAgent()) as sugar for the tools people build. The await matters: the channel is round-trip. When the agent finishes, the response lands back in the page, so the app can act on the answer instead of hoping the work happened somewhere off-screen. What flows through it:

• Cora puts a "have your agent draft the reply" button inside an email thread: the app hands the thread and the ask to the user's own agent, instead of running its own model or asking you to paste context around. When the agent is done, the draft drops back into the compose box.

• Agentation's annotations stop being clipboard cargo: you mark up the live page and the feedback lands in the agent's queue with selectors attached. That is the relay from section 1, deleted.

• DialKit grows an "apply" button: the spring constants you tuned in the browser travel to the codebase as a structured change request instead of a pasted prompt.

Note the inversion. WebMCP lets the agent call the page; Layer 2 lets the page ask the agent. They are complements and probably belong in one standard eventually; whether Layer 2 extends navigator.modelContext (its authors parked an event-based window.agent as future work) or stands alone is a naming fight this straw man would happily lose.

6. The objection you are already typing

A page that can send requests to your agent is a prompt-injection funnel with a nice SDK. That is the design problem, not a footnote, so Agent Mode takes a position: three gates, all mandatory.

1. The mode gate.Layer 2 does not exist outside Agent Mode. There is no ambient exposure; a human, or their harness policy, turned this on for this session.
2. The site grant.Pages request the channel per origin, and the harness mediates, the way camera and microphone permissions work today. Your agent's browser knows which sites you have granted a voice, and everything else gets silence.
3. The approval loop.Every request arrives as untrusted input with no more authority than a suggestion typed into the agent's prompt box: it passes through the same permission and approval chain every other agent action already does. Nothing executes on the page's say-so.

That is defense in depth, and a concession comes with it: this is a design contract, and nobody has battle-tested it yet. Prompt injection is not solved here; it is contained. If you want to attack the straw man, attack it here: it is the most load-bearing wall.

7. The ask

The whole proposal stages into one small first step, which is the reason it might actually happen.

• Agent makers (Cursor, Anthropic, OpenAI, Google): ship Layer 1. Send the header, expose navigator.agentMode, read the well-known file. It is a sprint of work, and every layer above it is blocked on you.

• App makers: publish the discovery file and design your agent path. Decide what a visiting agent should see, skip, and be told. You can sniff for agents heuristically today and adapt badly; be ready to adapt well the day the signal is honest.

• Tool makers: converge. DialKit, Agentation, Impeccable, RiffRec, and whatever ships next month are each maintaining a private bridge; target a shared surface and keep the bespoke transport as a fallback.

Where should this discussion live? Honestly open. The W3C group behind WebMCP is the nearest campfire, and a spec repo can follow if this resonates. For now, this article is the straw man, and the request is that you tear it apart in public.

The web has grown a mode for every new reader it has ever had: print stylesheets, responsive viewports when phones arrived, reader mode, screen readers and the accessibility tree. The newest reader shows up a thousand times a day and spends real money, and we still make it squint at pixels and pretend to be a person. Agent Mode is the web doing what it has always done, one reader late.

Grounded in the Agent Mode brainstorm synthesis and research dossier (Web Bot Auth, WebMCP, MCP Apps, DialKit, Agentation, Impeccable, RiffRec, ui.sh), July 2026.