Generative UI ist das neue Frontend

Das Frontend war früher eine feste Sache. Designer zeichneten es. Entwickler bauten es. Benutzer bekamen, was ausgeliefert wurde.

Das ist vorbei.

Die Oberflächen, die 2026 ausgeliefert werden, werden teilweise vom Agenten selbst in Echtzeit gezeichnet – basierend auf dem, wonach der Benutzer tatsächlich gefragt hat. Frag nach einer Tabelle, bekommst du eine Tabelle. Keinen Absatz, der eine beschreibt.

Generative UI ist die Schicht, die es Agenten ermöglicht, aufzuhören zu beschreiben und stattdessen zu zeigen. Drei Muster haben sich herauskristallisiert, wie man sie baut – und die Unterschiede zwischen ihnen sind wichtiger, als die meisten Teams glauben.

Aber es gibt nicht nur einen Weg, das zu bauen. Es gibt drei. Und die meisten Teams wählen einen, ohne zu wissen, dass sie sich entschieden haben.

Der Protokoll-Stack

Drei Protokolle. Jedes macht eine Aufgabe.

MCP verbindet Agenten mit Tools. A2A verbindet Agenten miteinander. AG-UI verbindet Agenten mit Benutzern.

AG-UI ist die Streaming-Schicht, die all das trägt, was du unten sehen wirst: Tool-Aufrufe, A2UI-Schemata, MCP-App-Ereignisse, Zustandsänderungen. Läuft über SSE. Der Zustand fließt in beide Richtungen auf demselben Stream. Benutzer bearbeitet, Agent sieht. Agent mutiert, Benutzer sieht.

A2UI ist Googles Spezifikation dafür, dass Agenten UI als Schema ausgeben. Es läuft auf AG-UI. CopilotKit liefert es in der Produktion aus.

Du schreibst keinen Parser für all das. CopilotKit ist ein AG-UI-Client und dekodiert den Stream für dich.

Die drei Muster, die die meisten Teams verwechseln

Frag zehn Entwickler, was Generative UI ist. Du bekommst zehn Antworten. Die meisten beschreiben das Muster, das ihr aktuelles Framework mitbringt.

Es gibt nur drei. Das Spektrum reicht von mehr Kontrolle zu mehr Flexibilität.

• Kontrolliert: Du baust die Komponenten vor. Der Agent wählt aus, welche gerendert werden.
• Deklarativ: Der Agent gibt ein Schema aus. Deine App mappt es auf Komponenten.
• Offen: Der Agent schreibt rohes HTML. Deine App rendert es in einer Sandbox.

Jedes Gen-UI-Framework im Jahr 2026 liegt irgendwo auf dieser Linie. Die Unterschiede sind architektonisch, nicht kosmetisch. Jedes Muster bringt deine App auf eine andere Art und Weise im großen Maßstab zum Einstürzen.

Ich habe verschiedene Stacks ausprobiert. Die meisten decken ein Muster gut ab. Gelandet bin ich bei CopilotKit, weil es alle drei auf derselben Laufzeit unterstützt, aufbauend auf AG-UI. Das ist der Stack, auf dem alles unten läuft.

Muster 1: Kontrolliert – das Frontend besitzt die UI

Hier fangen die meisten Teams an. Hier bleiben die meisten Teams auch stecken.

Du baust eine React-Komponente vor. Du bindest sie an einen Tool-Namen. Der Agent wählt dieses Tool aus, und die Komponente wird inline im Chat mit den Agent-Argumenten als Props gerendert.

Ein Frontend-Hook. Null Agent-Code. Das war's.

