Foto von Hal Gatewood auf Unsplash Source

Fragen Sie einen KI-Agenten nach dem besten Flug von München nach Lissabon, und Sie bekommen eine Textwand: Flugzeiten, Preise, Umsteigeverbindungen, alles als Fließtext. Mit A2UI bekommt derselbe Agent die Fähigkeit, eine Vergleichstabelle mit Buchungs-Buttons zurückzugeben. Googles Agent Development Kit (ADK) war das erste große Framework, das dieses Protokoll nativ integriert hat.

Das Problem ist offensichtlich, sobald man es benennt: Textbasierte Agenten-Interaktion funktioniert für Fragen und Antworten, aber nicht für strukturierte Eingaben. Wenn ein Reise-Agent Abflugdatum, Ziel, Budget und Sitzplatzpräferenz braucht, dauert das per Chat acht Nachrichten hin und her. Mit A2UI schickt der Agent ein einzelnes Formular, der Nutzer füllt es aus, fertig. Google hat A2UI im Dezember 2025 als Open-Source-Projekt vorgestellt, und ADK hatte als erstes Framework native Unterstützung.

Weiterlesen: Google ADK: Das Agent-Framework mit nativem MCP und A2A

Wie A2UI funktioniert: Deklaratives UI statt ausführbarer Code

Das zentrale Designprinzip von A2UI ist Sicherheit durch Deklarativität. Agenten senden kein HTML, kein JavaScript und keinen ausführbaren Code an den Client. Sie senden strukturiertes JSON, das beschreibt, welche UI-Komponenten aus einem vorab genehmigten Katalog gerendert werden sollen.

Ein vereinfachtes A2UI-Beispiel mit Datumsauswahl und Submit-Button:

{
  "surfaceUpdate": {
    "components": [
      {
        "id": "departure-date",
        "component": {
          "DateTimeInput": {
            "label": { "literalString": "Abflugdatum" },
            "value": { "path": "/booking/date" }
          }
        }
      },
      {
        "id": "submit-btn",
        "component": {
          "Button": {
            "label": { "literalString": "Flüge suchen" },
            "action": "submit"
          }
        }
      }
    ]
  }
}

Die Client-Anwendung pflegt einen Komponentenkatalog: eine Sammlung vertrauenswürdiger, vorab genehmigter UI-Widgets wie Card, Button, TextField, DateTimeInput und Table. Der Agent kann nur Komponenten anfordern, die im Katalog existieren. Fordert ein Agent etwas an, das nicht im Katalog steht, ignoriert der Client die Anfrage. Keine beliebige Code-Ausführung, keine UI-Injection-Schwachstellen.

Das ist der entscheidende Unterschied zu einem LLM, das direkt React- oder HTML-Code generiert. Bei A2UI ist der Agent auf sichere, deklarative Spezifikationen beschränkt. Bei direkter Code-Generierung vertraut man darauf, dass ein LLM keinen schadhaften Output produziert. In einer Produktionsumgebung, besonders unter den Anforderungen der DSGVO und des EU AI Act, ist das kein akzeptables Risiko.

Data Binding und Streaming

A2UI-Komponenten binden an ein gemeinsames Datenmodell über Pfadreferenzen. Wenn ein Nutzer das Abflugdatum oben ausfüllt, aktualisiert sich der Wert unter /booking/date im Datenmodell, und alle anderen Komponenten, die diesen Pfad referenzieren, aktualisieren sich automatisch. Dieses reaktive Binding ermöglicht mehrstufige Formulare, bei denen spätere Felder von früheren Eingaben abhängen.

Das Protokoll nutzt JSON Lines (JSONL) Streaming. Clients rendern Komponenten inkrementell, während der Agent sie generiert. Nutzer sehen die Oberfläche in Echtzeit entstehen, statt auf die vollständige Antwort zu warten.

Plattformübergreifend ab Werk

