Google's A2UI gets swappable inference formats to cut generative UI latency
Google has added swappable inference formats to A2UI, its protocol for generative user interfaces, and made a new format called A2UI Express the default. According to Google, Express can reduce latency by up to 3x compared with generating JSON directly, and pairing A2UI with decision models such as Jev can push that to up to 80x.
- Google's A2UI now supports swappable inference formats, set with one argument when creating the generator.
- A2UI Express is the new default and, per Google, cuts latency by up to 3x and needs up to 3x fewer tokens than Direct JSON.
- Decision models like Jev from TypeSafe can raise the speedup to up to 80x for screens with known layouts.
- Express is available in the Python, TypeScript and Dart agent SDKs.
- Google tested four formats on a 51-task eval with gemini-3.5-flash and says Express performs just as well with thinking off.
Why Google changed how A2UI agents generate screens
A2UI is a protocol in which a client advertises a catalog of trusted components, an agent sends messages describing a custom interface built from that catalog, and the client's renderer draws it. According to the Google A2UI team, developers had raised concerns about speed, because users wait while the model generates each screen.
The team says the original approach was part of the problem. Agents initially produced A2UI JSON transport messages directly, and generating JSON trees constrained by a complex schema turned out to be slow and error-prone for LLMs. It also tied A2UI to models that output text, which made it hard to integrate faster decision models that Google calls System One models.
The new release separates what the model writes from what goes over the wire. Agents can now generate an intermediate format, and deterministic code in the A2UI Agent SDKs translates it into the JSON-based transport protocol. Builders can also plug in another DSL and its compiler for special cases.
How swappable formats and A2UI Express work
The format a model generates is called the inference_format, and it is set with one argument when the generator is created. According to Google, each format has two parts, both produced by the SDK from the catalog's JSON schema: a prompt section that teaches the model the syntax, and a compiler that turns the reply into validated A2UI messages. Because both derive from the schema, a format cannot describe a component or property the catalog lacks.
A2UI Express writes one statement per line, in a style close to Python. Each line assigns a component to a variable, and that variable name becomes the component ID. Arguments are positional and mapped to property names in the order the catalog schema declares them. Google says Express needs up to 3x fewer tokens than Direct JSON to generate the same kinds of UI.
Google tested four formats: Direct JSON, Express, Atom (Lisp-style S-expressions) and Elemental (HTML with custom elements). All four ran through the same 51-task eval on gemini-3.5-flash, with thinking mode on and off. Google reports that Express works just as well with thinking off, which gives the fastest inference times.
Express is available in the Python agent SDK (a2ui-agent-sdk 0.9.0 on PyPI), the TypeScript agent SDK (@a2ui/agent on npm) and the Dart SDK (a2ui_agent 0.0.1-wip004 on pub.dev). The Python and TypeScript SDKs can stream Direct JSON chunk by chunk, but they compile Express from the complete reply. In the Python SDK, formats also work with macros: the model writes a call such as OrderStatus("ord_42"), and the developer's macro fetches the order and fills in the values from existing data.
Decision models for screens with a known shape
For screens such as settings pages, checkouts or confirmations, Google argues the model does not need to design a layout, only choose among layouts defined in advance. For that, the post points to Jev from TypeSafe, a System One model that does not generate text or JSON. Developers send it a state and a set of typed questions, and it answers each with calibrated probabilities. Question types include whether a statement is true (Noul), which option fits (Choice) and how something scores on a rubric (Score). According to the post, Jev answers many questions in one request in roughly 100 to 300 ms.
The open-source design tool Apparite (jev2ui) shows one way to connect such a model to A2UI. Jev decides the structure of each screen, code builds the A2UI components from those decisions, and gemini-3.5-flash-lite writes only the text. The questions live in a Markdown grammar written ahead of time, where a blockquote asks a question and bullets list the options with criteria.
Apparite builds a screen in steps. One Jev request answers the grammar's layout questions, about 30 for a screen. Code then builds the component tree from the catalog and sends createSurface and updateComponents at about 200 ms, with placeholders where text will go. Next, gemini-3.5-flash-lite streams the text into updateDataModel, and small follow-up Jev requests settle details that depend on it. On a podcast app's settings screen, Jev classified Skip forward as a value row, Auto-download as a switch and Log out as a danger action, each at p ≈ 1.00.
What it means for developers
Google frames the release as a set of levers, so teams can choose the trade-off that fits each screen. Open-ended screens can use Express for faster, cheaper generation, while predictable screens can lean on a decision model for the largest speedups Google cites. Teams that need a different syntax can bring their own DSL and compiler, and the Agent SDKs keep it compatible with transports and renderers.
Google for Developers: Fast, reliable A2UI, with swappable inference formats- Google Developers Blog
