A2UI vs MCP Apps: choose the renderer, delivery route, and fallback

The practical distinction starts with the renderer. A2UI gives the client a description to render, while an MCP App gives the host a web resource to run. That boundary determines who can change the layout, which components are available, where client state lives, how styling enters the surface, and what must be tested.

Security labels don't settle the choice. A declarative catalog limits what can be requested, but the application still has to validate messages, authorize actions, and protect data. An embedded iframe provides isolation boundaries, yet the host and application still have to govern permissions, messages, resources, and side effects. These architectures have different trust surfaces, not automatic security outcomes.

Protocol articles age quickly. On October 20, 2026, the first-party A2UI navigation identifies v0.9.1 as current, v1.0 as candidate, and v0.8 as legacy. A community article from December 2025 still describes v0.8 as preview. Both pages describe their own periods, but only the current first-party documentation should govern a current version decision.

Don't write that A2UI supports a host when the evidence only shows that the protocol can express the surface. Likewise, don't write that MCP supports an app when the client supports only tool calls. Record the protocol fact, host capability, local implementation, and observed result in separate fields.

One product can reasonably use A2UI for a generated summary, ordinary form, or native mobile result, then open an MCP App for a rich editor. Make the decision at the level of the smallest surface with one coherent interaction and consequence model.

Ask nine questions about each surface. Who owns the renderer? How variable is the layout? Does the catalog cover every required state? Where does client state live? Which hosts must work? What happens if the preferred route is unavailable? Who authorizes actions? Who controls release timing? What evidence is required before accepting the surface?

A rendering choice isn't a complete application contract. A2UI doesn't supply your product policy. An MCP App doesn't gain authority because it displays a button. A design kit isn't a renderer or an accessibility result.

Accessibility needs particular care. Native components may provide useful platform behavior, while a web app may reuse mature accessible components. Neither fact proves that the composed surface works with its real labels, focus order, updates, errors, content, viewport, and host container. Evaluate the actual surface.

"Use both" is incomplete advice. The combined patterns documented by the Google A2UI Team and MCP Apps co-creators have different prerequisites. Test the exact arrangement instead of assuming the parts will compose automatically.

Fallback is product behavior. It isn't an exception message added after integration. It must preserve meaning, action safety, and recovery. The result may be less rich, but it must never imply that an unavailable control executed or an interrupted operation completed.

For consequential actions, the safe fallback may be read-only. If the alternate route can't preserve authorization, confirmation, idempotency, or authoritative completion, remove the action and explain which supported route is required. That's a controlled reduction in capability, not a hidden failure.

The following record is a template. It hasn't been executed and makes no claim about host compatibility. Replace every bracketed value, verify the governing sources, and leave observations unresolved until someone runs the named checks.

record_type: agent_ui_route_decision
status: unexecuted
recorded_on: "[YYYY-MM-DD]"
owner: "[team or person]"

surface:
  name: "[one named surface]"
  user_task: "[task this surface must complete]"
  consequence_class: "[informational | reversible | consequential]"
  required_hosts:
    - name: "[host]"
      version: "[exact version]"

version_authority:
  a2ui_version: "[version or not-applicable]"
  a2ui_governing_source: "[first-party source and capture date]"
  mcp_apps_contract: "[extension or host contract and version]"
  host_support_source: "[named host source or unresolved]"

selected_route: "[a2ui | mcp-app | a2ui-over-mcp | mcp-app-in-a2ui | a2ui-in-mcp-app]"
renderer_owner: "[client | host | embedded app]"
renderer_version: "[version or unresolved]"
component_catalog: "[name and version or not-applicable]"
web_resource: "[resource identity and version or not-applicable]"
bridge: "[bridge and message contract or not-applicable]"

required_capabilities:
  layout: "[requirement]"
  client_state: "[requirement]"
  actions: "[requirement]"
  accessibility_scope: "[conditions to evaluate]"

action_authority:
  policy_owner: "[application owner]"
  permission_source: "[authoritative source]"
  completion_source: "[authoritative runtime evidence]"

visual_source:
  authority: "[design-system source and version]"
  mapping_owner: "[renderer or app owner]"

fallback:
  trigger: "[unsupported or failed capability]"
  behavior: "[deterministic alternate behavior]"
  prohibited_behavior: "[unsafe substitution or claim]"

rationale: "[why this route fits this surface]"
correction_owner: "[owner]"
review_triggers:
  - "protocol or extension version changes"
  - "host capability or policy changes"
  - "renderer or catalog changes"
  - "action policy or system-of-record behavior changes"
disposition: pending_execution

Write the expected behavior before testing. Add observations and evidence afterward. This keeps a plausible screenshot or successful tool dispatch from becoming false proof of authorization, completion, recovery, accessibility, or cross-host support.

