Every assistant draws its own way, and the bill lands on the people who already maintain your button component. This is a call to arms to fix this.

Connecting was the easy part and the plumbing is close to settled for MCP Servers, which followed the lead of HTTP dressed up for the AI era.

What isn’t is what each client does when your agent needs a date picker on screen: which components exist, who owns the rendering, what it looks like when it shows up on a screen.

There are four ways a client can do it, and every product you care about sits in one of them. Nobody publishes that comparison, so sorting out which client does which took four specifications, a protocol proposal and a Google engineering post, and none of them agree on what to call any of it.

Google’s trying to create that standard — A2UI. It’s short for agent-to-UI, their attempt at a shared approach i.e. doing the right thing.

Introduced in December 2025, it is declarative: the agent sends JSON naming components the client already holds in a catalog, and the client draws them in its own code. No markup crosses the wire, and no styling either.

Version 1.0 is still a release candidate and it looks a lot like the HTML constructs of 1999. It matters because it is the one proposal on the table that no vendor “owns.”

Working this out should not be a research project, and this is a call to arms to get there.

Here’s where we are today with A2UI and its adoption.

A2UI

Declarative JSON, rendered by the client

The agent names components the client already holds, and nobody owns the vocabulary. Three apps render it without a bundled renderer, which means they are hedging their bets.

• Google Gemini Enterprise renders the standard A2UI component set. Styling is Google’s.
• Google Opal draws its natural-language mini-apps with it. Styling is Opal’s.
• OpenClaw Canvas renders agent-built UI on connected devices. Styling belongs to the plugin.

A developer tier renders it too — Google’s ADK Web, the alpha Flutter GenUI SDK, CopilotKit AG-UI, Vercel json-render — but nobody works there.

Sandboxed HTML, if you ship the A2UI renderer yourself

A page arrives and runs in a frame. More expressive, less governable, and it stays a web object wherever it lands. These clients do render A2UI: the server sends application/a2ui+json and the app parses it locally with a bundled renderer, which means they are also hedging their bets. Google published three patterns for combining the two in June 2026.

• OpenAI ChatGPT renders app UI through the Apps SDK. Styling is yours — you shipped the CSS.
• Anthropic Claude renders Artifacts and hosts MCP Apps carrying their own renderer. Styling is yours, same reason.

Not A2UI List

Declarative JSON through vendor catalog

Same mechanism, one owner.

• Microsoft Teams and Outlook render Adaptive Cards across seven renderer SDKs. Styling is Microsoft’s, set by host config.
• Salesforce Slack renders Block Kit. Styling is Slack’s — its docs say Slack controls contrast so you don’t have to.

Generated code or nothing

The model writes the interface fresh each time, or the client has no surface at all.

• Google Gemini Consumer, writes generative UI per prompt. Styling is whatever the model invented that minute, if at all.
• xAI Grok renders nothing. It has tools and no surface format at all.

The only approach that lets your server control appearance is the one that ships a page, and that’s the one that turns into a webview on a phone. Every declarative option hands styling to the client, which is a feature right up until the client belongs to somebody else.

Two more things fall out.

• The declarative approaches are one mechanism with different owners, which is why the model was never the argument.
• A2UI reaches the clients your users actually open only by shipping its renderer inside every payload — the adapter tax in miniature, and a strange thing to call a standard.

You will pay for that gap. Not in licensing — in a tax. Every surface is another target your design system has to serve, and every platform multiplies it again.

Surfaces times platforms — that’s the surface tax.

Learn from the browser wars

Netscape and Microsoft spent the late 1990s shipping tags at each other. document.layers against document.all.

Every serious site carried browser-sniffing code at the top and two layouts underneath, and the people who wrote that code hated it. Ask Jeffrey Zeldman, which I covered in this article — Designing with web standards: The playbook for this AI moment.

Then Internet Explorer 6 won and the web stopped moving for five years. Firefox pulled developers back by rendering to spec. Google Chrome arrived in 2008 and finished the job — fast, yes, but mostly predictable. You could write a page once and know what it would do. Chrome now holds close to 68% of the browser market, per Statcounter’s July 2026 figures, so it’s a solved problem.

Agentic UI are the old browsers in a new costume, and they are called ChatGPT, Claude, Gemini, Copilot and Slack, with a side of Grok and Perplexity.

The authors of MCP Apps, an extension to the Model Context Protocol, say so in their proposal — without a standard, “developers must maintain separate implementations or adapters for different hosts.” MCP-UI, the project that spec grew out of, counts Postman, Hugging Face, Shopify and ElevenLabs among its adopters. The adapters exist.

Someone is paying for them — it’s us.

Look past chat to the canvas

A message list with an input and a stop button is a solved shape, drawn about the same way everywhere. The canvas is where it gets expensive — Gemini’s Dynamic View, ChatGPT’s Canvas, Microsoft rendering app UI in Copilot chat and out into Teams, Outlook, Word and Excel.

In Google’s own November 2025 evaluation of that generated UI, sites built by human experts still came out on top, and generation can take “a minute or more.”

Runtime assembly needs a shared parts list. Right now every vendor keeps their own.

So Google runs both approaches at once — open-ended code generation in the consumer app, a declarative catalog in the protocol. A consumer canvas can afford a minute and a look it invented this morning. Your product cannot. An approval form on your canvas has to be your date picker, your error states, your empty state, and it has to land before the user’s attention does.

Copy what Slack and Microsoft already proved

The standards argument keeps skipping this. It was solved twice already, in production, by companies with no idea they were prototyping agent UI.

