The chat box makes users package their work into prompts, wait, inspect the answer and try again. That is a poor fit for tasks already happening in an editor, document or table. Exposing that hidden interface work makes the alternatives easier to judge. Assistance moves back where the context already lives, and persistent artifacts give people room to edit and review. They force product decisions that chat can avoid: which components may the model choose, what can an older client render, and where may generated HTML, CSS or JavaScript run? Longer agent jobs make those choices more urgent. People need to see what the agent is doing, interrupt it when necessary, and check its claims against independent evidence.
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 decides what each client can render. Mihalik shows what rendering does to the model inside a chat host. If the app only injects HTML, the model cannot see the jobs the user is looking at, and a search tool that draws a carousel at once can make the model search once and stop. His fix keeps search as an ordinary tool and passes the chosen job IDs to a separate render tool.
Why here: Mihalik keeps a fixed renderer and lets the model choose what goes into it. 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.