1"use client";
2import { z } from "zod";
3import { useComponent } from "@copilotkit/react-core/v2";
4
5const expenseChartSchema = z.object({
6  title: z.string(),
7  data: z.array(z.object({ label: z.string(), value: z.number() })),
8});
9
10function ExpenseChart({ title, data }: z.infer<typeof expenseChartSchema>) {
11  return (
12    <section className="rounded-xl border p-4">
13      <h3 className="text-sm font-medium">{title}</h3>
14      <ul className="mt-2 grid gap-1">
15        {data.map((d) => (
16          <li key={d.label} className="flex justify-between text-sm">
17            <span>{d.label}</span>
18            <span>${d.value}</span>
19          </li>
20        ))}
21      </ul>
22    </section>
23  );
24}
25
26export function ExpensesCopilot() {
27  useComponent({
28    name: "showExpenseChart",
29    description: "Render a breakdown of expenses by category.",
30    parameters: expenseChartSchema,
31    render: ExpenseChart,
32  });
33
34  return null;
35}

Der Hook registriert das Tool in der CopilotKit-Laufzeit. Die Laufzeit macht es dem Agenten über AG-UI bekannt. Wenn der Agent es aufruft, streamen die Argumente herein, und deine Komponente wird inline gerendert. Kein Python-Tool zum Schreiben, kein Schema zum Verkabeln, keine API-Route zum Hinzufügen.

Dein Designsystem bleibt am Ruder.

Dieses Ausgabediagramm ist kein Mockup. Der KI-Finanzcoach-Agent rendert Karten genauso für echte Budgets, Sparpläne und Schuldenrückzahlung.

Willst du zuerst den nackten Hook? Er ist in 'use-generative-ui-examples.tsx' im Generative UI Starter-Projekt.

Die Token-Steuer

Jede Komponente, die du registrierst, sitzt im Kontextfenster des Agenten, bevor der Benutzer etwas gesagt hat. Eine typische Tool-Beschreibung mit ihrem JSON-Schema kostet etwa 400 Token. 25 Komponenten sind 10.000 Token bei jeder Runde. Diese Steuer zahlst du pro Anfrage.

Der Agent wählt auch die falsche Komponente. Zu viele sehen ähnlich aus. Tortendiagramm und Donut-Diagramm zeigen beide „Anteile". Er rät.

Wann man agentenseitigen Zustand hinzufügen sollte

Gemeinsamer Zustand ist der eine Fall, in dem sich das Schreiben eines Python-Tools lohnt. Der Agent schreibt in den Sitzungszustand. Andere Teile der UI abonnieren und rendern neu, ohne einen zweiten LLM-Aufruf. Pinne eine Metrik, das Dashboard aktualisiert sich. Füge eine Zeile hinzu, die Tabelle zeichnet sich neu.

1from google.adk.agents import LlmAgent
2from google.adk.tools import ToolContext
3
4def pin_metric(tool_context: ToolContext, label: str, value: float) -> dict:
5    """Pinne eine Metrik an das Dashboard des Benutzers."""
6    pinned = tool_context.state.get("pinnedMetrics", [])
7    tool_context.state["pinnedMetrics"] = pinned + [{"label": label, "value": value}]
8    return {"status": "pinned"}
9
10agent = LlmAgent(name="dashboard_agent", model="gemini-3.5-flash", tools=[pin_metric])

Das Frontend liest die gepinnten Metriken über den Shared-State-Hook von CopilotKit. Die Chat-Komponente wird immer noch inline gerendert, weil derselbe Tool-Name mit dem Frontend-Hook verdrahtet ist.

Pinne eine Metrik im Chat. Das Panel zeichnet sich neu ohne zweiten Modellaufruf. Das ist der KI-Dashboard-Canvas-Agent.

Der KI-Deep-Research-Agent geht noch weiter. Der Plan, jede Suche, jeder Dateischreibvorgang – alles streamt als Live-Karten. Für alles andere ist der Frontend-Hook die ganze Geschichte.

Wann man Kontrolliert ausliefern sollte: Zehn oder weniger hochwertige Abläufe. Designgenauigkeit zählt. Du kennst die genauen UIs, die du brauchst.

Wann nicht: Deine Codebasis wächst linear mit den Anwendungsfällen. 25 Komponenten bedeuten 25 Tool-Definitionen, die in jeder Agentenrunde sitzen.

