A2UI is Google's open source declarative protocol for the user interfaces that AI agents hand off to chat clients and copilots, and a new Google developer post mixing it with the iframe based MCP (Model Context Protocol) Apps shows the host app, not the agent, getting the final…
When Google published its June 17 developer-blog post on combining A2UI and MCP Apps, most readers saw a styling recipe: pick a declarative UI path, pick a custom iframe path, or mix them. The real story is quieter and more consequential. A2UI is Google's open-source protocol for the user interfaces that AI agents hand off to host apps like chat clients and copilots, and its defining mechanic hands the rendering decision to the host's runtime, not the agent's code. That is not a developer-experience preference. It is a sovereignty choice about who controls the surface the user actually sees.
The same post documents three patterns for mixing A2UI with MCP Apps, the iframe-based extension of the Model Context Protocol that lets agents serve full custom HTML, CSS, and JavaScript UIs inside a host sandbox. A2UI ships a JSON payload that the host renders with its own native components, which gives consistent design and lets the host refuse, remap, or rebrand anything it does not ship natively. MCP Apps gives the agent a sandbox to run arbitrary web code, which is creatively powerful but introduces iframe fragmentation, redundant scrollbars, performance overhead, and the persistent problem of security encapsulation. The Google post is candid about all of this. Its contribution is not to pretend the trade-off is gone, but to publish bidirectional integration guides for letting each side do what it is good at.
What makes this more than a developer-tools story is where the host's new gatekeeping power sits. A2UI is described by the a2ui.org project as an open standard for agentic user interfaces, backed by the open-source A2UI repository. MCP Apps, meanwhile, is being formalized as an official extension of the broader Model Context Protocol, the same standard that already gives agents a way to call tools and pull in context. Google's developer blog frames A2UI and MCP Apps as complementary rather than competitive, but the architectural reality is sharper. If the host controls the component library, the host controls what kinds of interactions an agent can express, what counts as a native affordance, and which user actions the agent is allowed to suggest at all. An agent developer who chooses A2UI is choosing, in effect, to ship within whatever vocabulary the host runtime happens to expose.
That choice is now made more durable by the bridge. The a2ui.org project publishes guides in both directions, so an agent running inside an A2UI-native host can drop into a custom MCP Apps iframe when it needs a complex client-side interaction, and an agent running inside an MCP Apps host can ask the host to render declarative A2UI surfaces when it does not. The agent does not have to commit to one rendering universe up front. The host, however, has to opt in to the bridge at all. If a chat client refuses to ship A2UI support, or ships a stripped-down version with a thinner component library, agents running inside that client simply lose the ability to express certain UI patterns, even if those patterns are perfectly valid in another host. The agent's expressive range becomes a function of the host's catalog.
Google is the only major player that currently sits on both sides of this bridge. A2UI is published under Google's developer blog and the a2ui-project GitHub organization. MCP Apps is an extension of the open Model Context Protocol, and the spec lives at modelcontextprotocol.io. The same Google developer blog that has been publishing A2UI guidance has also covered the parallel agent-to-agent protocol, A2A, which a Medium explainer frames as the agent-to-agent sibling to the user-facing protocols in play here. So whichever UI envelope wins in a given host, the default reference implementation, the default doc set, and the default code repository are Google's. That is not a guarantee of dominance, but it is the structural condition for it.
A second-order signal from the same ecosystem reinforces the picture. While the UI story is playing out, the MCP project blog is publishing enterprise-readiness work, including a post on zero-touch OAuth for MCP that targets the procurement and identity-management layer. Enterprise buyers tend to buy host platforms, not agent protocols, and the platforms that win the UI gatekeeping argument are likely to be the ones that also absorb the authentication and tool-call traffic. Adoption is uneven: a third-party aggregator tracks MCP usage, but the numbers are vendor-adjacent and should be read as a directional signal, not a census.
The watch items, then, are concrete. Does any non-Google chat client ship full A2UI support, or do they all ship a subset? Does the proposed MCP extension for A2UI actually land, and if it does, does it arrive as an open spec or a Google-shaped default? And when an enterprise customer asks its AI vendor what UI components its agents are allowed to render, does the answer come from the agent developer, or from the host platform that already chose the component library? The Google post is a recipe book. The sovereignty question is whether the cookbook is the only one the host kitchen will accept.