Catalog Beats Canvas: A Realistic Look at Generative UI
Nov 2026A2UI, the three flavors of generative interfaces, and why I think the controlled kind wins for brand-heavy commerce.
Why this is on my mind
"Generative UI" gets used to mean at least three different things, and mixing them up is how teams end up building the wrong one. I'm building for fashion and creative commerce, where brand consistency is non-negotiable, so I care which kind is realistic.
What's true right now
There's an emerging standard. Google released A2UI (Agent-to-User Interface) as an open protocol under the Apache 2.0 license. The core design choice is that the agent sends data, not code: a JSON description of the interface it wants, which the host app renders with its own native components. Google contrasts this with approaches that treat UI as a prefab HTML resource in a sandbox. The announcement noted use in Google's Opal mini-app platform and Gemini Enterprise, a Flutter GenUI SDK, and day-one support from the AG-UI and CopilotKit teams. Agents pick from component catalogs that are already approved. An early hands-on write-up described progressive rendering as components stream in, and noted the protocol was still at v0.8 then.
It's already shipping in consumer products. One agency overview says Google now ships generative interfaces inside Gemini and Search, and separates design-time generation (AI drafts screens for humans to ship) from runtime generation (the interface is assembled live per request).
It's not one thing. A 2026 breakdown describes three patterns: controlled, A2UI-style declarative, and open-ended. The open-ended kind requires sandboxed execution and an explicit security model and is best suited to prototyping, power-user tools, or products where the generative interface is the core value.
The practical advice is about components. A developer who has shipped it says the framework matters less than the discipline you bring to the components: a generated form may arrive with partial information already gathered, so components need strong defaults.
Three kinds, three different jobs
My opinion, a way to keep the three apart.
Controlled. The product decides almost everything, and the model fills in content. This is the safest and the easiest to test, and it is the least surprising to the user. For a brand that cannot afford a mistake, this is where I would begin, even though it feels the least exciting. The trade-off is control against range. The more of the interface the product fixes in advance, the less surprising it is, and the less the model can do for a user with an unusual request.
Declarative and open-ended. Declarative sits in the middle: the model chooses and arranges approved pieces. Open-ended gives the model the most freedom and asks the most of your security model. The useful habit is to name which one a team means before the project starts, because the three need very different safeguards. I would not treat them as a ladder where everyone eventually climbs to the top. They are different tools, and a single product could reasonably use more than one in different places.
A worked example from a commerce flow
Illustrative: my own sketch, not a sourced fact.
Imagine a user asks to compare two jackets. With a catalog, the model might compose a comparison card, a size selector, and a short note. Each of those exists already, with brand styling, accessibility, and validation built in. The model only decides which to show and in what order. That is the whole appeal for a brand-heavy product. The expensive and risky parts, like validation and styling, were settled earlier by people, so the model's choices stay inside a space that was already checked.
Now imagine the request does not fit. Someone asks for something no component can express. A catalog system needs a fallback here, such as a plain text answer or a hand-off to a human-designed screen. I would design that fallback first, because it is the moment people will actually notice. It also tells you what to measure. The number of requests the catalog cannot express is a direct signal about what is missing, and it is far more useful than a general sense that the output feels fine.
My hypothesis
This section is my opinion, not a sourced fact.
For brand-heavy, transaction-heavy products like commerce, controlled and declarative generative UI will dominate; open-ended generation will stay in prototyping and power-user tools.
Reasoning: commerce interfaces have to be on-brand, accessible, and safe around money and personal data. A model that picks from a catalog of approved components can't produce an off-brand checkout or a payment form that skips validation. A model that writes arbitrary interface code can. The catalog also gives you the one thing open-ended generation can't: something to test.
That makes the design work mostly about the catalog. Which components exist, how they combine, and what the fallbacks look like when the model's request doesn't fit any of them.
How I'd test it
Build a small catalog of eight components for one flow. Let a model compose them in response to 30 realistic requests. Count requests the catalog couldn't express (catalog gaps) and compositions that were valid but poor (catalog design problems). Those two numbers tell you what to build next.
What would change my mind
If open-ended generation becomes safe enough in practice (reliable sandboxes, strong automated brand checks), the quality ceiling might favor it, and the catalog could become a starting point instead of a boundary.
What I would do first on a real product
My opinion, a suggested starting order.
Write the catalog on paper. Before any model is involved, I would list the components, what each one needs, and what a sensible default looks like. Since a generated form may arrive with partial information, defaults are not a nice extra. They are what keeps the half-filled version usable. Defaults deserve more attention than they usually get. They decide what the user sees when the model supplies only half of what the component needs, which will happen more often than the demo suggests.
Then decide what happens when nothing fits. I would agree a fallback with the team early and treat it as a real screen with real design work, not an error message added at the end. If that screen is good, the rest of the system can afford to be a bit imperfect. It also keeps expectations honest for the people around the project. Everyone can see the boundary of what the system will do, and a clear boundary is easier to improve than an open-ended promise.
References
- The Decoder, Google's open standard lets AI agents build user interfaces on the fly
- Analytics Vidhya, Google A2UI Explained
- HackerNoon, Chat Is a Terrible Interface for Agents, and 2026 Will Prove It
- Lazarev.agency, 6 generative UI design patterns behind real products
- mer.vin, Generative UI in 2026: Controlled, A2UI Declarative, and Open-Ended Patterns on AG-UI
- Alex Cloudstar, Generative UI in 2026: What Actually Works for Developers