Google A2UI Express: Evaluate Streaming Before Switching Formats

In its October 27 announcement, Google describes A2UI as a protocol in which a client advertises a component catalog, an agent describes an interface using those components, and a renderer draws it. Previously, agents generated the JSON transport messages directly. Express adds an intermediate representation that SDK code translates into standard A2UI messages.

The separation matters because teams can change how a model expresses a screen without redesigning the component catalog or renderer. Google also describes support for custom inference formats, provided developers supply the relevant prompt generation and conversion logic. That creates room for experimentation, although maintaining another format would become the team’s responsibility.

Our editorial recommendation is to evaluate Express first on an existing interface. Keeping the catalog and renderer fixed makes it easier to determine whether differences come from the inference format.

Express uses assignments resembling Python: a component is assigned to a variable, and that variable becomes its component ID. Positional arguments map to properties in catalog order, an underscore skips an argument, and data paths bind values to the interface’s data model. The Express specification documents these syntax rules.

Google says the SDK derives both format instructions and compilation behavior from the catalog schema. This keeps the generated representation tied to the components the application provides. It does not establish that a valid screen answers the user’s request correctly. A permitted button can still have confusing text, and a valid layout can still omit information.

For a proposed pilot, use a familiar screen with a heading, a short list, and one action. Check the compiled messages, displayed values, and action behavior separately. Our guide to designing a reliable AI workflow provides a broader framework for defining those acceptance conditions.

The announcement explicitly says the Python and TypeScript SDKs can stream Direct JSON chunk by chunk, while they compile Express from the complete reply. A smaller response could finish generation sooner, but that alone does not establish when a user first sees a useful interface.

There is an important distinction between the sources. The Express specification lists streaming compatibility as a design goal and describes line-by-line parsing for progressive rendering. The dated announcement describes a narrower SDK implementation. Treat the specification’s capability as separate from demonstrated behavior in the SDK version you use; this article has not tested either path.

Our proposed evaluation should record two times: the first useful rendered content and the completed screen. Include a longer screen where waiting for the entire reply could be noticeable. If progressive display matters to the product, retain Direct JSON as a comparison until Express meets that requirement in an actual test.

Google claims Express can reduce latency by up to three times and requires up to three times fewer tokens than Direct JSON for the same kinds of interfaces. It says its comparison covered four formats across a 51-task evaluation using gemini-3.5-flash, with thinking enabled and disabled. These are vendor-reported findings, not measurements performed by NextAITime.

The announcement also says Express worked just as well with thinking disabled in its tests. That supports including the setting in an evaluation; it does not establish equivalent results for every model, catalog, or application. Changing both format and thinking settings at once would also make a result harder to interpret.

Start with the same model, catalog, requests, and thinking setting for both formats. Then evaluate thinking settings separately. Record output tokens, timing, compilation failures, and whether each screen satisfies the task. A faster response that needs correction should remain visible in the results.

The announcement also discusses controlled generation using Jev and the Apparite example project. In that approach, a decision model chooses among predefined layout options, code assembles components, and a separate model writes text. This changes how the screen is constructed beyond simply selecting Express.

Google explicitly says A2UI Agent SDKs do not yet include a decision-model inference format. It presents Apparite as an example and characterizes its small evaluation as an initial result. Teams should therefore avoid interpreting the announcement’s largest speed claims as results from switching an existing agent to Express.

For this article’s adoption decision, keep controlled generation outside the first pilot. It deserves separate consideration when an application’s screens already follow predictable structures and the team is prepared to maintain those definitions.

Build a small comparison set from real interface requirements: a short card, a longer list, missing data, an update to existing content, and an intentionally unsupported component request. These are proposed cases, not tests we performed. Record the SDK version and catalog alongside each result so later changes can be compared meaningfully.

Preserve failures as regression cases using the approach in our guide to regression tests for AI-generated code. Examine whether failures occur during generation, compilation, or rendering; treating them all as a bad model response would obscure the work needed.

Try Express when verbose interface generation is a concrete problem and complete-reply compilation fits the experience. Keep Direct JSON where progressive rendering already serves users well until a comparison supports changing it. The adoption threshold should be a usable screen delivered reliably, with timing measured at the interface.