Skip to content
On this page

A2UI Version Status

Current A2UI production and candidate versions, compatibility boundaries, message changes, and migration guidance.

Updated: 8/6/2026 Reviewed by: HiA2UI Editorial Team Current through 2026-08-06

A2UI version status

This page is the canonical HiA2UI version guide. It separates the production protocol from candidate work so implementation advice does not accidentally present a draft as stable.

A layered protocol map showing legacy, production, and candidate A2UI generations connected by a controlled migration path

Status at a glance

VersionOfficial statusUse it for
v0.8LegacyMaintaining older clients and Gemini Enterprise integrations that still require v0.8
v0.9Previous stableExisting implementations already deployed on the v0.9 family
v0.9.1Current production releaseNew production work that needs the stable protocol family
v1.0CandidateEvaluation, prototyping, compatibility planning, and feedback—not an assumption of production stability

The authoritative status is maintained by the A2UI project and the canonical source repository at a2ui-project/a2ui.

What changed in v0.9.1

v0.9.1 is a compatibility-focused refinement of v0.9:

  • The media type is standardized as application/a2ui+json; application/json+a2ui is legacy.
  • A surfaceId only needs to be unique among active surfaces. An ID may be reused after its surface is deleted.
  • v0.9 and v0.9.1 payloads remain mutually compatible in the current schemas.

Use version negotiation at integration boundaries. A client advertising v0.8 support must not be sent v0.9 messages merely because the agent supports them.

Message model by version

v0.8

The legacy lifecycle uses:

  • surfaceUpdate
  • dataModelUpdate
  • beginRendering
  • deleteSurface

v0.9 and v0.9.1

The stable family uses:

  • createSurface
  • updateComponents
  • updateDataModel
  • deleteSurface

It also adds custom catalogs, client-side functions, modular schemas, validation errors, and renderer-to-agent data synchronization. See the message reference.

v1.0 candidate

The candidate adds capabilities that should be tested behind explicit version routing:

  • Synchronous action responses using actionId and actionResponse.
  • Agent-initiated renderer functions through callFunction and functionResponse.
  • Components and functions from multiple compatible catalogs in one surface.
  • Optional initial components and data in createSurface.
  • Catalog composition constraints through allowedParents and allowedChildren.
  • Clearer agent and renderer terminology in place of ambiguous server/client names.

The complete differences are documented in the official v1.0 evolution guide.

Production decision rule

  1. Start from what the target renderer actually supports.
  2. Prefer v0.9.1 for new production systems unless a host product requires v0.8.
  3. Route v1.0 into a separate compatibility path until the candidate becomes stable.
  4. Keep catalogs versioned and validate every received message before rendering.
  5. Preserve a text fallback when no compatible A2UI version is negotiated.

Known product boundary

Gemini Enterprise currently documents A2UI v0.8 support for registered A2A agents. That is a host-product constraint, not evidence that the overall protocol is still v0.8. Review the Google product integration guide before deployment.

Source policy

Version claims on HiA2UI are derived from the official specification, evolution guides, package registries, and merged upstream changes. Candidate behavior is labelled candidate. Community implementations are labelled community-maintained.