Generative UX becomes unreliable when a model chooses freely from a component catalog and composes the whole interface.
2
Gus Iwanaga's team uses an orchestrator that classifies intent, invokes tools, maps results to eligible components, and broadcasts a UI specification rendered as native components.
3
The component catalog and layout hierarchy become contracts that encode the design system and the team's UX knowledge for the agent.
Summary
Gus Iwanaga argues that software still makes people adapt to its fixed interfaces, even though AI can generate more personalized experiences. He demonstrates why unconstrained generative UX is difficult to ship: the same sales-report request produced different KPI cards, charts, text, and date ranges on four attempts. His team chose a middle path between fixed components and fully generated HTML. An orchestrator classifies intent, calls tools, maps their results to approved components, and sends a UI specification that renders as native React components against schemas. This preserves control over the design system and copy while allowing the interface to respond to the user's request. The remaining problem is arrangement. The team uses atomic design, templates, slots, sub-slots, and component categories to teach the UX agent how to place what the orchestrator selects. Iwanaga is also direct about the organizational change: designers and product managers now work on schemas, catalog curation, rules, synthetic data, queries, and interaction patterns rather than designing every pixel.
Software still makes users learn each product's mental model
Iwanaga says people have spent about 40 years adapting themselves to static software. Users often work across several SaaS applications, each with its own logic and way to complete tasks. The cognitive load that software was meant to remove remains with the user. He shows screens from familiar applications that contain dense information, many features, and complicated tables. Each product also requires onboarding because users must learn where to browse, how to navigate, and how work gets done. His question is whether AI can change this pattern so the interface adapts to the user's intent instead.
An unconstrained model produced four unusable versions of one report
The first product experiment asked an AI system to create a sales report for Q1 while allowing it to decide the information architecture and retrieve components from a catalog. Four versions of the same request looked different. One used Q1 and KPI cards, another changed the period to January and March, and later versions added different combinations of text, charts, and cards. Iwanaga rejected the result for production because repeated prompts created confusion rather than a useful personalized experience. He treats this as a product and system-design problem caused by giving the model too much compositional freedom.
The orchestrator turns intent and tool results into a controlled interface
The current system begins with an orchestrator that extracts the intent from a user's query. It finds the relevant tools, which may be first-party tools, third-party tools, or agents on MCP servers. Their combined outputs provide the context for a UX agent to render a useful experience. In the campaign-planning demo, the resulting interface looks more coherent than the earlier report experiment. Iwanaga stresses that AI still makes the decisions, but the team guides those decisions. The system can approve the generated result and make it live in a pre-production environment.
The amount of control determines how much of the interface the model can change
Iwanaga describes three rendering approaches along a control spectrum. With an opinionated component, the company ships the component and the agent chooses when to display it. The component renders exactly as specified, which fits a business with a small number of established flows. At the open-ended end, the model can produce HTML that renders inside a sandboxed iframe. He demonstrates an org chart created by Claude, but says a company may not want to ship an output it cannot predict or control. His own UX judgment favors retaining control over the experience.
Declarative UI keeps generated experiences inside the design system
The team's chosen approach is declarative UI, which sits between fixed components and fully generated markup. The user query goes through intent classification, tool invocation, data retrieval, and a mapping step that connects tool entities to eligible catalog components. The orchestrator then broadcasts a UI description, or UI spec. A component catalog and Zod schema constrain the description, and the result renders as native React components. This gives the team a less deterministic interface while keeping it compliant with the design system. It also gives them more control over copy, so a Q1 request does not randomly become January through March.
Selecting components does not solve information architecture
Even after the orchestrator selects eligible components, the system still has to decide where they belong. Iwanaga calls this an information architecture problem because random placement can make the result unusable. His team teaches a UX agent what good layouts look like and maintains a catalog of templates. Their hierarchy moves from a page layout to slots, sub-slots, and eligible component categories. The layout gives the team a way to steer placement for a particular situation instead of asking the model to invent the whole page structure from scratch.
The team inverts atomic design so selected components can find their place
The team borrows atomic design and changes the direction of the normal hierarchy for orchestration. Instead of starting with a template and filling it downward, the selected components map upward to sub-slots, sub-slots map to slots, and slots map to templates. This lets the system arrange the components returned by the orchestrator. Iwanaga says the approach remains a challenge, but it gives the UX agent a codified structure for choosing an appropriate layout. The system is therefore using UX knowledge as rules and relationships that the agent can apply repeatedly.
The component catalog becomes the contract between the agent and the UI
Iwanaga calls the design system and component catalog the heartbeat of the system. The catalog is the contract between the agent and the interface, so every property matters. Layouts also have attributes for their components, slots, and sub-slots. The team has to curate these definitions and test UI protocols such as ATUI, JSON Render, and OpenUI. Curation determines whether the generated result is meaningful rather than a demo that works only for one example. This is where the company preserves control over how the product looks and behaves.
UX and product work shifts from pixels to schemas, rules, and interaction patterns
Iwanaga says his teams no longer design the entire flow pixel by pixel. AI can dictate much of the resulting flow, so the work now includes defining schemas, curating the catalog, writing rules, generating synthetic data, producing queries that map to components, and specifying interaction patterns. This change affected non-technical product managers and UX designers as well as engineers. He frames the adoption problem around people, product, and process. The technical system can work, but teams still need a lightweight way to organize the new responsibilities.
"We're still adapting to the software that we ship, not the other way around."02:31
Who should watch
You are building an AI interface that chooses components or layouts and need to decide how much control to give the model.
Your product has a large component catalog, many configuration paths, or strict requirements for copy and design-system compliance.
You lead UX or product work and need to understand how schemas, catalog curation, rules, and synthetic data change the team's responsibilities.
