# A note from the other side of the same frontier _Three thoughts back on generative UI, MCP Apps, context and governance._ **TL;DR —** Generative UI changes the economics of task-specific interfaces. Structure makes model power controllable. Context should stay outside any one model, while governance belongs at the attachment between context, model and interface. > **Archive update · September 2026** > > Ruben Casas’ talk remains a useful source, and MCP Apps have since become an official MCP extension with a stable 2026-01-26 specification. Host support still varies, so “MCP Apps provide the delivery layer” should not be read as universal deployment support. This started as a private letter to [Ruben Casas](https://www.youtube.com/watch?v=hCMrEfPG2Yg) after his talk *Beyond Components — Designing Generative UI for MCP Apps*. The talk gave me language for something I had been approaching from a different direction. Ruben came from protocols and rendering. I came from adoption, context and governance. Three thoughts stayed with me. **Argument map · From generative interface to governed attachment** Six states move from static and declarative interfaces through generative UI to separate interface, model, context and governance layers, a governed attachment, and a conversation-canvas feedback loop. ```text 01 · Static components The host selects a pre-built component. Data and properties change; the available surface remains fixed. host application → pre-built component 02 · Declarative UI The model produces a structured descriptor. The host validates and renders a bounded component, properties and layout. model → descriptor → host-rendered UI 03 · Generative UI The task receives a task-shaped surface. Context informs a temporary interface whose interaction can shape the next turn. task + context → surface → interaction 04 · Separate the layers Interface, model, context and governance have different jobs. Replaceability and portability are goals that depend on keeping these concerns explicit. interface · model · context · governance 05 · Govern the attachment Policy controls what connects. Consent, permissions and audit mediate how context reaches a model, tool and task interface. portable context → governed attachment → model + UI 06 · Collaborative canvas Conversation becomes a working surface. The user changes the temporary interface, and that interaction becomes input to the next model turn. conversation → canvas → interaction ↺ next turn ``` ## 01 — Specificity economics, not screen evolution The temptation with generative UI is to imagine that the revolution must be a new kind of screen: spatial canvases, floating windows, interfaces we have not yet named. That may happen. But I think the more immediate change is economic. Photoshop, Premiere, VS Code, DAWs and Figma already taught us a durable design pattern: **dense, task-shaped surfaces**. The interface adapts to the work. What generative UI changes is the cost of producing that specificity. Instead of shipping years of fixed panels and menus, a system can assemble a useful surface per task, user and moment. > The revolution may not be that the screen becomes alien. It may be that specificity becomes cheap. ## 02 — Structure turns power into usable control Ruben called declarative UI a useful balance between flexibility and consistency. That point has aged well. The broader pattern is visible across structured generation: schemas, constrained components, declarative descriptors, validation, tool contracts and action guards. The goal is not to make the model weak. It is to give a powerful model a precisely shaped place to act. ```text model capability + structured contract → bounded action → inspectable result ``` A model can generate arbitrary HTML, but a production system often benefits when it can instead produce a constrained representation that the host renders and validates. ## 03 — Centralize context, not interface. Govern the attachment. The rendering conversation often starts with “where does the UI run?” I think there is a prior question: **what should be central, and what should remain at the edges?** **Interface** Distributed, task-specific, per tool and moment. **Model** Reasoning and compute utility; ideally replaceable. **Context** Accumulated knowledge and working state outside any single model. **Governance** Rules for what context may attach to which model and interface. I still like this architecture, but one sentence from the 2026 draft should be softened. “The model becomes a swappable utility” is a design goal, not a guaranteed property. Provider-specific tools, context semantics and model behaviour can make substitution expensive. Context portability across tools and models also remains incomplete and fragmented. That is the architectural direction, not a claim that the required product layer is already solved. ## MCP Apps make the attachment concrete [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview) provide a standardized pattern for servers to declare interactive UI resources that supporting hosts can render in sandboxed iframes, with bidirectional communication through the host. The [official specification and SDK repository](https://github.com/modelcontextprotocol/ext-apps) marks version 2026-01-26 as stable. That gives us a real attachment point between tool, UI and conversational context. Support still varies by host. But the extension does not eliminate governance. It makes governance more specific: - Which context reaches the tool? - Which fragments may be displayed or sent onward? - What actions can the embedded UI invoke? - What does the host log or audit? - What happens when the host does not support the extension? ## Conversation as canvas as conversation The user-side moment that first made this intuitive for me was much simpler. I asked an LLM to draw a BPMN diagram of making a margherita pizza. The interesting part was not that it could draw. The diagram became a temporary task surface inside the conversation: something I could point at, change and reason through. ```text conversation → task-shaped surface → human interaction → next model turn → changed surface ``` We are now much closer to that pattern being a standard product primitive than when I first had the thought. ## The frontier from the adoption side The protocol and rendering layers are becoming real. The unresolved institutional question is still the attachment. Inside a regulated organisation, the demo rarely fails because the generated card is unattractive. It fails when nobody can answer who routed which context, under what authority, to which model and tool, with what audit trail. > Distribute the interface. Keep context portable. **Govern the attachment.** ## Sources - [Ruben Casas — Beyond Components: Designing Generative UI for MCP Apps](https://www.youtube.com/watch?v=hCMrEfPG2Yg) - [Model Context Protocol — MCP Apps overview](https://modelcontextprotocol.io/extensions/apps/overview) - [Official MCP Apps specification and SDK repository](https://github.com/modelcontextprotocol/ext-apps)