Was kaputtgeht: Der Agent wählt die falsche Komponente. Zwei Tool-Beschreibungen überschneiden sich semantisch. Ab 15 Tools lesen sich wahrscheinlich zwei wie „zeigt Daten an". Lösung: Schreibe die Beschreibungen um, um die Benutzerabsicht zu nennen, nicht die Optik. „Verwenden, wenn der Benutzer Proportionen eines Ganzen vergleichen möchte" schlägt „rendert ein Tortendiagramm".

Muster 2: Deklarativ (A2UI) – der Agent gibt Schema aus

Dies ist das Muster, das die meisten Produktions-Agenten-Apps am Ende benötigen.

Der Agent gibt ein JSON-Schema aus, das die UI beschreibt. Deine App hat einen Katalog von Komponenten, der Schema-Knoten auf React (oder Svelte, Flutter, was auch immer) abbildet. Ein Tool. Viele UIs.

A2UI ist die Standardspezifikation. CopilotKit liefert die Laufzeit. ADK betreibt den Agenten. AG-UI ist die Leitung.

Das Agent-Tool gibt drei Operationen in der richtigen Reihenfolge zurück: eine Oberfläche erstellen, den Komponentenbaum schieben, die Daten schieben.

1def search_flights(flights: list[Flight]) -> dict[str, Any]:
2    """Suche Flüge und zeige sie als reichhaltige Karten an."""
3    return {
4        "a2ui_operations": [
5            {"type": "create_surface", "surfaceId": SURFACE_ID, "catalogId": CATALOG_ID},
6            {"type": "update_components", "surfaceId": SURFACE_ID, "components": FLIGHT_SCHEMA},
7            {"type": "update_data_model", "surfaceId": SURFACE_ID, "data": {"flights": flights}},
8        ]
9    }

Das ist die tatsächliche Funktion, kein Pseudocode. Die Laufzeit-Middleware sieht den a2ui_operations-Container im Tool-Ergebnis und leitet Oberflächen an das Frontend weiter. Hotels hinzufügen? Neue Schema-Datei. Eine weitere Funktion mit einer anderen surfaceId. Null zusätzliche Frontend-Arbeit.

Festes Schema vs. dynamisches Schema

Der Komponentenbaum oben lebt in flights.json. Du hast ihn geschrieben. Der Agent füllt nur die Daten ein. Das ist ein festes Schema.

Dynamisches Schema dreht es um: Ein sekundäres LLM schreibt den Komponentenbaum pro Runde aus dem Gesprächskontext. Derselbe a2ui_operations-Container am Ende. Die Google ADK-Showcase liefert beide aus.

Der Katalog ist der Vertrag

Definitionen listen die Komponenten auf, die der Agent ausgeben darf, mit Zod-Schemata für die Props. Renderer füllen React aus. Tippfehler werden zu Build-Fehlern statt zu leeren Bildschirmen.

1const renderers: CatalogRenderers<TravelDefinitions> = {
2  FlightCard: ({ props }) => (
3    <article className="rounded-xl border p-4">
4      <header className="flex justify-between">
5        <span>{(props as any).airline}</span>
6        <span>{(props as any).price}</span>
7      </header>
8      <div className="text-sm text-muted-foreground">
9        {(props as any).origin} → {(props as any).destination} · {(props as any).departureTime}
10      </div>
11    </article>
12  ),
13};
14
15export const travelCatalog = createCatalog(travelDefinitions, renderers, {
16  catalogId: "copilotkit://travel-catalog",
17  includeBasicCatalog: true,
18});

Beide Hälften leben im Generative UI Starter-Projekt, verdrahtet und abgestimmt. search_flights in 'a2ui_fixed_schema.py', der FlightCard-Katalog in 'renderers.tsx'. Frage nach Flügen. Sieh die Karten in den Chat streamen.

Schaltflächen und andere interaktive Komponenten tragen eine Aktion im Schema. Der Basiskatalog verdrahtet sie mit onClick. Klick feuert ein Ereignis zurück an den Agenten über AG-UI. Der Agent entscheidet, was als Nächstes gerendert wird. Null Click-Handler.

Die Token-Mathematik

50 Kartentypen oder 500, der Agent sieht eine Funktion. Token pro Runde bleiben flach, während deine Komponentenbibliothek wächst.

Erweiterbar auf jedes Rendering-Framework, weil es nur JSON ist. Jeder Agent, der bereits AG-UI spricht, kann A2UI ab Tag Null steuern. Du berührst keinen Agent-Code, um das zu verdrahten.

Kompromiss: Das LLM besitzt das Layout. Die Ausgabe variiert von Lauf zu Lauf innerhalb deines Katalogs. Wenn du rechtliche Hinweise, Marketing-Oberflächen oder irgendetwas auslieferst, bei dem die genaue Pixelplatzierung zählt, ist das nicht dein Bereich.

Deklarativ ist das Muster, das für die lange Spur gebaut ist. Dashboards, Ergebnisse, Formulare, Karten, Widgets.

Wann man Deklarativ ausliefern sollte: Du hast mehr Anwendungsfälle als Zeit, sie vorzubauen. Dir liegen die Token-Ökonomie nach der Prototyp-Phase am Herzen.

Was kaputtgeht: Du hast eine benutzerdefinierte FlightCard gebaut. Jeder Flug wird als generische Karte des Basiskatalogs gerendert. Kein Fehler in der Konsole. Die CATALOG_ID auf dem Agenten und catalogId in createCatalog auf dem Frontend stimmen nicht überein. Das Frontend erkennt den Katalog nicht, den der Agent ansteuert, und fällt auf den Basiskatalog zurück. Gleiche die Strings auf beiden Seiten genau ab.

Muster 3: Offen – kein Katalog, keine Regeln

Das dritte Muster ist das entgegengesetzte Extrem. Kein Katalog. Kein Schema. Nur eine leere Leinwand.

In diesem Bereich leben zwei Untermuster.

MCP-Apps

Ein MCP-Server legt UI-Oberflächen frei, die der Agent steuert. Excalidraw ist das Beispiel, das bei mir hängengeblieben ist. Der Agent bekommt die volle Kontrolle über die Leinwand. Zeichnet Diagramme aus deinem Kontext. Besitzt jedes Pixel auf dem Board.

Das Client-Protokoll von Grund auf neu zu implementieren, ist mühsam, also liefert CopilotKit eine MCPAppsMiddleware aus. Hänge sie an deinen Agenten und richte sie auf einen beliebigen MCP-Apps-Server.

1const agent = new BuiltInAgent({
2  model: "openai/gpt-5.5",
3  prompt: "You are a helpful assistant.",
4}).use(
5  new MCPAppsMiddleware({
6    mcpServers: [{ type: "http", url: "https://mcp.excalidraw.com/mcp", serverId: "my-server" }],
7  }),
8);

Starte die MCP-Apps-Showcase und du buchst Flüge und reservierst Hotels im Chat-Fenster. Dieselbe Middleware, echte MCP-Server. Oder geh weiter.

Der KI-MCP-App-Builder lässt den Agenten eine brandneue App in eine E2B-Sandbox schreiben und rendert sie dann live.

0:45

HTML in der Sandbox

Der Agent schreibt rohes HTML. Deine App rendert es innerhalb einer Sandbox-iFrame, damit es die Sitzung nicht kapern kann.

Die Laufzeit registriert ein HTML-Rendering-Tool und liefert es über AG-UI an den Agenten. Der Agent ruft es mit dem Markup auf, das er haben will. Es gibt kein HTML-Tool, das auf der Agentenseite definiert werden müsste. Die Laufzeit injiziert es.

Die agentenseitige Anweisung leistet echte Arbeit:

1canvas_agent = LlmAgent(
2    name="canvas_agent",
3    model="gemini-3.5-flash",
4    instruction=(
5        "Du bist ein Visualisierungsassistent. Wenn der Benutzer darum bittet, "
6        "etwas zu sehen, zu zeichnen oder zu visualisieren, generiere ein interaktives HTML-UI. "
7        "Verwende nur Tailwind-Klassen. Keine externen Schriftarten. Halte dich an neutrale "
8        "Farben, es sei denn, der Benutzer nennt eine bestimmte."
9    ),
10)

