The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools
Description
Gus Iwanaga opens by disowning his own session title, then shows the demo that did not work. His team asked their system for a sales report for Q1 four times over. It returned four different layouts: different KPI cards, different charts, different amounts of text, and copy that drifted from Q1 in one run to January and March in another. He would not ship it. None of that was a model failure. It was the consequence of handing a model a component catalog and asking it to compose the experience, which is precisely what his team had done. The rest is what they built instead, at a company carrying more than 300 APIs. He lays the choices out as a spectrum of control. At one end you ship a fixed component and the agent only decides when to show it, which suits an opinionated flow. At the other the model emits markup that renders inside a sandboxed frame, which he demonstrates working and then declines to ship, on the grounds that a business cannot control what it cannot predict. His team took the middle. An orchestrator classifies intent, calls tools, maps the results onto eligible components, and broadcasts a UI spec that renders as native components against a schema, so the output obeys the design system every time. Two problems stay unsolved and he says so. Something must still arrange whatever the agent selected, which his team addressed by teaching it atomic design and inverting the hierarchy to run from components upward. And the catalog becomes the contract between agent and interface, so every property in it matters. Speaker info: - https://x.com/guhgoi - https://www.linkedin.com/in/gus-iwanaga/ Timestamps: 0:00 - Changing the title, and what he wanted to talk about instead 2:26 - Forty years of adapting ourselves to the software 3:35 - Three interfaces, and what onboarding people to them costs 5:54 - The question that started it, at an API first company 7:00 - The failure demo: one query, four different layouts 9:20 - How the orchestrator works now 11:35 - Con
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: Generative UX should not mean letting an LLM freely invent screens; it requires a declarative UI contract, a curated component and layout system, and an orchestrator that translates user intent into governed native interfaces.
- Why it matters: This is a concrete control-plane pattern for turning agent outputs into usable product experiences without sacrificing design-system compliance, information architecture, copy consistency, or operational trust.
- Best use: Use it as an architecture and product-design briefing for any agentic interface: extract its component-contract, layout-constraint, and team-operating-model patterns rather than treating it as a protocol-selection tutorial.
Executive Summary
Gus Iwanaga argues that conventional SaaS has accumulated cognitive debt: users must learn many static applications, each with its own navigation and mental model, while onboarding costs rise with product complexity. AI creates an opportunity to replace fixed screens with interfaces assembled around a user’s present intent—but only if the resulting UI remains coherent and trustworthy.
Commercetools’ early experiments exposed the failure mode. The same request, “create a sales report for Q1,” produced materially inconsistent screens: changing date interpretations, differing KPI sets, excessive charts and text, and arbitrary layouts. The speaker’s conclusion is that raw model-driven composition is not production-grade generative UX, even when each individual output appears plausible.
Their current pattern is an intent-to-interface pipeline: an orchestrator classifies the request, invokes relevant first- or third-party tools or agents, gathers data and context, maps available components to the resulting entities, and sends a constrained UI description to render native React components. The key design choice is declarative UI: more flexible than selecting a completely fixed component, but much more governed than allowing an LLM to emit arbitrary HTML.
The operational lesson is that generative UX moves design work upstream. Teams no longer primarily design every pixel or linear flow; they curate schemas, component catalogs, templates, layout-slot rules, interaction patterns, test queries, and synthetic data. The design system becomes the contract between agents and the product UI, while UX knowledge must be encoded into the system rather than left to model taste.
Key Takeaways
- Claim: The central opportunity is to shift enterprise software from static, application-specific workflows toward interfaces assembled around the user’s immediate intent. | Evidence: Iwanaga contrasts familiar CRM, tabular, and enterprise-product screens that present dense feature sets and distinct mental models; he says customers must learn multiple SaaS applications and companies must invest substantially in onboarding because of this accumulated complexity. | Implication: For agent products, the unit of experience should increasingly be an intent-specific task surface rather than a predetermined page hierarchy. | Caveat: The speaker presents this as a product direction and mental model, not as evidence that static navigation can be eliminated for every workflow.
- Claim: Unconstrained LLM-generated screens are unsuitable for production because repeated prompts can yield inconsistent information architecture, content, and scope. | Evidence: Early versions of the same “create a sales report for Q1” request rendered four different variants, including one labeled with an unclear entity, one changing the timeframe to January–March, and others adding differing combinations of KPI cards, prose, and charts. | Implication: Evaluate generative UI on consistency across repeated and paraphrased requests, not merely whether a single demo output looks polished. | Caveat: The outputs were experimental product iterations; they demonstrate a class of reliability problem rather than a benchmark comparison across models.
- Claim: A declarative UI protocol is the preferred middle ground between deterministic component selection and fully open-ended LLM rendering. | Evidence: The talk distinguishes: controlled rendering, where an agent selects a pre-shipped component; open-ended rendering, where an MCP tool can deliver HTML into a sandboxed iframe; and declarative rendering, citing Google’s H2UI, Vercel’s JSON Render, and Thesis’s OpenUI as examples of the middle approach. | Implication: Choose the degree of model autonomy based on business risk: use strict fixed components where predictability is paramount, and use declarative specifications where adaptive composition is valuable but brand and UX governance must remain intact. | Caveat: Protocol names are examples under active evaluation, not a recommendation that one is universally best.
- Claim: The production pipeline should separate intent/tool orchestration from UI generation and render a constrained UI specification into native components. | Evidence: In Commercetools’ described flow, the user query is intent-classified; the orchestrator locates first- or third-party tools, potentially including agents on MCP servers; returned data provides context; eligible catalog components are mapped to tool entities; and the orchestrator broadcasts a UI description that renders as native React UI. | Implication: Treat the UI agent as a downstream consumer of governed task context and component eligibility—not as an autonomous system that decides both business actions and arbitrary presentation.
- Claim: Information architecture must be explicitly encoded, because choosing valid components does not determine where they belong or what hierarchy they should have. | Evidence: The team uses Atomic Design and a hierarchy of page/template, layout, slots, sub-slots, and eligible component categories. The orchestrator retrieves components first, then maps components upward through sub-slots and slots to templates to steer their placement. | Implication: A component registry alone is insufficient; an agentic UI platform needs a machine-readable layout grammar and placement constraints to prevent random or overloaded compositions. | Caveat: Iwanaga calls this an ongoing, difficult challenge rather than a solved layout-planning system.
- Claim: The design system and component catalog become the formal contract between the agent and the interface. | Evidence: The declarative system uses a component catalog with Zod schemas; the speaker stresses that every component property and every layout, slot, and sub-slot attribute matters. The approach is intended to preserve design-system compliance across generated experiences. | Implication: Invest in typed schemas, semantic component metadata, eligibility rules, and versioned layout primitives before attempting broad generative UI rollout.
- Claim: Generative UX changes the work of PMs and designers from drawing fixed flows to curating the rules, data, and evaluations that guide AI composition. | Evidence: Iwanaga says his teams no longer “design the pixel” in the same way; their work now includes schemas, catalog curation, rules, synthetic data, generating queries that map to components, mapping logic, and interaction patterns. He frames adoption through “people, product, and process.” | Implication: Plan generative UI as an operating-model change: give product and design teams ownership of structured interface knowledge and evaluation assets, not just prompt-writing responsibilities. | Caveat: The talk does not provide adoption metrics, staffing ratios, or a detailed change-management plan.
Detailed Brief
Protocol trade-off: control versus autonomy
- Claims: The speaker frames protocol choice primarily as a control decision, not as a purely technical implementation choice.; A controlled approach lets an agent select from predefined components and display them exactly as authored.; An open-ended approach maximizes flexibility but asks the organization to accept outcomes it cannot reliably govern.; The declarative approach permits AI to compose from available UI building blocks while retaining a native, design-system-conformant rendering layer.
- Evidence: For an open-ended example, Claude is asked to create a three-level organization chart and directly renders a diagram.; The open-ended MCP pattern described can ship HTML and render it within a sandboxed iframe in hosts such as chat applications.; The speaker notes that a highly standardized consumer task, such as a booking-like experience, can fit the controlled component-selection model well.
- Caveats: The transcript does not cover protocol maturity, interoperability limitations, security boundaries beyond the iframe reference, or how schemas are validated against malicious or erroneous agent outputs.; Declarative constraints improve control but do not remove non-determinism; the model may still make poor composition decisions within the allowed grammar.
- Implications: Define an explicit autonomy policy per workflow: specify which presentation decisions are fixed, which may be selected from a catalog, and which—if any—may be generated freely.; Keep the rendering host responsible for validation and native rendering rather than trusting tool-delivered markup as the default.
What must be operationalized beyond the demo
- Claims: The speaker differentiates a meaningful production experience from a generative-UI demo by the depth of catalog and layout curation behind it.; The system’s quality depends on making UX judgment reusable as templates, placement rules, schemas, and interaction patterns.
- Evidence: Commercetools is API-first with more than 300 APIs, making intent-driven tool selection and cross-domain composition a practical product problem.; The demonstrated campaign-planning flow is described as live in pre-production after the team rejected earlier, visibly inconsistent designs.
- Caveats: No latency, cost, success-rate, accessibility, user-trust, or task-completion measurements are disclosed.; The presentation does not explain approval, rollback, or audit mechanisms for generated interfaces that trigger consequential actions.
- Implications: Before scaling, establish evaluation suites covering repeated-prompt consistency, correct data-to-component mapping, layout validity, copy accuracy, accessibility, and task completion.; For consequential workflows, treat a polished generated screen as insufficient evidence of safety; require observability around tool calls, provenance, validation failures, and user approvals.
Notable Concepts & Terms
- Generative UX/UI: An interface assembled dynamically from a user’s intent and available task context rather than delivered as a fully static, predesigned screen.
- Declarative UI: The speaker’s preferred middle layer: an agent emits a constrained UI description/specification that is rendered by the product’s native component system.
- Controlled rendering: An agent selects an existing, opinionated component that renders exactly as the organization authored it; this maximizes predictability.
- Open-ended rendering: An LLM is given broad freedom to generate the interface, potentially including HTML rendered in a sandboxed host; this maximizes autonomy but reduces governance.
- UI protocol: The contract and transport format through which an agent describes an interface for a host to render; examples named are H2UI, JSON Render, and OpenUI.
- Component catalog: A typed inventory of eligible UI components and their properties that serves as the contract between AI decision-making and the product interface.
- Atomic Design: A hierarchical design-system methodology adapted here to guide composition from layouts and slots down to eligible components.
- Layout → slots → sub-slots → components: The team’s machine-readable information-architecture hierarchy for steering where agent-selected components may appear.
Operator Notes / Why Ken Should Care
- Define a reference architecture in which task orchestration, data/tool execution, UI-spec generation, schema validation, and native rendering are distinct layers with auditable interfaces.
- Create a structured component inventory that includes schema, semantic purpose, required data, allowed actions, eligibility conditions, and placement constraints—not merely visual component names.
- Build a regression set of identical and paraphrased user intents; score generated interfaces for scope consistency, data correctness, layout validity, copy consistency, and component appropriateness.
- Decide where free-form UI generation is prohibited. For operational or high-trust workflows, default to declarative specs and host-controlled rendering rather than model-generated HTML.
- Assign design and product ownership for template curation, layout grammar, interaction policies, and synthetic evaluation data; do not frame this as an engineering-only agent initiative.
- Monitor protocol maturity and validation/security models for H2UI, JSON Render, and OpenUI before standardizing on one.
Source/Metadata
- Title: The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools
- Transcript words: 4105
- Duration seconds: 1398
- Timestamp note: No usable timestamps or chapters were present in the supplied transcript; the ending also contains repeated/corrupted extraction text.
Transcript
Reviewer. How's it going? The end of the conference. How is everybody feeling? Tired, drinking from the fire hose as well? Are you guys a little bit tired of hearing loop engineering, harness engineering, software factory, pre-training, post-training data, and whatnot? But anyway, those topics were more than valid, right? Hi. Some really common faces here. By the way, I'm super excited to be here and talk to you guys about this title. And I'm sorry. When I submitted the application, I was thinking of potentially a catchy title, but I don't like this at all. So, with all the respect to the organizers, I'll have to make a change. And the actual topic that I want to focus on here today is lessons learned from a team that is building proper generative UX and UI. And I was going to touch on agentic orchestration, but come on. Over the last three days, this is what we heard all the time. So, I'd rather focus on what I didn't hear enough about here at the conference. And hopefully, you walk away, if not with something very tangible, with a new mental model that can spark meaningful discussions down the road. Sounds good? All right. Very good. So, hi, everybody. I'm Gus. I'm a general manager at Commerce Tools. I lead product UX and engineering for 0 to 1 products. I tell people I'm in a very privileged position because we get to build really cool stuff. So, we cook really interesting stuff at Commerce Tools. Fantastic. And this is what you guys can expect, at least during the presentation. I'd like to make sure that we're on the same page with respect to the problem space, followed by a quick demo of the product, because I'm not sure if you guys agree, an image speaks more than 1,000 words. So, it would just make it more tangible for everybody here. Followed by a rapid discussion on the emergence of UI protocols. And I'm not sure if you guys joined some of the talks here. Even the founder of some of these protocols was here this week. And that was really cool. Followed by, last but not least, the challenges that my team and I faced, and we still face, and some of the mitigation tactics that we put in place to overcome some of these challenges. So, with that, let's continue. The problem space. This is more like a statement. And we still adapt to the software that we ship, not the other way around. Right? And then, although you could argue when GPT came out, this was November 2022, we had a really good glimpse of real personalization, but everything else remained static. And even with AI, we keep shipping a lot of stuff much faster, but to a significant extent, it is still static. And my question is, why? So, over the last 40 years, we kept shipping static experiences. And if I put myself in the shoes of some of my customers, they need several SaaS applications for the day-to-day work, each with its own mental model and its own way to get anything done. And over time, it just kept getting worse, just accruing debt. The cognitive load that we wanted to remove and that we wanted to transfer to the machine is on us. And now with AI, things can be different. I don't know if you guys agree, but this is what we think. And I do have a couple of examples. I'm not going to say out loud the name of these apps, but let's take a look. Here. First one. That icon is very well known. This is probably the most famous CRM of all time. But when I look at this screen, there's a lot going on. I don't even know where to start. Not only the information overload, how many features, how many teams do you think are somewhat involved just to ship this? Many, probably. Right? And this is just one. Let's have a look. I have a couple of other examples. So, this here. Look at that. Oh, my God. This is a fancy table. I don't even know where to start. But anyways. One more. Does everybody know this one here? Beautiful. Beautiful UI. Right? It's fantastic, super intuitive. And something else just to highlight. Do you guys know how much time these companies need to invest in onboarding people? So, that was the tradeoff. Right? So, you got to allocate a lot of time from a lot of people just to onboard newcomers as a result of this complexity that has been introduced over time. So, this is just at least the hardcore evidence. Different apps, different logic, every single time. And then more apps are coming out. So, imagine, just put yourself in the shoes of an average user, and then, oh, now I have five apps. And then every single one I need to learn how to navigate, how to browse, and so on and so forth. And then this has been the history up until now. But then, this was August last year. I sat down with my boss, who happens to be the founder of the company, so big shout out to my boss. And then we asked this question because at Commerce Tools, we are an API-first company, 300 plus, still counting. And we asked this question. Through the lens of artificial intelligence, what are the foundational shifts that could be made if we could change drastically the way that we interact with software, not in a static fashion? And the answer to that question led to the product that I'm going to demo right now. Let's go. How about a quick demo? You guys like the idea? Give me a thumbs up. I know everybody's tired. Let's go. Yay. All right. Cool. Look at this. I know. I'm going to zoom in. No worries. I have this query here: create a sales report for Q1. And the UX side of me, when I look at what was generated, and by the way, everything here on the right side has been auto-generated, guided by us, but this is AI, right, deciding on the placement, on the information architecture, deciding which components had to be actually retrieved from the catalog. But I don't like it at all. Right? Even if you don't know a lot about UX, I have at least four different variations because those were four different turns for the same query. Let's check it out. First one here, it was Q1, urban thread, whatever that is. Q1, IC, all of these KPI cards. There's a lot going on here. And then my intuition tells me, man, this doesn't add up. Okay. Second one, it's not Q1 anymore. Now this is January and March. There's no consistency. Does that help? Yes or no? No, right? This will only create confusion. If this is a heavily personalized experience for the user, imagine if every single time you need to prompt and then at least the model will output something different. This is not good. And this is just the second turn. Let's have a look at the third one. Oh, my God. Now there is even more stuff here on the right side. So, I have this component, the KPI cards, a bunch of text, a bunch of charts. And then this was the beginning of our journey. One more? Yes. Okay. Now it's still Q1, but still, for me, this is still confusing. And because this has been a very experimental journey, my feedback to the team and to myself was no, no, and no. There's no way that I would ship this to prod whatsoever. Right? And then I have my colleagues here just to confirm what I just said. But then things evolved. And I like to demo the current state of the product. It's much more sophisticated. And let's have a look. I like to plan a campaign. And for what it's worth, I'm going to save you from all the nitty-gritty details for everything that is domain-specific. But I'm going to pick this query here, and then let's see what happens. And this is the agentic orchestration part that I was going to highlight. Underneath the hood, we have the orchestrator. And the orchestrator can then extract the intent of the query. Based off of the intent of the query, it can locate the tools. Right? Those can be first-party, third-party tools. And the outputs of these different, it could be agents on MCP servers, combined will give enough, what I call, ammunition and context for the UX agent to eventually render something that we call meaningful. So, compared to the previous turns, this is decent. Right? I want to just remove my bias, but the overall aesthetics, the look and feel of this query, it resonates with me. Would you agree? Give me a thumbs up if you agree. Okay. At least the vast majority here. And then, see, it is decent. And let me just continue here. And then once again, right, this was decided by AI, guided by us. I just want to make that clear here. And the orchestrator can then just extract the intent of the query based off of the intent of the query. It can locate the tools. Right? Those can be first party, third party tools. And the outputs of this different, it could be agents on MCP servers. Combined will give enough what I call ammunition and context for the UX agent to eventually render something that we call meaningful. So, compared to the previous terms, this is decent. Right? I want to just remove my bias. But the overall aesthetics, the look and feel of this query, it resonates with me. Would you agree? Give me a thumbs up if you agree. Okay. At least the vast majority here. And then see, it is decent. And let me just continue here. And then once again, right? This was decided by AI, guided by us. I just want to make that clear here. And then I'm going to touch on the UI protocols and then how you can make this happen. But okay. Let's see. If I approve here, and then this is already live. And this is pre-prod. Right? So, this is great. Let me go back to my presentation. Perfect. I have one more question. Are you guys skeptical that this is possible? Because I can tell you, this is possible. If you're still skeptical, don't worry. I have all of these guys here also every day just looking at me and then challenging whether this can be made possible at scale. Right? And then, okay. And then this is the part that I would like to touch base on: the three ways that you can render what you just saw. And there are different UI protocols. Are you guys familiar with generative UI? Have you guys played with it? Let me see here. Okay. Wow. That's really cool. So, what I would like to share with you guys, it's all about how much control you want to exercise over the experience. And this matters a lot because, as a non-deterministic solution, you can decide if you want something really like this. So, let's have a look. Here. This is a chat GPT. And my query was, help me find a Japanese restaurant in SF today. Okay. If you guys see here, this component, this component is very opinionated. Would you agree with that here? Right? So, you can have complete control over this component. So, depending upon the nature of your business, this works really well. Right? And for that, let me just go back here. And then this is what I call control. Essentially, you ship the component as it is. The agent will pick and it will display exactly the way that you describe. However, depending upon the nature of your business, at least for us, right? My company, we're a B2B SaaS. There's so much configuration that we don't want to be over prescriptive because the feedback that I keep getting from my customers: oh, the flows are so confusing. There's so much configuration. How can you remove the cognitive load for me? But if you're like booking, for example, this approach works really well. And then let's see how it works. So, essentially, you have the agent. The agent will just pick the component from your catalog and then it will render as it is. Right? And in the interest of time, I'm not going to touch base on the code snippets that I have for these three different types. But afterwards, if you guys are interested, I can share the presentation and then you can have a look. All right? Very good. This is at least on the left side. Let's discuss a little bit on the right side because this is when you give full autonomy to the LLM. If you guys remember at least the previous attempts from my product, this is exactly what we did. So, we just say, hey, LLM, how would you compose this experience knowing that you have these components? Right? But that was a little bit of our opinion because it had some of the components available. But it could happen that you can just delegate fully to the LLM. And then right now, I'm here on Claude. And I ask Claude, hey, create an org chart with three levels. That was it. And then Claude just render this diagram. And it works really well. Right? But here, if I put myself in the shoes of a company, I'm not sure I would delegate fully to the LLM. Because I cannot control at least the output and the outcome. And me personally, me guys, as a UX leader, the UX side of me will always say no. You've got to be in control. There's been a couple of talks here at least this week on design, on taste and judgment. And this matters a lot. If you guys want to embark on this journey of leveraging these protocols, you don't want to delegate too much of the actual experience to the LLM. You've got to find alternatives. And I'm going to touch on that in just a little bit. Okay, cool. So, this is how the open-ended approach works. So, essentially, there's going to be an MCP tool. And then this will literally ship the HTML. And then in a sandbox iframe environment, this will be rendered in the host of your choice. But it can be a chat. It can be this cloud. It could be a chat GPT. It could be perplexity. Or it could be any other chat. If you're willing just to give full control to the LLM, good luck. But the one that I would like to highlight is this here. And this was our choice that we call the declarative. The declarative is in the middle. If you guys heard some of the protocols, and I don't want to get into the specifics of each because they have different characteristics. But H2UI from Google, JSON render from Vercel, OpenUI by Thesis. Those are some of the protocols that will give you this in-between here. And let's have a look, right? So, at least for my product, the one that I just showed, the orchestrator agent will eventually, if you think of the whole traversal, the user will enter the query. And then there's going to be the intent classification. Based off of the intent classification, then the tools will be invoked. The data will be retrieved. And somewhat in between, at least there will be the mapping of the eligible components from your catalog to the entities of the tools, right? And then the orchestrator will just broadcast this UI description. It's like a UI spec. This UI spec will be also, we have this component catalog here, and we use the ZOD schema. And then you've got to be compliant with this protocol. This is just one of the requirements. And then you just render that, right? And then the final output will be the native UI. In this case, the React components. This is it. The good thing about the declarative approach is it will be compliant with your design system everywhere. This matters a lot. So, in our case, we did not want to delegate to the LLM because you guys saw over there, you can change the copy, right? So, it's not key one. Sometimes it's going to be March, January to March. It matters a lot. So, within UX, we have different vectors, right? We have the actual UX. If you think of the overall experience, there is UI. There's also copy UX writing, and so on and so forth. But this approach gives us this in between. It is less deterministic. And I think this is a really good segue to some of the challenges. Because imagine, I'm going to use my example once again. The orchestrator would just fetch the eligible components for that query. But then, it's up to the LLM how to place in the UI. And this can get really, really messy, right? And those are the challenges that I would like to share with you guys here. I've got to be careful because I've got only 30 minutes. But let's go. So, the first challenge is if the agent picks the components, who is in charge of arranging them? And this is information architecture, right? This is a critical aspect of UX. And then, once again, if you put yourself in the shoes of the average customer, it matters a lot. So, if you're just left alone, the placement can be totally random. So, at least in my team, we borrow this concept of atomic design. And atomic design, it goes like this. Let me just change here. Yeah. So, as you can see, atomic design, and then I have the definition, is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner. This helps a lot, right? Because those are the individual elements. And if you think of the overall structure of the page, it gives me the ability to steer as I see fit. And what we've done in my team, this UX agent, we harnessed this UX agent. So, we eventually taught this UX agent what good looks like. What is the optimal layout for a given situation. And we have a catalog of different templates. But I would like to show you at least this, because this detail is very important. Here. It is the overall hierarchy. So, at least in my team, we borrow this concept of atomic design. And atomic design goes like this. Let me just change here. Yeah. So, as you can see, atomic design, and then I have the definition, is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner. This helps a lot, right? Because those are the individual elements. And if you think of the overall structure of the page, it gives me the ability to steer as I see fit. And what we've done in my team, this UX agent, we harnessed this UX agent. So, we eventually taught this UX agent what good looks like. What is the optimal layout for a given situation. And we have a catalog of different templates. But I would like to show you at least this, because this detail is very important. Here. It is the overall hierarchy. So, if you remember, part of the orchestrator, the orchestrator will eventually just fetch the eligible components to accomplish the query of the user. But then, the next big question is, how do we arrange that? The approach that we used was: think of this hierarchy. So, you have the overall page, the layout. The layout will contain different slots. So, think of this one here, the header. You can have the main. And then, you can have sub slots. Sub slots can have sub slots. And within the sub slots, you can have eligible component categories. And then, this will allow us to steer, eventually, the optimal placement of the components that have been retrieved by the orchestrator. So, this is literally us codifying our UX knowledge into this agent. So, the next time, it doesn't matter. We'll just follow the same approach. And then, this is the hierarchy that we're using. So, layout to slots, to sub slots, to components. However, because of the orchestrator, we flip the order. So, from components, components will map to sub slots, sub slots to slots, slots to templates. And then, we can just arrange as needed. So, this was a hell of a challenge. It is still a challenge, by the way. And this is a really good segue to the second one, the second challenge, which is the actual design. Your design system and your catalog. This becomes the heartbeat of the whole thing. Right? I cannot stress enough. If you guys see the potential of leveraging this UI protocols for your product, this is going to be a big deal. Right? So, we're pushing the boundaries. And then, we're testing. And we keep on testing these different protocols that I mentioned. H2UI, JSON render, open UI, and so on and so forth. But this has been quite challenging. Because the catalog is the contract between the agent and the UI. So, every property matters. And not only for the catalog, but for the layout as well. So, if you remember, the layout has its own components. The slots and the sub slots. Each of those components will have its own attributes. And all of that, this curation, let me just encapsulate into curation. This curation is absolutely needed so that you can deliver something meaningful. Not some demo that you will see out there for the sake of demo. Right? So, this will give you control. It will allow you to steer from a UX perspective. Very good. And last but not least, one significant challenge that we had is that my teams do not design the pixel anymore. I don't know if you could see that. Right? So, we're not here designing the entire flow. Now, AI can dictate that to a significant extent. But the nature of the work shifted quite a bit. And it's been an interesting journey, to say the least. A really good one. But even for the non-technical PMs and UX designers, it was a big hit. Because right now, we talk about the schema. Let's talk about this curation of the catalog. Let's talk about the rules. Let's talk about the synthetic data that we can generate. How can we generate the queries that will map to a given component as part of this mapping logic? Let's talk about interaction patterns. So, this, once again, if you guys are going to embark on this journey, be aware that the people element is very important. When I talk to other leaders, I talk about the three Ps. People, product, and process. Right? And then, very lightweight process. But this matters a lot. And with that, I'm going to leave a couple of resources here. And by the way, those are talks from AIE. For what it's worth. So, yeah. People that have been talking about these protocols over and over and over. So, please. Just take advantage. Take a screenshot. And if you guys want to connect with me here. Yeah. My LinkedIn. Or just take a screenshot. I would love to talk more about the topic. I can tell you this. It's just a matter of time. Right? So, this is coming. So, thank you so much. I gotohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohoh For what it's worth. So, yeah. People that have been talking about these protocols over and over and over. So, please. Just take advantage. Take a screenshot. And if you guys want to connect with me here. Yeah. My LinkedIn. Or just take a screenshot. I would love to talk more about the topic. I can tell you this. It's just a matter of time. Right? So, this is coming. So, thank you so much. I gotohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohohoh