Gus Iwanaga

Gus Iwanaga develops intent-driven interfaces: software that interprets a person's goal, coordinates tools, and assembles an interface around the resulting work. commercetools author biographies identify him as the founder and general manager of MosAIc, its AI orchestration product for commerce. In his recorded talk, he describes leading product, UX, and engineering for zero-to-one products at commercetools. His team's work addresses a practical design problem: how to make an adaptive interface coherent when a model can change what appears on screen with every request.

A commercetools author biography describes fifteen or more years across Google, Zalando, and elsewhere, and places him in Munich. His work on MosAIc brings that commerce background together with product development and interface design.

From SaaS navigation to intent-driven commerce

The project began with a question Iwanaga explored with commercetools' founder: how could AI fundamentally change the way people interact with software? He saw customers carrying the cognitive load of several SaaS applications, each with its own navigation, configuration, and ways of completing tasks. Connecting their underlying APIs did not by itself remove the need to learn those interfaces.

In writing with Dirk Hoerig, Iwanaga describes an operating model in which people express goals and receive an interface assembled around the work and decisions those goals require. The introduction of MosAIc presents that approach for commerce operations and states that a select group of customers was already using the product. His talk makes the mechanism concrete: an orchestrator classifies intent, locates first- and third-party tools, and retrieves their outputs. Those results provide context for selecting and presenting relevant interface components. He demonstrates campaign planning, while explicitly describing the demonstrated environment as pre-production.

Making adaptive interfaces coherent

Iwanaga's generative UX work developed through experiments he refused to ship. His team's early attempts produced four markedly different sales reports for the same Q1 request. One used Q1 labels; another used January-to-March wording. KPI cards, text, and charts accumulated in different arrangements. The problem was more than appearance: users would have to interpret a changing information hierarchy each time they repeated a familiar task.

• Declarative UI: The team chose declarative UI to constrain that variability. Iwanaga distinguishes three degrees of control: an agent can select an entirely prebuilt component, generate an unrestricted interface, or produce a structured interface description using an approved component catalog. His team chose the middle approach. Tool results map to eligible components, a UI specification describes the composition, and schema-defined native React components render it. Zod schemas specify component properties. This preserves the design system while allowing the model to adapt the presentation to the request.
• Layout hierarchy: That choice still leaves a difficult question: where should the selected components go? Iwanaga's team uses atomic-design principles and a hierarchy of layouts, slots, subslots, and eligible component categories. Because the orchestrator retrieves components first, the assembly process works upward: components map to subslots, subslots to slots, and slots to templates. The hierarchy encodes the team's UX judgment about suitable placement instead of leaving the model to arrange useful parts arbitrarily. Iwanaga describes layout as an ongoing challenge, rather than a solved consequence of adopting a UI protocol.
• Component catalog: The component catalog consequently becomes central to product quality. Component properties, layout attributes, and eligibility rules determine what the agent can assemble and where it can place it. His team continues testing interface protocols and curating those definitions. Iwanaga's position is that design judgment must remain active in the system: a model's ability to generate an attractive screen does not justify delegating the entire experience to it. The appropriate freedom depends on the product, particularly when a configurable B2B application must balance flexibility with understandable flows and consistent language.

How generative UX changes the team's craft

This approach also changes his team's craft. Product managers and UX designers increasingly work on schemas, catalog definitions, rules, interaction patterns, and synthetic queries that test how requests map to components. They specify the conditions under which an interface is assembled rather than drawing every screen and complete flow in advance. Iwanaga treats that transition as a leadership responsibility involving people, product, and a lightweight process. His team's contribution is to make design knowledge part of the machinery that generates the experience, while continuing to confront the variability that machinery introduces.