Eine Notiz von der anderen Seite derselben Grenze
Drei Gedanken zurück zu generativer UI, MCP Apps, Kontext und Governance.
Kurzfassung — Generative UI verändert die Ökonomie aufgabenspezifischer Schnittstellen. Struktur macht Modellleistung kontrollierbar. Kontext sollte ausserhalb eines einzelnen Modells bleiben; Governance gehört an die Verbindung zwischen Kontext, Modell und Schnittstelle.
Dieser Text begann als privater Brief an Ruben Casas nach seinem Talk Beyond Components — Designing Generative UI for MCP Apps.
Der Talk gab mir Sprache für etwas, dem ich mich aus einer anderen Richtung genähert hatte. Ruben kam von Protokollen und Rendering. Ich kam von Adoption, Kontext und Governance.
Drei Gedanken blieben hängen.
Host-Anwendung → vorgefertigte Komponente
Modell → Beschreibung → Host-gerenderte UI
Aufgabe + Kontext → Oberfläche → Interaktion
Schnittstelle · Modell · Kontext · Governance
portabler Kontext → gesteuerte Verbindung → Modell + UI
Konversation → Canvas → Interaktion ↺ nächster Schritt
01 — Ökonomie der Spezifität statt Bildschirmevolution
Bei generativer UI liegt die Versuchung nahe, die Revolution als völlig neuen Bildschirm zu denken: räumliche Canvases, schwebende Fenster, Schnittstellen ohne Namen.
Das mag kommen. Die unmittelbarere Veränderung ist für mich jedoch ökonomisch.
Photoshop, Premiere, VS Code, DAWs und Figma haben uns längst ein dauerhaftes Designmuster gezeigt: dichte, aufgabenspezifische Oberflächen. Die Schnittstelle passt sich der Arbeit an.
Generative UI verändert die Kosten dieser Spezifität. Statt über Jahre feste Panels und Menüs auszuliefern, kann ein System pro Aufgabe, Person und Moment eine passende Oberfläche zusammensetzen.
Die Revolution muss nicht darin liegen, dass der Bildschirm fremdartig wird. Vielleicht wird Spezifität einfach günstig.
02 — Struktur macht Leistung kontrollierbar
Ruben bezeichnete deklarative UI als nützliche Balance zwischen Flexibilität und Konsistenz. Dieser Punkt ist weiterhin stark.
Das breitere Muster zeigt sich überall in strukturierter Generierung: Schemata, begrenzte Komponenten, deklarative Beschreibungen, Validierung, Tool-Verträge und Aktionsgrenzen.
Das Ziel ist nicht, das Modell schwach zu machen. Es soll einen präzise geformten Ort erhalten, an dem es handeln kann.
Modellfähigkeit + strukturierter Vertrag → begrenzte Aktion → prüfbares Ergebnis
Ein Modell kann beliebiges HTML erzeugen. Ein Produktionssystem profitiert aber oft davon, wenn es stattdessen eine begrenzte Darstellung erzeugt, die der Host rendert und validiert.
03 — Kontext zentralisieren, nicht Schnittstellen. Die Verbindung steuern.
Das Rendering-Gespräch beginnt oft mit der Frage: „Wo läuft die UI?“ Davor liegt für mich eine andere: Was sollte zentral sein, und was sollte an den Rändern bleiben?
Ich mag diese Architektur weiterhin. Einen Satz aus dem Entwurf von 2026 würde ich aber abschwächen: „Das Modell wird zum austauschbaren Utility“ ist ein Designziel, keine garantierte Eigenschaft. Anbieterspezifische Werkzeuge, Kontextsemantik und Modellverhalten können einen Wechsel teuer machen.
Auch die Kontextportabilität über Werkzeuge und Modelle hinweg bleibt unvollständig und fragmentiert. Das ist die architektonische Richtung, keine Behauptung, dass die nötige Produktschicht bereits gelöst wäre.
MCP Apps machen die Verbindung konkret
MCP Apps bieten ein standardisiertes Muster, mit dem Server interaktive UI-Ressourcen deklarieren können. Unterstützende Hosts rendern sie in Sandbox-iFrames und vermitteln die bidirektionale Kommunikation. Das offizielle Spezifikations- und SDK-Repository kennzeichnet die Version 2026-01-26 als stabil.
Damit entsteht ein realer Verbindungspunkt zwischen Werkzeug, UI und Gesprächskontext. Die Unterstützung unterscheidet sich weiterhin je nach Host.
Die Erweiterung beseitigt Governance jedoch nicht. Sie macht sie konkreter:
- Welcher Kontext erreicht das Werkzeug?
- Welche Fragmente dürfen angezeigt oder weitergegeben werden?
- Welche Aktionen darf die eingebettete UI auslösen?
- Was protokolliert oder auditiert der Host?
- Was geschieht, wenn ein Host die Erweiterung nicht unterstützt?
Konversation als Canvas als Konversation
Der Moment auf der Nutzerseite, der mir das zuerst verständlich machte, war viel einfacher. Ich bat ein LLM, ein BPMN-Diagramm für die Zubereitung einer Margherita-Pizza zu zeichnen.
Interessant war nicht, dass es zeichnen konnte. Das Diagramm wurde im Gespräch zu einer temporären Arbeitsoberfläche: etwas, auf das ich zeigen, das ich verändern und mit dem ich denken konnte.
Konversation → aufgabenspezifische Oberfläche → menschliche Interaktion → nächster Modellschritt → veränderte Oberfläche
Wir sind heute deutlich näher daran, dass dieses Muster zu einem Standardbaustein von Produkten wird.
Die Grenze von der Adoptionsseite aus
Protokoll- und Rendering-Schichten werden real. Die ungelöste institutionelle Frage bleibt die Verbindung.
In einer regulierten Organisation scheitert eine Demo selten daran, dass die erzeugte Karte nicht attraktiv genug ist. Sie scheitert, wenn niemand beantworten kann, wer welchen Kontext unter welcher Befugnis an welches Modell und Werkzeug geleitet hat – und mit welcher Auditspur.
Schnittstellen verteilen.
Kontext portabel halten.
Die Verbindung steuern.
Quellen
Bringen Sie eine echte Frage zur KI-Adoption mit.
Wir machen daraus etwas Klareres: eine Entscheidung, ein erstes Experiment, eine Governance-Frage oder einen praktischen nächsten Schritt.