Warum UIAP?

Das Kernproblem

KI-Agenten brauchen mehr als nur “da ist ein Button”. Sie müssen wissen:

• Was der Button fachlich tut (video.create, nicht nur click)
• Ob sie ihn klicken dürfen (Risk-Level, Policy)
• Woran sie erkennen, dass die Aktion erfolgreich war (Route-Wechsel, Toast, Dialog-Schluss)

ARIA beschreibt Rollen, Zustände und Eigenschaften — aber nicht die Businesslogik. Playwright automatisiert Browser — versteht aber keinen Intent. MCP verbindet Tools — modelliert aber keinen Live-UI-Zustand.

Was bestehende Protokolle leisten

MCP (Model Context Protocol)

Standardisiert den Zugriff auf Tools und Wissen, nicht die direkte Steuerung laufender Web-UIs.

AG-UI

Eventbasiertes Protokoll für Agent-zu-App-Kommunikation. Am nächsten dran, aber:

• Löst das Kommunikationsproblem, nicht das volle UI-Verständnisproblem
• Kein kanonischer Katalog für UI-Elemente, Rollen, Risiken oder Erfolgs-Signale
• Definiert nicht, wie ein Agent ein belastbares Seitenmodell bekommt

WebDriver / WebDriver BiDi

Browser-Fernsteuerung — die Ausführungsschicht darunter, nicht der semantische Vertrag darüber.

ARIA / Accessibility

Semantische Beschreibung von UI-Elementen — wichtige Basis, aber keine vollständige Lösung für agentische Steuerung.

Die Lücke

Es gibt noch keinen reifen, breit akzeptierten “UI Control Protocol”-Standard für KI-Agenten in bestehenden Webanwendungen, der Semantik, Aktionen, Feedback und Sicherheitsregeln aus einem Guss verbindet.

Was UIAP liefert

UIAP (UI Agent Protocol) ist ein standardisiertes Agent-Interface für UIs. Anwendungen teilen dem KI-Agenten damit strukturiert mit, welche Elemente, Aktionen, Zustände, Risiken und Erfolgs-Signale es gibt — damit der Agent nicht blind im DOM herumstochert.

UIAP steht nicht gegen MCP oder AG-UI, sondern ist adapterfähig:

• MCP-Adapter: UIAP-Capabilities oder Workflows als MCP Tools/Resources exponieren
• AG-UI-Adapter: UIAP-Events in AG-UI-Events spiegeln
• WebDriver/BiDi-Adapter: Für externe Browser-Ausführung