A2UI (Agent-to-UI) is an open, Apache-2.0 format from Google for agent-driven UI. Instead of returning plain text, an agent emits a declarative JSON description of a user interface — Cards, Buttons, TextFields, and client-advertised custom components — and a client library renders it as real, interactive widgets. The tree is incrementally updatable, so the UI can render progressively as the agent works.

How is A2UI different from MCP Apps / the OpenAI Apps SDK?

Both deliver agent-driven ("generative") UI, but the payload differs. MCP Apps / the OpenAI Apps SDK ship a ui:// HTML resource — a self-contained HTML+JS widget the author wrote, which the host renders in an iframe. A2UI instead ships a declarative component tree as JSON, with no HTML or JS; the host's own trusted A2UI client (Flutter, Web Components, or Angular) renders its components from your description. One is your rendering code in a sandbox; the other is a cross-framework description the host renders natively.

How does an agent deliver A2UI to a client?

A2UI is a payload layer, not a transport. It rides inside a live agent conversation over A2A (Agent-to-Agent) or AG-UI (the CopilotKit agent-user wire protocol), with REST transport planned. There is no static /.well-known/ artifact a crawler fetches: the component tree streams at runtime as part of an agent run, the same way AG-UI events do.

Can a website publish an A2UI endpoint the way it publishes llms.txt?

