title: "静态界面的终结：构建意图驱动的 UX｜Gus Iwanaga 与 commercetools"
source_url: "https://www.youtube.com/watch?v=QrMcNe2jjt8"
author: "AI Engineer"
excerpt: "公共早报 Gus Iwanaga 说明，意图驱动的软件可通过声明式 UI、经策展的组件契约和明确的信息架构适应用户需求，同时不把产品与 UX 控制权交给不可预测的 LLM。"

Brief Description

Gus Iwanaga of commercetools explains why AI should move software beyond static screens without surrendering UX quality to unpredictable model output. Drawing on his team's experiments with generative UI, he compares controlled, open-ended, and declarative UI protocols, then describes the information architecture, component curation, and organizational changes required to make intent-driven interfaces useful in production.

Table of Contents

• From static software to intent-driven experiences

• Early generative UI experiments and their limits

• Three ways to render generative interfaces

• Declarative UI as a controlled middle ground

• Designing the system behind the interface

• Curation, teams, and the path forward

From static software to intent-driven experiences

Gus Iwanaga leads product, UX, and engineering for zero-to-one products at commercetools. He frames the talk as lessons from a team building generative UX and UI, rather than another discussion of agentic orchestration alone.

For decades, people have adapted to the software they ship rather than software adapting to people. GPT offered a glimpse of real personalization, but much of today's software remains static even as AI accelerates feature delivery. Users often need several SaaS applications to do everyday work, each with its own mental model and way of completing tasks. That accumulation transfers cognitive load to people instead of machines.

Screens in well-known CRM and enterprise applications illustrate the problem: dense information, many features, and complicated tables make it hard to know where to begin. Organizations also spend significant time onboarding people to navigate this complexity. As more applications arrive, users must repeatedly learn new logic and navigation patterns.

At an API-first company with more than 300 APIs, Iwanaga and his team asked what foundational changes AI could enable if software interaction were no longer static. That question led to the product he demonstrates.

Early generative UI experiments and their limits

An early prompt, "Create a sales report for Q1," generated an interface automatically from a guided component catalog. The AI chose the placement, information architecture, and components, but the resulting experience was not ready for production.

Different phrasings of the same request produced materially different interfaces. One version showed Q1 KPI cards for a named entity; another changed the period to January through March; others added more cards, text, and charts. The inconsistency was confusing. In a highly personalized experience, users cannot be expected to receive a different and potentially contradictory interface each time they prompt.

The team rejected those early versions. In a more mature demonstration, a campaign-planning request is handled through an orchestrator that extracts intent, locates first- and third-party tools or agents on MCP servers, gathers their outputs, and supplies context to a UX agent. The UX agent then renders a meaningful result. The improved interface is still AI-decided within guidance, but it has a more coherent look and feel and can be approved into a pre-production environment.

Three ways to render generative interfaces

The central choice is how much control a business wants over a non-deterministic experience. At one end is a controlled approach: the product ships opinionated components, the agent selects one from a catalog, and it renders exactly as described. A restaurant-finding interaction in ChatGPT illustrates this kind of strongly prescribed component. This approach can work well for businesses such as Booking, where the desired component and presentation can be tightly defined.

For configurable B2B SaaS, however, a fully prescriptive flow can preserve the very cognitive load customers want removed. At the other end is an open-ended approach, where an LLM has broad autonomy to compose the experience. Iwanaga shows Claude creating a three-level organization chart from a simple request. It can work well, but a company loses control over the output and outcome.

In the open-ended model, an MCP tool can ship HTML that is rendered in a sandboxed iframe in a chosen host, such as Claude, ChatGPT, Perplexity, or another chat environment. This provides flexibility, but giving full control to the LLM is a risk for teams that care about design, taste, and judgment.

Declarative UI as a controlled middle ground

commercetools chose a declarative approach between rigid control and full autonomy. Iwanaga cites protocols including A2UI from Google, JSON Render from Vercel, and OpenUI by Thesis as examples of this middle ground, while noting that their characteristics differ.

In the demonstrated product, a user enters a query and an orchestrator classifies its intent. Tools are invoked and data is retrieved. Eligible components from the catalog are mapped to entities returned by those tools. The orchestrator broadcasts a UI description---a UI specification---which is validated against the component catalog and its Zod schema, then rendered as native UI, in this case React components.

The result stays compliant with the design system across the product while allowing the system to adapt to user intent. That control matters not only for visual UI but also for copy and UX writing. A model that changes "Q1" into "January to March" changes the meaning of the experience; declarative constraints help keep these elements reliable.

Designing the system behind the interface

The first major challenge is information architecture. If an agent selects components, some entity must determine how to arrange them. Leaving placement unconstrained can produce random layouts that fail the average customer.

The team borrows the idea of atomic design, a methodology with five stages that creates interface systems in a deliberate hierarchy. They teach the UX agent what good looks like, what layout is optimal for a situation, and which templates are available. This encodes UX knowledge rather than leaving layout decisions wholly to the model.

Their hierarchy moves from page to layout, slots, sub-slots, and eligible component categories. A layout can contain headers and main areas; slots can contain nested sub-slots; and each sub-slot can restrict the categories of components it accepts. Although an orchestrator begins by retrieving eligible components for a user query, the system maps components to sub-slots, sub-slots to slots, and slots to templates so that the final page can be arranged appropriately.

Curation, teams, and the path forward

The second challenge is the design system and component catalog. Iwanaga calls the catalog the contract between the agent and the UI: every property matters. Layouts, slots, and sub-slots also have their own attributes. This curation is necessary to deliver a meaningful product rather than a demonstration that merely looks impressive.

The team continues to test protocols such as A2UI, JSON Render, and OpenUI, but sees curation as the mechanism that lets UX teams steer the experience. The work is not finished; placing retrieved components meaningfully remains difficult.

The third challenge is organizational. Teams are no longer designing every pixel or complete flow directly, because AI can influence both. The nature of product and UX work shifts toward schemas, catalog curation, rules, synthetic data, the queries that map to components, and interaction patterns. This affects non-technical product managers and UX designers as much as engineers.

For leaders beginning this journey, Iwanaga emphasizes three connected concerns: people, product, and process. The process can be lightweight, but it matters. He encourages the audience to explore the referenced AI Engineer talks and expects intent-driven UX to become increasingly important over time.