record_type: agent_ui_surface_acceptance
status: unexecuted
route_decision_id: "[record identifier]"
surface: "[named surface]"
host: "[host and exact version]"
protocol_and_extension_versions: "[versions]"
renderer_and_catalog_versions: "[versions or not-applicable]"
resource_version: "[version or not-applicable]"
test_date: null
tester: null

cases:
  - case: renders_required_content
    expected: "All required content and controls render from the selected route."
    observation: null
    evidence_reference: null
  - case: rejects_unknown_or_invalid_input
    expected: "Unknown catalog entries or invalid resources fail through the declared rejection path."
    observation: null
    evidence_reference: null
  - case: preserves_interaction_state
    expected: "Required state survives updates, interruption, and route handoff according to the contract."
    observation: null
    evidence_reference: null
  - case: enforces_permission
    expected: "The application checks current authority before dispatching a consequential action."
    observation: null
    evidence_reference: null
  - case: reports_completion_truthfully
    expected: "Only authoritative runtime evidence marks an action complete."
    observation: null
    evidence_reference: null
  - case: recovers_deterministically
    expected: "Unsupported and failed capabilities use the recorded fallback without losing meaning."
    observation: null
    evidence_reference: null
  - case: evaluates_accessibility_scope
    expected: "The named keyboard, focus, semantics, zoom, update, and assistive-technology conditions are evaluated."
    observation: null
    evidence_reference: null
  - case: preserves_visual_mapping
    expected: "The rendered surface maps to the declared visual source without unauthorized local substitutions."
    observation: null
    evidence_reference: null

correction_owner: "[owner]"
retest_trigger: "[dependency, policy, host, renderer, catalog, or resource change]"
disposition: pending_execution

Consider a support workflow with two surfaces. One is a case summary showing customer-visible status, recent events, and recommended next steps. The other is a complex evidence editor with filters, attachments, annotations, and draft state.

1. 1

   Select A2UI for the summary

   The host renderer can map a bounded summary, status labels, event rows, and ordinary next-step controls to approved native components. This is still a proposal until the exact host, renderer, catalog, and payload are tested.

2. 2

   Select an MCP App for the editor

   The product team needs direct control over dense layout, attachment handling, local drafts, filtering, and annotation behavior. The host must support the app resource, bridge, lifecycle, and required permissions.

3. 3

   Keep action policy outside both views

   The application decides whether a case may be escalated, who may send a response, and which system event proves completion. Neither the native button nor the embedded editor creates that authority.

4. 4

   Define the handoff

   Opening the editor must carry the case identity and current version without treating the A2UI view as the source of truth. On return, the summary must refresh from authoritative state instead of trusting an optimistic local message.

5. 5

   Specify fallback

   If A2UI is unsupported, show a structured read-only case result and the approved alternate route. If the editor resource is unavailable, preserve the summary and draft status without presenting edit or send controls.

6. 6

   Leave acceptance unresolved

   Expected behavior can be written now. Rendering, bridge behavior, permissions, recovery, accessibility, and completion remain pending until tested in every named host.

A visual system sits upstream of either route. For A2UI, the host can map semantic roles, typography, spacing, and component treatments into its native catalog. An MCP App can consume the same intent through its own CSS, tokens, and components. Shared visual input may reduce drift, but it doesn't erase the two rendering implementations or their separate verification work.

Ambient Sage is useful here because its public page exposes a coherent set of colors, typography, spacing, and usage direction. Its availability proves only that the source artifact can be inspected. It doesn't prove that an A2UI catalog maps those decisions, that an MCP App consumes them, that either route is accessible, or that a rendered surface is correct.

Choose one representative surface with a real user task. Name every required host, then complete the route decision record before implementation. Define the fallback and expected evidence at the same time. Expand the architecture only after you've observed that surface in every named host and traced its action outcomes to authoritative runtime evidence.

• A2UI + MCP Apps: Combining the best of declarative and custom agentic UIs: The Google A2UI Team and MCP Apps co-creators describe three combined patterns, including A2UI delivered over MCP and arrangements that nest one UI mechanism inside the other.
• MCP Apps vs A2UI: Which Agent UI Standard Should You Use? (October 2026): This comparison distinguishes renderer ownership, host UI support, validation, application responsibilities, testing, and fallback for unsupported clients.
• How Does A2UI Compare?: The first-party A2UI documentation distinguishes declarative native rendering from sandboxed MCP App resources, documents their combined use, and lists v0.9.1 as current and v1.0 as candidate.
• MCP Apps and A2UI: The Two Architectures That Will Define Generative UI for Enterprise AI Agents: The Workday engineering analysis highlights approval, permission, audit, governance, and side-effect questions that remain application responsibilities.
• A2UI vs MCP Apps: Choosing the Right Protocol: This December 2025 community comparison labels A2UI v0.8 as preview, providing a historical example of why protocol comparisons need dates and governing sources.
• Ambient Sage Design Kit: The published Ambient Sage kit exposes an inspectable visual system with semantic colors, typography, spacing, and usage direction, but does not establish compatibility with either UI protocol.