Weil A2UI ein deklaratives Format ist, rendert dieselbe Agent-Antwort auf jeder Plattform identisch. Google liefert bereits Renderer für Flutter, Lit (Web Components) und Angular. CopilotKit hat über seine AG-UI-Integration React-Kompatibilität geschaffen. Ein Agent, mehrere Frontends, null Code-Änderungen.

ADK und A2UI: Natives Rendering ohne Zusatzaufwand

Google ADK war das erste große Agent-Framework mit A2UI als First-Class-Feature. Die eingebaute Entwickler-UI (adk web) rendert A2UI-Komponenten nativ. Das bedeutet: Sie können interaktive Agent-UIs testen, ohne ein eigenes Frontend zu bauen.

So sieht das in der Praxis aus. Ein ADK-Agent gibt A2UI-Teile zusammen mit seiner Textantwort zurück:

from google.adk.agents import LlmAgent

restaurant_agent = LlmAgent(
    model="gemini-2.0-flash",
    name="restaurant_finder",
    description="Findet Restaurants und zeigt Ergebnisse als interaktive Karten",
    instruction="""
    Bei Restaurantempfehlungen: Ergebnisse als A2UI Card-Komponenten
    mit Name, Bewertung, Küche und Reservierungs-Button zurückgeben.
    """,
    tools=[search_restaurants, get_reviews]
)

ADK Web erkennt A2UI-formatierte Teile automatisch und rendert sie als native UI-Komponenten. Keine zusätzliche Konfiguration nötig. Der Agent kann Diagramme statt Datenbeschreibungen zurückgeben, Formulare statt sequentielle Fragen, Vergleichstabellen statt Aufzählungen.

ADK liefert den A2UI v0.8 Standard-Komponentenkatalog vorinstalliert mit Komponenten für Textanzeige, Nutzereingabe, Navigation, Datenvisualisierung und Layout. Der Katalog lässt sich mit eigenen Komponenten erweitern.

Mit dem kürzlich erschienenen ADK v2.0 Alpha und seinen graphbasierten Workflows wird A2UI noch mächtiger. Ein Workflow kann Nutzereingaben über A2UI-Formulare sammeln, durch bedingte Logik routen, an mehrere Agenten verteilen und aggregierte Ergebnisse als A2UI-Karten präsentieren.

Weiterlesen: MCP und A2A: Protokolle für KI-Agent-Kommunikation
Weiterlesen: MCP Apps: Wie KI-Agenten echte Benutzeroberflächen im Chat rendern

Toolset-Authentifizierung: Wenn Agenten Zugangsdaten brauchen

Agenten, die auf echte APIs zugreifen, brauchen Credentials. Der Kalender-Agent braucht OAuth-Tokens. Der CRM-Agent braucht API-Keys. Der Payment-Agent braucht Service-Account-Credentials. ADKs Toolset-Authentifizierungssystem regelt das, ohne Secrets im Agent-Code hardzucoden.

Das AuthCredential-System

ADK unterstützt fünf Credential-Typen, die die gängigsten API-Authentifizierungsmuster abdecken:

  • API_KEY: Einfache Schlüssel-Wert-Authentifizierung für Dienste wie Wetter-APIs oder Webhook-Endpunkte
  • HTTP: Basic Auth oder Bearer-Token-Schemata für REST-APIs
  • OAUTH2: Vollständige OAuth 2.0 Flows mit Client-ID/Secret und Nutzereinwilligung, kompatibel mit Identitätsanbietern wie Google, Okta und Auth0
  • OPEN_ID_CONNECT: OIDC-Authentifizierung auf Basis von OAuth 2.0 zur Identitätsverifizierung
  • SERVICE_ACCOUNT: Google Cloud Service-Account-Credentials mit automatischem Token-Tausch

So konfiguriert man OAuth2-Authentifizierung für ein OpenAPI-Toolset:

from google.adk.tools.openapi_tool import OpenAPIToolset
from google.adk.auth import AuthScheme, AuthCredential

