Google Adds A2UI Express and Shows a Separate Decision-Model Path

Google's October 27 A2UI update changes what an agent must generate to describe a user interface. Instead of making a language model write the final nested JSON transport message directly, an agent can produce A2UI Express, an intermediate format that an SDK compiles deterministically into standard A2UI messages. The client still advertises a catalog of allowed components, and the renderer still receives the regular protocol. A format can only refer to components and properties in that catalog because its prompt instructions and compiler are derived from the same schema. This is a change in the inference format, not a new unrestricted power to draw arbitrary controls.

Google says Express uses up to three times fewer output tokens for comparable screens than Direct JSON and can reduce latency by up to three times in its tests. The post describes a 51-task comparison across Direct JSON, Express and two other candidate syntaxes with Gemini 3.5 Flash and different thinking settings. “Up to” numbers name a favorable observed case; they are not a promise for every model, screen or network. Express writes compact statements with positional properties and IDs, and the SDK converts them to validated messages. That conversion may reduce syntax failures, but application correctness still depends on the component catalog, data binding and the agent's choice of layout.

The format is available through the Python, TypeScript and Dart A2UI agent SDKs described in the post. Python and TypeScript can stream Direct JSON in chunks; Express is compiled after the complete model reply. Macros in the Python SDK can fetch existing application data when the model supplies an identifier, so a screen need not depend on the model inventing every displayed value. These implementation details affect when the first usable screen appears and how trusted business data gets into it. A developer comparing formats should measure both generation time and the time until the renderer has validated, useful components.

Google also describes a different path for screens whose structure is known in advance. The example Apparite project asks the Jev decision model typed layout questions, lets code build a component tree, and uses a smaller model only for text. In one 11-prompt run, the component tree appeared in 92 to 298 milliseconds and complete screens in 0.8 to 1.7 seconds. Google says decision-model layouts can be up to 80 times faster, but that applies to constrained layouts defined ahead of time. Apparite's grammar covers nine screen archetypes and twelve blocks. Its sample is small, and the A2UI Agent SDKs do not yet include a decision-model inference format. It would be inaccurate to attribute that path's results to Express itself.

The selection rule is therefore about scope. Use a constrained decision path when the product already knows the possible screen shapes, and use Express when the agent needs more flexibility within the approved component catalog. A team can also define its own inference syntax and compiler while preserving the transport and renderer. The useful engineering question is whether faster generation preserves valid components, correct data and interaction behavior on the team's real tasks. Google's published figures are vendor measurements and an illustrative project, not an independent cross-product benchmark.