A2UI v0.9.1 in Production and the v1.0 Candidate: A Migration Guide
A sourced guide to the current A2UI v0.9.1 production line, the v1.0 candidate, compatibility boundaries, and upgrade decisions.
The practical A2UI decision in August 2026 is not “latest versus old.” It is a three-way compatibility decision: legacy v0.8, production v0.9.1, and the v1.0 candidate. Treating those lines as interchangeable can break negotiation, message parsing, renderer state, and product integrations.
The production baseline
v0.9.1 is the current production-oriented release. It standardizes the media type as application/a2ui+json and clarifies that a surfaceId must be unique only while its surface is active. v0.9 and v0.9.1 remain compatible within the stable family.
The lifecycle differs from v0.8. Production v0.9.1 uses createSurface, updateComponents, updateDataModel, and deleteSurface; v0.8 used surfaceUpdate, dataModelUpdate, beginRendering, and deleteSurface. The exact envelope must be selected through version negotiation, not inferred from a component payload.
What the v1.0 candidate changes
The candidate is more than a naming pass. It explores synchronous actionResponse messages tied to actionId, renderer function calls through callFunction and functionResponse, and surfaces that can combine compatible catalogs. createSurface may also carry initial components and data, reducing lifecycle round trips.
Catalog composition becomes more explicit through parent and child constraints. Terminology shifts toward “agent” and “renderer,” which better describes deployments where neither side maps cleanly to server and client.
These features are useful, but candidate status matters: schemas and migration details may still change. Keep v1.0 experiments behind a converter or isolated transport route.
A safe migration sequence
- Inventory every host, agent, renderer, catalog, stored transcript, and test fixture by protocol version.
- Pin the renderer and schema artifacts; avoid a floating dependency at the protocol boundary.
- Add explicit version negotiation and a text fallback.
- Convert envelopes at one boundary rather than spreading version checks through product components.
- Test partial streams, duplicate delivery, invalid paths, stale actions, deletion, and ID reuse.
- Roll out by host capability, with telemetry for validation failures and unsupported catalogs.
Gemini Enterprise currently documents a v0.8 boundary for registered A2A agents. That product constraint does not redefine the overall protocol status. See our Google product compatibility guide and version reference.
Production judgment
Use v0.9.1 for new work when the host and renderer support it. Maintain v0.8 only at an integration boundary that requires it. Evaluate v1.0 for architecture feedback and future migration, not as an unstated production dependency.
Version choice does not replace security work. Validate the exact schema, allowlist catalogs, constrain resource use, sanitize URLs, authorize actions on the server, and preserve an accessible fallback. The production checklist turns those requirements into an implementation review.
Frequently asked questions
Is A2UI v1.0 stable for production?
No. It is a candidate design and should remain behind explicit version routing until the upstream project marks it stable.
Which version should a new production implementation use?
Prefer v0.9.1 unless the target host product requires v0.8; verify renderer and host compatibility before deployment.