auth_scheme = AuthScheme(
    auth_type="OAUTH2",
    oauth2={
        "authorization_url": "https://accounts.google.com/o/oauth2/v2/auth",
        "token_url": "https://oauth2.googleapis.com/token",
        "scopes": ["https://www.googleapis.com/auth/calendar"]
    }
)

auth_credential = AuthCredential(
    auth_type="OAUTH2",
    oauth2={"client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET"}
)

calendar_tools = OpenAPIToolset(
    spec_url="https://www.googleapis.com/discovery/v1/apis/calendar/v3/rest",
    auth_scheme=auth_scheme,
    auth_credential=auth_credential
)

Das Framework übernimmt den Token-Austausch automatisch. Wenn der Agent einen API-Call macht, der Authentifizierung erfordert, erkennt ADK den Bedarf, startet den OAuth-Flow, handhabt den Redirect, speichert den Token und wiederholt den ursprünglichen Call mit gültigem Credential.

MCP-Authentifizierung

Dasselbe Authentifizierungssystem funktioniert auch für MCP-Toolsets. Beim Verbinden mit einem MCP-Server, der Authentifizierung erfordert, übergibt man dieselben auth_scheme und auth_credential:

from google.adk.tools.mcp import MCPToolset

github_tools = MCPToolset.from_server(
    connection_params=StdioServerParameters(
        command="npx",
        args=["-y", "@modelcontextprotocol/server-github"]
    ),
    auth_scheme=github_auth_scheme,
    auth_credential=github_auth_credential
)

Das vereinheitlicht die Authentifizierung über eingebaute Tools, OpenAPI-Tools und MCP-Tools hinweg. Ein Credential-System, drei Tool-Typen. In Multi-Agent-Architekturen, wo Eltern-Agenten an Unter-Agenten mit verschiedenen Tool-Anforderungen delegieren, können Authentifizierungs-Tokens durch die Agenten-Hierarchie durchgereicht werden.

Credentials in der Produktion

ADKs Dokumentation ist unmissverständlich: Rohtext-Access-Tokens in InMemorySessionService haben in der Produktion nichts verloren. Die empfohlene Vorgehensweise ist Verschlüsselung vor der Datenbankspeicherung oder die Nutzung eines dedizierten Secret-Managers wie Google Cloud Secret Manager oder HashiCorp Vault.

Für Teams, die Agenten mit Zugriff auf Finanzdaten oder Zahlungsabwicklung bauen, ist das unter DSGVO-Anforderungen keine Option, sondern Pflicht. Das Framework liefert die Authentifizierungs-Infrastruktur, aber produktionsreifes Secret-Management liegt in der eigenen Verantwortung.

A2UI im Einsatz: Wo es wirklich zählt

A2UI zeigt seinen Wert dort, wo textbasierte Interaktion Reibung erzeugt.

Enterprise-Dashboards. Ein Analytics-Agent, der Ihr Data Warehouse abfragt und ein A2UI-Diagramm zurückgibt, ist nützlicher als einer, der das Diagramm in Worten beschreibt. Gemini Enterprise nutzt A2UI bereits für KPI-Karten, Vergleichstabellen und Trendvisualisierungen in Google Workspace.

Mehrstufige Workflows. Eine Restaurantbuchung per Chat-Agent dauert 6-8 Nachrichten (Küche? Ort? Personenzahl? Datum? Uhrzeit? Budget?). Mit A2UI schickt der Agent ein einziges Formular mit allen Feldern. Ein Klick, erledigt. Googles eigenes Restaurant-Finder-Sample demonstriert genau dieses Muster.

Agenten-Marktplätze. Wenn Agenten verschiedener Anbieter UIs für Nutzer bereitstellen müssen, bietet A2UI ein gemeinsames Format. Agent A liefert eine Flugkarte, Agent B eine Hotelkarte, Agent C eine Mietwagenkarte. Der Client rendert alle drei konsistent, weil sie denselben Komponentenkatalog verwenden.