Not today. A2UI defines no publisher-side discovery file and no well-known path — the spec is built around runtime delivery inside an A2A/AG-UI conversation, and component trust is a client-side catalog of pre-approved components, not a server advertisement. The closest publisher-discoverable signal for agent-driven UI right now is an MCP Apps declaration on your MCP Server Card (a ui:// resource and UI-bound tools), which is what readiness scanners actually look for.

Does Agent Ready check for A2UI?

Yes — within the limits of what a site can advertise. Protocol check C17 (Agent-driven UI) reads your MCP Server Card and confirms it advertises a well-formed generative-UI surface: an apps block or ui:true endpoint, a ui:// widget resource, and the MCP-Apps MIME type (text/html;profile=mcp-app). It is a discover-then-validate check — sites with no such surface simply don't see it. Agent Ready dogfoods this: its own ChatGPT MCP App publishes exactly that surface.

A2UI is led by Google (used in Opal and Gemini Enterprise) and developed with CopilotKit, with stated involvement from Cisco, IBM, SAP, and Salesforce. It is open-source under Apache-2.0, currently at v0.8 ("early but working"), with client libraries for Flutter, Web Components, and Angular.

What is A2UI? Agent-driven generative UI

What is A2UI?

A2UI (“Agent-to-UI”) is an open format for agent-driven UI — sometimes called generative UI. Rather than answering a user with a wall of text, an agent emits a declarative JSON description of an interface: a Card, a Button, a TextField, and any custom components a client has advertised as trusted. A client library turns that description into real, interactive widgets. The tree is incrementally updatable, so the UI renders progressively as the agent works.

The project is open-source under Apache-2.0 at a2ui.org (google/A2UI), currently v0.8 — “early but working” — with client libraries for Flutter, Web Components, and Angular.

A2UI vs MCP Apps: two kinds of generative UI

Both A2UI and MCP Apps / the OpenAI Apps SDK let an agent render real UI in a conversation, but the payload is fundamentally different:

MCP Apps ship a ui:// HTML resource — a self-contained HTML+JS widget you wrote, which the host drops into an iframe and runs.
A2UI ships a declarative component tree as JSON — no HTML, no JS. The host’s own trusted A2UI client renders its components from your description, cross-framework and without an iframe.

In short: MCP Apps is your rendering code in a sandbox; A2UI is a description the host renders natively. They are complementary, and A2UI is explicitly designed to be transport-compatible with the same generative-UI ecosystem.

How is A2UI delivered? (A2A, AG-UI, REST)

A2UI is a payload layer, not a transport. The component tree rides inside a live agent conversation over A2A (Agent-to-Agent) or AG-UI (CopilotKit’s agent–user wire protocol), with a REST transport planned. That runtime nature is the crux of how A2UI differs from the rest of the agent-readiness signals: there is no static file a crawler fetches — the UI streams as part of an agent run.

What can a website actually publish?

Here is the honest limitation: A2UI defines no publisher-side discovery artifact. There is no /.well-known/a2ui file and no well-known path, because component trust is a client-side catalog and the UI is delivered at runtime. So unlike llms.txt or an MCP Server Card, A2UI is not something a static scanner can fetch and grade directly.

The closest publisher-discoverable signal for agent-driven UI today is an MCP Apps declaration on your MCP Server Card — a ui:// widget resource plus UI-bound tools. That is the surface readiness scanners (including ora.ai) inspect when they grade “A2UI / generative UI” support.

How Agent Ready checks it (C17)

Agent Ready’s protocol check C17 — Agent-driven UI (A2UI) reads your MCP Server Card and confirms it advertises a well-formed generative-UI surface:

an apps block or a ui: true endpoint with an absolute endpoint URL,
at least one ui:// widget resource, and
the MCP-Apps MIME type text/html;profile=mcp-app.

It is a discover-then-validate check — sites that advertise no such surface simply don’t see it, so a marketing site is never penalised for lacking one. Agent Ready dogfoods this: its own ChatGPT MCP App publishes exactly that surface, so it passes its own check. Grading the qualityof the rendered widget (valid HTML5, dark-mode, CSP, no secrets) requires connecting to the live MCP server at runtime — a deeper probe tracked separately.

A2UI sits alongside the other agent-readiness signals — NLWeb, llms.txt, AGENTS.md, and protocol manifests. To see where your site stands today, run a full agent-readability scan.

Frequently asked questions

What is A2UI?: A2UI (Agent-to-UI) is an open, Apache-2.0 format from Google for agent-driven UI. Instead of returning plain text, an agent emits a declarative JSON description of a user interface — Cards, Buttons, TextFields, and client-advertised custom components — and a client library renders it as real, interactive widgets. The tree is incrementally updatable, so the UI can render progressively as the agent works.
How is A2UI different from MCP Apps / the OpenAI Apps SDK?: Both deliver agent-driven ("generative") UI, but the payload differs. MCP Apps / the OpenAI Apps SDK ship a ui:// HTML resource — a self-contained HTML+JS widget the author wrote, which the host renders in an iframe. A2UI instead ships a declarative component tree as JSON, with no HTML or JS; the host's own trusted A2UI client (Flutter, Web Components, or Angular) renders its components from your description. One is your rendering code in a sandbox; the other is a cross-framework description the host renders natively.
How does an agent deliver A2UI to a client?: A2UI is a payload layer, not a transport. It rides inside a live agent conversation over A2A (Agent-to-Agent) or AG-UI (the CopilotKit agent-user wire protocol), with REST transport planned. There is no static /.well-known/ artifact a crawler fetches: the component tree streams at runtime as part of an agent run, the same way AG-UI events do.
Can a website publish an A2UI endpoint the way it publishes llms.txt?: Not today. A2UI defines no publisher-side discovery file and no well-known path — the spec is built around runtime delivery inside an A2A/AG-UI conversation, and component trust is a client-side catalog of pre-approved components, not a server advertisement. The closest publisher-discoverable signal for agent-driven UI right now is an MCP Apps declaration on your MCP Server Card (a ui:// resource and UI-bound tools), which is what readiness scanners actually look for.
Does Agent Ready check for A2UI?: Yes — within the limits of what a site can advertise. Protocol check C17 (Agent-driven UI) reads your MCP Server Card and confirms it advertises a well-formed generative-UI surface: an apps block or ui:true endpoint, a ui:// widget resource, and the MCP-Apps MIME type (text/html;profile=mcp-app). It is a discover-then-validate check — sites with no such surface simply don't see it. Agent Ready dogfoods this: its own ChatGPT MCP App publishes exactly that surface.
Who is behind A2UI?: A2UI is led by Google (used in Opal and Gemini Enterprise) and developed with CopilotKit, with stated involvement from Cisco, IBM, SAP, and Salesforce. It is open-source under Apache-2.0, currently at v0.8 ("early but working"), with client libraries for Flutter, Web Components, and Angular.