Ohne diese Stilregeln greift das Modell standardmäßig auf die Ästhetik zurück, die in seinen Trainingsdaten in dieser Woche am lautesten war. Mit ihnen bekommst du meistens etwas in der Nähe deiner Marke. Nicht immer.

Das Problem der Markeninkonsistenz

Ich habe versucht, Offen als primäre UI für einen Agenten auszuliefern. Nach einer Woche wieder zurückgezogen.

„Neo-Brutalistisch" am Dienstag. „iOS-4-Klon" am Mittwoch. Stilregeln im Prompt schieben den Agenten in Richtung deiner Marke. Sie garantieren sie nicht. Die Marke hat sich ständig geändert. Das Produkt wirkte unseriös.

Offen ist nicht nutzlos. Es ist falsch angewendet.

Richtig für eine Sache: Wegwerf-Interaktionen, bei denen der Benutzer nicht darauf achtet, wie die Oberfläche aussieht, und sie nie wieder sehen wird. „Zeig mir, wie Elektronen funktionieren." „Gib mir ein komisches Balkendiagramm meiner letzten 10 Abfragen." „Visualisiere diese API-Antwort." Die Art von Dingen, die man in Google AI-Übersichten sieht.

Wann man Offen ausliefern sollte: Einmalige Abfragen. Wegwerf-Visualisierungen. Sandbox-Experimente. Niemals als primäre Oberfläche.

Was kaputtgeht: Der iFrame rendert. Buttons klicken nicht. Formulare senden nicht ab. Die Sandbox-Flags sind zu streng oder zu locker, sodass der Browser sie ablehnt. Setze das iFrame-Sandbox-Attribut auf allow-scripts und allow-forms. Nichts anderes. Niemals allow-same-origin.

So wählst du aus

Gehe den Entscheidungsbaum durch, bevor du Code schreibst.

Hat der Designer pixelgenaue Mockups für diesen Ablauf? Kontrolliert.

Dutzende von Kartentypen oder Widgets auszuliefern? Deklarativ.

Einmalige, wegwerfbare Visualisierung, die der Benutzer nie wieder sehen wird? Offen.

Kannst du dich nicht entscheiden? Standardmäßig Deklarativ. Upgrade auf Kontrolliert für die Top-3-Abläufe. Niemals Offen als Standard.

Wenn du bereits auslieferst und nicht sicher bist, wo du gelandet bist, zähle die Render-Tools. Ab 15 bist du im Kontrollierten und die Wand ist nah. Beginne diese Woche mit der Verkabelung von A2UI.

Drei Muster. Drei Wetten.

Kontrolliert setzt auf dich. Vorgebaute Komponenten, pixelgenau. Teuer ab 25 Stück.

Deklarativ setzt auf das Schema. Das Schema ist der Vertrag. Der Agent füllt es aus. Skaliert flach.

Offen setzt auf das Modell. Kein Katalog, kein Schema, rohes HTML. Gut für Einweg. Spröde für alles, das zweimal ausgeliefert wird.

Der Fehler ist nicht, das falsche Muster zu wählen. Es ist, nicht zu wissen, dass du eines gewählt hast.

Die meisten Teams standardmäßig auf Kontrolliert, weil das Framework standardmäßig auf Kontrolliert setzt. Sie stoßen bei 25 Komponenten an die Wand und greifen zu Offen, weil es in Demos überzeugend aussieht. Keines war eine Entscheidung. Beides war Abdrift.

Wähle mit Absicht. Passe das Muster an das Problem an. Kontrolliert für die Abläufe, die exakt sein müssen. Deklarativ für die lange Spur. Offen für das Wegwerfbare.

Open-Source Generative UI Agent-Vorlagen

Die Referenz für alle drei lebt im neuen Generative UI Agents-Bereich von awesome-llm-apps. Klone, was du brauchst. Entferne, was du nicht brauchst.

Ich werde mehr darüber veröffentlichen, wie man Agenten in der Produktion ausliefert, über AG-UI und die Muster, die skalieren. Folge mir @Saboo_Shubham_, um auf dem Laufenden zu bleiben.