Every few years a technology shows up that looks like a product but is actually a protocol. When that happens, the product gets forgotten and the protocol becomes infrastructure. Google I/O 2026 had one of those moments. It just didn't get treated like one.
The models were impressive. Gemini 3.5 Flash is four times faster than its predecessors. Antigravity 2.0 makes agent orchestration feel like something you'd actually ship. AI Studio now deploys to Cloud Run in one click. None of it was architecturally surprising. But buried in the developer sessions was something different: WebMCP, a proposed open standard for exposing structured tools to browser-based AI agents.
That one is worth sitting with.
The Failure Mode Everyone Already Knows
If you have ever maintained Selenium automation for more than six months, you already understand the problem WebMCP is trying to solve.
The automation works until the product team redesigns the checkout page. Then the selector breaks. You fix it. Three weeks later the login flow changes. You fix it again. You are not engineering anything — you are running a permanent rearguard action against a UI that was never designed to stay still. The automation is fragile because it is built on inference: your code is guessing at intent by reading presentation.
The first generation of browser AI agents have exactly this problem, at larger scale and higher stakes. They can see buttons and forms and navigation menus, and they can click on things, but they are always one redesign away from failing. They are imitating human behavior because the web has never offered them an alternative.
Imagine booking a flight through an agent today. The agent visually searches for departure fields, date pickers, seat selectors, and payment buttons. Every redesign risks breaking the workflow. Under WebMCP, the airline could expose booking itself as a structured capability: destination, dates, passenger count, seat preferences, payment authorization. The agent stops navigating the interface and starts interacting with the system underneath it.
WebMCP is the alternative.
The standard lets web developers expose structured tools — JavaScript functions, typed parameters, form interactions — as machine-readable capabilities. Instead of an agent inferring "this is probably a search box" by parsing the DOM, the site simply declares: here is a search function, here are its inputs, here is what it returns. Declarative for standard interactions, imperative for anything requiring runtime JavaScript. Chrome's experimental origin trial starts in Chrome 149.
The immediate gain is reliability. But that is not the interesting part.
What Changes Under the Surface
Websites have always been designed around visibility. If a human could see and operate something, the web had succeeded. That assumption ran so deep it was invisible — interfaces were presentation layers, and making them look right was the whole job.
WebMCP introduces a different assumption: systems may not need to be visually navigable to be operationally useful. The interface stops being primarily a presentation layer and starts being a capability surface.
That is a significant mutation.
An airline site exposing a structured booking capability is no longer just a place you visit. It becomes a service an agent can call directly. The distinction between website and API starts to blur at the protocol level, not just for developers, but for the web itself.
There is historical precedent for this shift.
RSS made web content machine-readable. A feed reader did not have to scrape a blog and guess where the article title ended and the sidebar began. The site simply exposed structure directly. RSS eventually collapsed as a consumer technology, but the idea it proved — that structured syndication beats scraping — became foundational to modern content APIs.
WebMCP does for actions what RSS did for content.
That distinction matters enormously.
Content syndication is passive. The machine reads what a human wrote. Action exposure is active — the machine performs operations on a user's behalf, with real-world consequences. The jump from "readable" to "actionable" changes the ontology of the web itself.
This is what Google is quietly building toward.
Antigravity 2.0 orchestrates agents. Gemini Spark acts across Gmail, Calendar, and eventually third-party tools via MCP. But agent workflows are only as reliable as the surfaces they operate on. The whole agentic stack presupposes that websites will eventually expose structured interfaces for machine consumption.
WebMCP is the specification for what that looks like on the open web.
The Critique You Have to Make
Here is where most conference coverage goes soft.
WebMCP only matters if adoption follows. An open standard with one browser behind it and no ecosystem buy-in is just a Chrome experiment. The history of proposed web standards is mostly a graveyard of promising ideas that died waiting for critical mass, or got implemented inconsistently enough that developers ended up writing workarounds anyway — which is to say, they ended up back at the Selenium problem.
Google has enough platform leverage to push Chrome 149 to most of the world's browsers in six months. It does not have the same leverage over every site that agents will need to use. The gap between "here is a standard" and "here is a standard that Stripe and Shopify and healthcare portals have implemented correctly" is years of developer effort and business negotiation. Nothing about announcing a standard compresses that timeline.
There is also a safety question the I/O coverage largely sidesteps.
Structured tool exposure is a double-sided surface. Right now browser agents are limited partly for the same reason they are safe: they cannot do that much. A web where every site exposes clean, machine-actionable capabilities is a web where the blast radius of a compromised or misbehaving agent gets significantly larger.
The permissions model, the consent model, the audit trail — none of that is solved by declaring "here are the actions this site supports." If anything, it sharpens the accountability question.
The infrastructure is arriving faster than the trust guarantees.
That is the honest summary of where agentic development actually sits right now. Not just for WebMCP — for all of it.
Why This Is Still the Story
None of those concerns make WebMCP less important. They make it more important to track carefully.
The DEV community's instinct after I/O was telling. The submissions that resonated were not about model benchmarks. They were about infrastructure, about privacy, about frameworks designed for machines as much as humans. That pattern is not accidental.
Developers who ship things for a living have a reliable nose for where the actual work is going to land, and right now that nose is pointing at integration — not intelligence.
The capability problem is closer to solved than most people want to admit. Models reason well. Models act. What remains unsolved is making those actions reliable, auditable, and safe at scale.
That is an infrastructure problem.
And infrastructure problems get solved by protocols, not products.
WebMCP is an early answer to the question of what reliable agent-web interaction should look like. It will probably not be the final answer. RSS wasn't either. But RSS proved the idea was viable, and everything that followed built on that proof.
The original web connected documents.
The next version may connect capabilities — not just for humans navigating pages, but for agents executing intent.
The web was built for humans to navigate.
The next version may be built for agents to operate.
Submitted for the Google I/O 2026 Writing Challenge on DEV.
