Uploaded September 2026 | Updated September 2026, 3 weeks ago
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
- 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 - Control: shipping an opinionated component
12:44 - Open ended: handing the whole thing to the model
14:59 - Declarative, and the protocols that support it
17:21 - Who arranges the components the agent picked
18:30 - Borrowing atomic design, and flipping the hierarchy
21:56 - When your team stops designing pixels
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
- 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 - Control: shipping an opinionated component
12:44 - Open ended: handing the whole thing to the model
14:59 - Declarative, and the protocols that support it
17:21 - Who arranges the components the agent picked
18:30 - Borrowing atomic design, and flipping the hierarchy
21:56 - When your team stops designing pixels
