Zum Inhalt springen
Archiv 20. Juni 2026

Google verbindet A2UI mit MCP Apps: Warum Agenten jetzt eine ernsthaftere UI-Schicht bekommen

Bei Agenten wird gerade viel über Tools, Discovery und Delegation gesprochen. Deutlich weniger Aufmerksamkeit bekommt eine andere Frage: Wie soll die Arbeit eigentlich beim Menschen ankommen? Also nicht als Textblock im Chat, sondern als Formular, Karte, Dashboard, Editor oder interaktive Oberfläche, die sich im Workflow wirklich benutzen lässt.

Genau an dieser Stelle ist Googles neuer Beitrag zu A2UI und MCP Apps interessant. Auf den ersten Blick wirkt das nach UI-Technik für Spezialisten. Ich glaube aber, dass hier eine wichtigere Schicht sichtbar wird: Agenten brauchen nicht nur bessere Modelle und Protokolle, sondern auch eine ernsthafte Oberflächenlogik zwischen Host, Tool und Nutzer.

Was Google konkret zeigt

Im Kern stellt Google drei Integrationsmuster vor, mit denen sich declarative A2UI-Oberflächen und MCP Apps kombinieren lassen:

  • A2UI über MCP: Ein MCP-Server liefert statt HTML oder reinem Text ein A2UI-JSON mit dem MIME-Typ application/a2ui+json, das der Host nativ rendert.
  • MCP Apps in A2UI: Eine A2UI-Oberfläche kann bei Bedarf eine eingebettete MCP-App in einem Iframe aufrufen, wenn die Interaktion komplexer oder stark individuell ist.
  • A2UI in MCP Apps: Eine MCP-App kann umgekehrt selbst einen A2UI-Renderer mitbringen, um auch in älteren oder nicht nativ A2UI-fähigen Hosts generative UI einzubetten.

Google beschreibt diese drei Muster ausdrücklich als Antwort auf einen bekannten Zielkonflikt. MCP Apps geben Entwicklern kreative Freiheit in einer Web-App im Iframe, bringen aber schnell Brüche bei Design, Performance und Sicherheitskapselung mit. A2UI liefert dagegen deklarative, nativ gerenderte Komponenten mit konsistenterem Look und engerer Sicherheitskontrolle, ist dafür aber begrenzter bei sehr individueller Client-Logik.

Die neue Botschaft lautet also nicht „ersetzt das eine durch das andere“, sondern: kombiniert beides gezielt je nach UI-Tiefe.

Warum das mehr ist als ein UI-Detail

Viele Agenten wirken heute noch erstaunlich textzentriert. Selbst wenn darunter komplexe Toolchains laufen, endet das Ergebnis oft in langen Antworten, Links oder bestenfalls einem simplen Widget. Für echte Arbeitsprozesse reicht das nur begrenzt.

Wer mit Agenten Formulare ausfüllt, Daten exploriert, Entscheidungen bestätigt, Varianten vergleicht oder längere Prozesse steuert, braucht eine bessere Schicht zwischen Modell und Mensch. Genau diese Schicht versucht Google hier systematischer aufzubauen.

Das ist für menzel.works interessant, weil wir gerade an vielen Stellen sehen, dass sich der Wettbewerb bei Agenten nach unten in den Stack verschiebt:

A2UI plus MCP Apps ergänzt dazu jetzt die Ausgabeschicht: also die Frage, wie solche Systeme nicht nur auf Tools zugreifen, sondern ihre Arbeit in benutzbare, sichere und integrierte Oberflächen übersetzen.

Der interessante Architekturpunkt: native UI, wenn möglich — Iframe, wenn nötig

Ich finde genau diese Mischlogik spannend. Die letzten Monate haben im Agentenmarkt oft so gewirkt, als müsste man sich entscheiden: entweder offene Web-App-Freiheit oder sichere, hostkontrollierte Standard-Komponenten.

Google schlägt nun einen pragmatischeren Weg vor:

  • Standardisierte, datengetriebene Oberflächen wie Formulare, Karten oder Ergebnis-Panels können deklarativ beschrieben und nativ gerendert werden.
  • Komplexe Spezialoberflächen wie Spiele, Editoren oder hochgradig individuelle Interaktionen dürfen weiter als MCP App im Iframe laufen.
  • Legacy- und Übergangsszenarien können A2UI sogar innerhalb einer MCP App mitnehmen, ohne dass der Host selbst A2UI sprechen muss.

Das klingt technisch, ist aber praktisch ziemlich wichtig. Denn damit wird generative UI nicht zu einer Alles-oder-nichts-Entscheidung, sondern zu einer abstufbaren Architekturfrage.

Warum Sicherheit und Portabilität hier nicht nur Beipackzettel sind