Slack’s Block Kit is blocks, block elements and composition objects, authored as JSON. A server sends the structure; Slack draws it. It runs across messages, modals and App Home tabs, with limits that tell you it’s a real system under load — 50 blocks per message, 100 in a modal.

Microsoft’s Adaptive Cards went further. The pitch is nearly word for word what A2UI now promises: “platform-agnostic snippets of UI, authored in JSON, that apps and services can openly exchange.” Microsoft maintains seven renderer SDKs — JavaScript, .NET, .NET WPF, .NET HTML, Windows UWP, Android and iOS — with React Native contributed by the community.

Teams alone documents a whole card taxonomy: hero, thumbnail, list, connector, adaptive in the same way design systems are documented.

Nobody has to prove declarative UI works across native clients. Microsoft shipped that proof years ago.

The model is not the risk.

The problem is ownership. Block Kit draws in Slack. Adaptive Cards draw in Microsoft’s products. Both are proprietary, and neither will ever be the format the other adopts. If you have ever fought a Block Kit layout into your brand, you know the ceiling of a parts bin somebody else owns.

Make the baseline neutral

A2UI is that baseline, or the best attempt so far. Its 1.0 specification defines surfaces, components and catalogs as JSON naming parts the client already holds — Google calls it a “declarative data format, not executable code.” Same shape as an Adaptive Card, except no vendor owns the parts bin and it streams, so the interface builds as the agent thinks.

Compare that to the other direction. MCP Apps delivers text/html;profile=mcp-app into a sandboxed iframe. That’s a page, not a description, and it never becomes a SwiftUI sheet or a Jetpack Compose bottom sheet — on a phone you get a webview, with the wrong scroll physics, the wrong keyboard, Dynamic Type ignored and a VoiceOver reading order from a different document than the one around it. Bundling an A2UI renderer inside that page gets the vocabulary back, not the native widgets.

A component that doesn’t exist in your system cannot appear at all.

The declarative side inverts all of that. A component that doesn’t exist in your system cannot appear at all, an easier promise to make to a security team than “the sandbox will hold.” A2UI’s community renderer list covers SwiftUI, Jetpack Compose, React Native, Vue and Lynx — the same native-renderer play Adaptive Cards made, minus the owner.

Version 1.0 stripped theme properties out of the payload entirely, so a button carries a primary variant and nothing about color. Christine Vallaure’s UX Collective piece puts the designer’s half plainly: the intelligence decides what to show, your design system decides what it looks like. That holds only where the catalog is yours.

The caveat: most of those mobile renderers are volunteer work, and A2UI’s documentation tells you to check compatibility yourself. Microsoft staffs seven of its eight.

Add up the surface tax

Do the multiplication: Your design system probably serves the web, iOS and Android today. Add ChatGPT, Claude, Gemini, Copilot across Teams and Outlook, and Slack.

Ten surfaces across three platforms isn’t 10 problems, it’s the same date picker in Block Kit JSON, again as an Adaptive Card, again for whatever ChatGPT wants, then regression-tested against a matrix nobody staffed.

There’s a rough price on this for mobile already.

A 2026 survey of 267 app development companies by GoodFirms put a mid-level product built natively for iOS and Android at $120,000 to $300,000, against 20% to 40% less to build it once cross-platform, and maintenance adds 15% to 25% of budget every year after. Agent surfaces cost less per unit, but the shape is the same, and you’re adding units faster than you ever added platforms.

It isn’t elegance. It’s who absorbs the complexity, and right now the answer is your design systems team, if you even have one of at all.

Nathan Curtis wrote about balancing platforms in a design system at EightShapes: once a system serves more than one platform, the real work is deciding what’s shared and what’s justifiably different.

Agent surfaces add a twist — you don’t own the renderer, so you can’t decide at all. The cost lands in the drift. Sparkbox’s 2022 design systems survey of 219 practitioners found 37% of maintainers struggling with design-code parity and 16% tracking usage metrics, and that was before AI.

One shared format doesn’t delete the work.

It changes what you maintain from N implementations to one catalog with N renderers, and moves that burden onto the platform vendors, and right now that’s your team.

Pick a target

After all of this, A2UI might not be the one, in same way there were competing standards in 1999.

Version 1.0 is still a release candidate, the repository has no neutral foundation behind it, and every native deployment so far is Google’s own. Google has abandoned better-supported things.

But the shape is right, and we know it because two companies already shipped it. Adaptive Cards proved a JSON card renders as native UI across seven renderer SDKs. Block Kit proved it carries real interaction at scale. Neither can be the standard, because a standard owned by Microsoft is Microsoft’s standard.

So pick your target, and make every vendor answer one question before you build against theirs: which renderers do you ship, on which devices and who maintains them. The ones who can’t answer are asking you to pay the tax for them.

Start with these four moves now and then plan for a new world

• Count the cells, not the surfaces. Put surfaces down one axis and platforms across the other, then fill in who owns each cell today. The empty cells are your roadmap, and the count turns this into a budget line.
• Write the catalog, not the screens. Pick the 12 components an agent needs to finish a task in your product — table, form, date picker, confirmation, status, error and empty state — and specify each with its states and constraints, versioned. That asset transfers to whichever format wins. Screens built against one vendor’s surface don’t.
• Read the Adaptive Cards schema before you design anything. It’s the most mature declarative UI vocabulary in production, and it will tell you in an afternoon which of your components survive translation and which only work because you control the CSS.
• Test on a mid-range Android phone first, not last. Run your first agent-rendered form on real hardware with TalkBack on and Dynamic Type up. If it only holds together in a desktop browser, you’ve found the ceiling.

---

The call for an agentic standard: We need to stop shipping the same form four different times was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.