{
  "video": {
    "id": "QrMcNe2jjt8",
    "title": "The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools",
    "duration": 1399,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer"
  },
  "analysis": {
    "video_id": "QrMcNe2jjt8",
    "title": "The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools",
    "one_liner": "A commercetools GM shows why letting an LLM freely compose UI produces inconsistent, unshippable screens, and lays out the middle path his team chose — a declarative UI protocol where an orchestrator picks components and a UX agent places them inside a codified layout → slot → sub-slot → component hierarchy.",
    "summary": "Gus Iwanaga rejects his own submitted title and instead gives lessons learned from a team shipping generative UX/UI in a B2B SaaS product. He argues software has been static for 40 years — users adapt to each app's mental model and pay the onboarding and cognitive-load cost — and demos both his team's failed first attempt (the same 'create a sales report for Q1' query rendering four inconsistent layouts, sometimes relabelled 'January to March') and the current pre-prod product, where an orchestrator classifies intent, invokes first- and third-party tools/MCP servers, and hands the results to a UX agent that renders React components. He frames three rendering approaches by how much control you keep — controlled components, fully open-ended LLM-generated HTML in a sandboxed iframe, and the declarative middle they chose — and closes with three challenges: information architecture, catalog curation, and the fact that his designers no longer design pixels.",
    "key_points": [
      "Framing of the problem: for 40 years we've shipped static experiences and users adapt to the software, not the reverse; every SaaS app carries its own mental model, and the cognitive load that should have moved to the machine sits on the user — which is why these companies must invest so heavily in onboarding.",
      "The product came from a question he and the company founder asked in August of last year at commercetools, an API-first company with '300 plus still counting' APIs: through the lens of AI, what foundational shifts are possible if we drastically change how we interact with software?",
      "Live demo of the failed early version: four runs of the same 'create a sales report for Q1' query produced four different layouts — differing KPI cards, charts and text, and copy that drifted from 'Q1' to 'January and March'. His verdict to the team was 'no, no, and no' — not shippable to prod.",
      "Current pre-prod demo ('plan a campaign'): an orchestrator extracts the query's intent, locates tools (first-party, third-party, agents, MCP servers), and their combined outputs give the 'ammunition and context' for a UX agent to render something meaningful, with an approve step in the flow.",
      "Three UI protocol approaches positioned on a control axis: controlled (you ship the component as-is and the agent picks it from your catalog — ChatGPT's opinionated Japanese-restaurant card, works well for a business like Booking); open-ended (an MCP tool ships raw HTML rendered in a sandboxed iframe in Claude, ChatGPT, Perplexity or any host — he asked Claude for a three-level org chart and it rendered a working diagram); and declarative in the middle, citing HTMX from Google, JSON Render from Vercel and OpenUI by Thesis.",
      "Their declarative pipeline: query → intent classification → tool invocation and data retrieval → mapping of eligible catalog components to tool entities → orchestrator broadcasts a 'UI description'/UI spec → component catalog defined with Zod schemas and protocol compliance → native React components. The payoff is design-system compliance everywhere and control of copy, which full LLM delegation loses.",
      "Challenge 1 — information architecture: if the agent picks the components, what arranges them? They borrowed atomic design ('a methodology composed of five distinct stages... in a more deliberate and hierarchical manner') and harnessed a UX agent taught what good looks like, with a template catalog and a layout → slot → sub-slot (nestable) → eligible component category hierarchy. Because the orchestrator retrieves components first, they run it in reverse: components → sub-slots → slots → templates.",
      "Challenge 2 — the design system and component catalog become 'the heartbeat of the whole thing': the catalog is the contract between agent and UI, every property matters, and layout components (slots, sub-slots) have their own attributes; that curation is what separates a real product from a demo for the sake of demo. Challenge 3 — people: teams no longer design the pixel, and the work shifted to schemas, catalog curation, rules, synthetic data, and generating queries that map to components — a big hit for non-technical PMs and UX designers."
    ],
    "takeaways": [
      "Don't hand the whole experience to the LLM. Pick your position on the control axis deliberately — for B2B SaaS with heavy configuration, use a declarative protocol where the model selects and arranges from your catalog but cannot invent copy or components.",
      "Codify your UX knowledge as an explicit layout hierarchy (layout → slot → sub-slot → component category) plus a template catalog, and teach the UX agent what good looks like for a given situation; otherwise component placement is random and inconsistent between turns.",
      "Treat the component catalog as the contract between the agent and the UI: define it with schemas (they use Zod), curate every property including layout/slot attributes, and make it compliant with the UI protocol you've chosen.",
      "Test the same query several times before believing a generative-UI demo — the failure mode is turn-to-turn inconsistency in layout, information architecture and copy (Q1 becoming 'January to March'), not a single bad render.",
      "Plan for the people shift: PMs and UX designers move from designing flows and pixels to arguing about schemas, catalog curation, rules, synthetic data and interaction patterns. Manage it as people, product and process, with a lightweight process."
    ],
    "topics": [
      "generative-ui",
      "ui-protocols",
      "agentic-orchestration",
      "design-systems",
      "mcp",
      "ux",
      "b2b-saas",
      "atomic-design"
    ],
    "tools": [
      "commercetools",
      "ChatGPT",
      "GPT",
      "Claude",
      "Perplexity",
      "MCP",
      "Zod",
      "React",
      "HTMX (Google)",
      "JSON Render (Vercel)",
      "OpenUI (Thesis)",
      "Booking"
    ],
    "quotes": [
      {
        "text": "The cognitive load that we wanted to remove and that we wanted to transfer to the machine, uh it's on us.",
        "at": "03:40",
        "url": "https://www.youtube.com/watch?v=QrMcNe2jjt8&t=220s"
      },
      {
        "text": "chat. If you're willing just to to give full control to the LLM, good luck.",
        "at": "14:37",
        "url": "https://www.youtube.com/watch?v=QrMcNe2jjt8&t=877s"
      },
      {
        "text": "because the the catalog is the contract between the agent and the UI.",
        "at": "20:40",
        "url": "https://www.youtube.com/watch?v=QrMcNe2jjt8&t=1240s"
      },
      {
        "text": "that my teams do not design the pixel anymore.",
        "at": "21:26",
        "url": "https://www.youtube.com/watch?v=QrMcNe2jjt8&t=1286s"
      }
    ],
    "words": 4504
  },
  "summary_url": "/#QrMcNe2jjt8",
  "transcript": {
    "html": "/transcripts/QrMcNe2jjt8.html",
    "txt": "/transcripts/QrMcNe2jjt8.txt",
    "vtt": "/transcripts/QrMcNe2jjt8.vtt"
  }
}