A2UI setzt auf deklarative JSON-Strukturen statt auf frei ausgeführten HTML-, CSS- und JavaScript-Code. Laut Projektseite dürfen Agenten nur vorab definierte Komponenten aus einem Katalog ansprechen, die der Host selbst rendert. Das reduziert die Gefahr, dass eine Agentenantwort einfach eine halbe Web-App einschleust.

Gleichzeitig verweist Google auf einen zweiten Punkt, den ich fast noch wichtiger finde: Portabilität. Wenn ein MCP-Server A2UI-Payloads liefert, kann derselbe inhaltliche UI-Intent in React, Flutter, Angular oder anderen Renderern nativ auftauchen, ohne dass der Server jede Oberfläche separat bauen muss.

Für agentische Workflows ist das enorm wertvoll. Sonst landet man schnell wieder in einer Welt, in der jede Host-App, jeder Chat-Client und jede Unternehmensoberfläche ihre eigene Sonderintegration braucht. A2UI ist deshalb nicht nur ein Sicherheitsversprechen, sondern auch ein Versuch, Generative UI organisatorisch skalierbarer zu machen.

Warum das auch gut zu MCP selbst passt

Die MCP-Apps-Dokumentation macht ziemlich klar, wofür Iframe-basierte Apps gut sind: komplexe Datenexploration, Konfigurationsoberflächen, Viewer, Monitoring und mehrstufige Workflows direkt in der Konversation. Genau dort stoßen reine Textantworten ohnehin an ihre Grenzen.

Googles A2UI-Beitrag verschiebt diese Logik nun einen Schritt weiter. Nicht jede interaktive Oberfläche muss gleich eine komplette eingebettete Web-App sein. Ein Teil davon lässt sich als hostnahe, sichere und native generative UI ausdrücken. Erst wenn die Interaktion tiefer, lokaler oder individueller wird, braucht es den iframe-basierten App-Modus.

Mit anderen Worten: MCP Apps bleiben wichtig, aber sie werden architektonisch eingeordnet statt allein gelassen.

Was daran strategisch spannend ist

Ich glaube, Google arbeitet hier an mehr als einem UI-Spielzeug. Wenn Agenten wirklich in produktive Software, interne Tools und Arbeitsoberflächen hineinwachsen sollen, dann entscheidet sich viel an genau dieser Schicht:

  • Wie konsistent fühlt sich der Agent im Host an?
  • Wie sicher ist die gerenderte Oberfläche?
  • Wie portabel sind einmal gebaute UI-Intents über verschiedene Clients hinweg?
  • Wie tief lässt sich Interaktivität einbauen, ohne jedes Mal eine neue Sonder-App zu bauen?

Das sind keine Nebensachen. Hier wird aus einem Agenten-Output langsam eine echte Arbeitsoberfläche.

Genau deshalb passt das Thema auch gut zu A2A. Dort geht es um Zusammenarbeit zwischen Agenten. Hier geht es um die gegenüberliegende Seite: wie Ergebnisse und Steuerung wieder sauber beim Menschen landen. Ein Agenten-Ökosystem braucht beides.

Wo ich trotzdem vorsichtig wäre

Noch ist das natürlich keine fertige Marktlösung. A2UI bleibt ein junges Ökosystem, MCP-Host-Support ist nicht überall gleich weit, und selbst gute deklarative Kataloge lösen nicht automatisch alle UX-Probleme. Je stärker Hosts nur ihre eigenen Komponenten zulassen, desto stärker verschiebt sich auch Kontrolle in die Plattform.

Außerdem bleibt die praktische Frage offen, wie viele Teams tatsächlich sauber zwischen „nativ renderbar“ und „Custom App nötig“ unterscheiden. Ohne gute Defaults kann aus der neuen Freiheit auch einfach zusätzliche Komplexität werden.

Mein Fazit

Google zeigt mit A2UI plus MCP Apps eine wichtigere Entwicklung als nur einen neuen UI-Baukasten. Hier entsteht gerade eine ernsthaftere Oberflächenschicht für Agenten: deklarativ, hostnah, sicherer und trotzdem offen genug, um komplexe Sonderfälle weiter als App einzubetten.

Wenn Agenten nicht bei netten Textantworten stehenbleiben sollen, braucht es genau solche Zwischenschichten. Denn produktive KI-Arbeit hängt nicht nur daran, was ein Agent denken oder ausführen kann. Sie hängt genauso daran, wie diese Arbeit für Menschen sichtbar, steuerbar und benutzbar wird.

Und genau deshalb ist diese Google-Meldung für mich interessanter als der nächste Modellvergleich.

Quellen

Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt und redaktionell bearbeitet.

Frage zu diesem Inhalt?
Kurz schreiben.
Kontakt