AI products inherited the chat box before anyone knew whether it was the right interface. The first talk compares prompting to punch cards. The next two put help back inside the user's work and replace the long conversation with documents, tables and other things that persist. Once that sounds appealing, the awkward implementation questions arrive: which components may the model choose, what can each client render, and where does generated code run? The final three talks care less about novelty than control. Shared work has to stay visible and interruptible. More importantly, the interface should make a person examine the evidence rather than approve whatever the model put in front of them.
Why first: Johnson names the protocol the rest of the pack is trying to escape. Prompting still looks like batch work: assemble a request, submit it, wait, inspect the answer and submit a repair. Objartel's talk makes more sense once that hidden interface work is visible.
Why second: Johnson explains why prompting feels like batch work. Objartel offers the first practical alternative: help that appears inside the task, where the context already exists, and asks before making a change that may be wrong.
Why here: Objartel moves assistance into an existing workflow. Lauritzen shows why complex work also needs something that lasts. Documents and tables expose decisions, accept edits and comments, and give a person somewhere to review work that would disappear inside one long thread.
Why here: Lauritzen argues for persistent artifacts. Iwanaga explains how a product can assemble one from a user's intent without letting the model improvise the whole interface. His failed sales-report experiments make the case for a schema and a known set of native components.
Why here: Iwanaga defines the declarative contract at product level. Ramdoss follows it down into streaming, client versions and fallbacks. A model response is still raw material; the rendering layer decides what an old phone or a current web client can safely turn into an interaction.
Why here: Ramdoss shows how to deliver controlled components across real clients. Casas widens the choice: static UI, model-selected components or generated code. The extra freedom is real, but so is the trust boundary around HTML, CSS and JavaScript written at runtime.
Why here: Casas ends with a shared, editable artifact. Nguyen shows what that feels like in practice. Canvas lets a person and a model write, code, research and correct the work in the same place instead of passing messages across a chat transcript.
Why here: Nguyen says shared work must remain open to correction. Dibia turns that into controls: show what the agents are doing and where their information came from, let a person interrupt or roll back, and expose enough cost and risk to decide how much autonomy to grant.
Why last: Dibia gives people controls over autonomous work. Ortmann Lee closes with the harder problem: controls do little if the screen still invites a rubber stamp. Separating the model's signal from the decision and asking for independent evidence can change judgment without changing the model.