Das Protokoll ist bei v0.8 und auf dem Weg zu einer stabilen v1.0. OpenClaw hat A2UI integriert, CopilotKit unterstützt es über AG-UI, und Flutters GenUI SDK nutzt es für plattformübergreifende generative Oberflächen. Das Ökosystem ist noch jung, aber das Adoptionsmuster ähnelt dem von MCP vor 12 Monaten: wenige Schlüsselintegrationen, die vor der Welle Momentum aufbauen.

Weiterlesen: KI-Agent-Frameworks im Vergleich: LangGraph, CrewAI, AutoGen

Erste Schritte: Vom Text-Agent zum A2UI-Agent

Wer mit ADK baut und A2UI ausprobieren will, braucht fünf Minuten:

# A2UI-Repo mit Beispiel-Agenten klonen
git clone https://github.com/google/A2UI.git
export GEMINI_API_KEY="your_key_here"

# ADK Restaurant-Finder-Agent starten
cd A2UI/samples/agent/adk/restaurant_finder && uv run .

# In einem separaten Terminal: Lit Web-Client starten
cd A2UI/samples/client/lit/shell && npm install && npm run dev

Damit haben Sie einen funktionierenden A2UI-Agenten mit kartenbasierten Restaurant-Ergebnissen. Von dort aus können Sie die Agent-Instruktionen ändern, den Komponentenkatalog erweitern oder Ihren eigenen ADK-Agenten einsetzen.

Für Teams, die bereits ADK-Agenten betreiben: A2UI ist additiv. Bestehende Textantworten funktionieren weiterhin. A2UI-Komponenten sind eine optionale Erweiterung, die Sie schrittweise einführen können, Agent für Agent, ohne die gesamte Anwendung umzuschreiben.

Häufig gestellte Fragen

Was ist A2UI und wie funktioniert es?

A2UI (Agent-to-User Interface) ist ein deklaratives Protokoll, das KI-Agenten ermöglicht, interaktive UI-Komponenten wie Buttons, Karten, Formulare und Diagramme statt reinem Text zu generieren. Der Agent sendet strukturiertes JSON, das beschreibt, welche Komponenten aus einem vorab genehmigten Komponentenkatalog gerendert werden sollen. Es ist sicher by Design, da Agenten keinen ausführbaren Code senden können.

Wie integriert Google ADK A2UI?

Google ADK integriert den A2UI v0.8 Standard-Komponentenkatalog und rendert A2UI-Komponenten nativ in seiner eingebauten Web-UI (adk web). ADK-Agenten können A2UI-formatierte Teile zusammen mit Textantworten zurückgeben, und das Framework erkennt und rendert sie automatisch als interaktive Komponenten.

Welche Authentifizierungsmethoden unterstützt Google ADK?

ADK unterstützt fünf Credential-Typen: API-Keys, HTTP Basic/Bearer-Tokens, OAuth 2.0, OpenID Connect und Google Cloud Service Accounts. Diese funktionieren über eingebaute Tools, OpenAPI-Toolsets und MCP-Toolsets hinweg. Das Framework übernimmt Token-Austausch-Flows automatisch.

Was ist der Unterschied zwischen A2UI und AG-UI?

A2UI ist Googles deklaratives Protokoll für agentengesteuerte UIs mit Fokus auf ein Komponentenkatalog-Modell. AG-UI ist CopilotKits Protokoll für Agent-UI-Kommunikation. Beide sind kompatibel: CopilotKit unterstützt A2UI-Rendering über seine AG-UI-Integration.

Ist A2UI DSGVO-konform einsetzbar?

A2UI als deklaratives Protokoll sendet keine ausführbaren Daten, was Sicherheitsrisiken minimiert. Für DSGVO-Konformität müssen Teams dennoch sicherstellen, dass Nutzerdaten in A2UI-Formularen verschlüsselt übertragen und gespeichert werden. ADK empfiehlt für die Produktion dedizierte Secret-Manager wie Google Cloud Secret Manager oder HashiCorp Vault.