TL;DR: AG-UI ist ein offenes Protokoll, über das ein KI-Agent mit einer Oberfläche spricht: Er streamt Text, meldet Werkzeugaufrufe und deren Ergebnisse und kann für eine Freigabe anhalten. Für .NET gibt es seit September Pakete in Version 1.0, das Microsoft Agent Framework liefert die Server-Seite dazu. Unsere Demo mit einem lokalen Modell zeigt: Streaming, Werkzeugaufrufe und das Anhalten vor einer Bestellung funktionieren. Die Fortsetzung nach der Freigabe hat mit den veröffentlichten Paketen nicht funktioniert, der Server hat die Bestellung dann sicher abgelehnt. Der wichtigste Befund kam vom Modell: Es meldete die Bestellung als erledigt, obwohl das Werkzeug sie abgelehnt hatte. Eine Agenten-Oberfläche muss deshalb zeigen, was das Werkzeug meldet, nicht nur, was das Modell schreibt.

Was „Agentic UI“ meint

Die meisten KI-Assistenten in Unternehmen sehen gleich aus: ein Chatfenster, eine Frage, eine Antwort. Was der Agent dazwischen tut, welche Werkzeuge er aufruft, welche Daten er liest, was er ändern will, bleibt unsichtbar. Für eine Auskunft reicht das. Sobald ein Agent bestellt, bucht oder löscht, reicht es nicht mehr.

Agentic UI heißt: Die Oberfläche zeigt, was der Agent gerade tut, und lässt den Menschen an den richtigen Stellen eingreifen. Dafür braucht die Oberfläche mehr als den fertigen Antworttext. Sie braucht einen Strom von Ereignissen: Lauf beginnt, Werkzeug wird aufgerufen, Ergebnis kommt zurück, Text entsteht, Freigabe nötig, Lauf endet.

AG-UI: das Protokoll zwischen Agent und Oberfläche

AG-UI (Agent-User Interaction Protocol) ist ein offenes, ereignisbasiertes Protokoll. Es stammt aus dem Umfeld von CopilotKit und wird inzwischen von mehreren Agenten-Frameworks unterstützt, darunter das Microsoft Agent Framework. Der Ablauf ist schlicht: Die Oberfläche schickt eine HTTP-POST-Anfrage mit dem bisherigen Verlauf, der Agent antwortet mit einem Strom von Server-Sent Events.

Die wichtigsten Ereignisse:

Ereignis Bedeutung
RUN_STARTED / RUN_FINISHED Ein Lauf beginnt bzw. endet, mit Ergebnis success oder interrupt
TEXT_MESSAGE_START / _CONTENT / _END Antworttext, Stück für Stück
TOOL_CALL_START / _ARGS / _END Der Agent ruft ein Werkzeug auf, mit Argumenten
TOOL_CALL_RESULT Was das Werkzeug zurückgemeldet hat
STATE_SNAPSHOT / STATE_DELTA Gemeinsamer Zustand zwischen Agent und Oberfläche

AG-UI ersetzt dabei kein anderes Protokoll, es ergänzt sie:

flowchart LR
    U[Oberfläche] <-->|AG-UI| A[KI-Agent]
    A <-->|MCP| W[Werkzeuge und Daten]
    A <-->|A2A| B[Andere Agenten]
    style U stroke:#cc171a

MCP verbindet den Agenten mit Werkzeugen und Daten, A2A Agenten untereinander, AG-UI den Agenten mit dem Menschen. Wie MCP-Server in .NET entstehen, beschreibt unser Praxisleitfaden für eigene MCP-Server.

Stand in .NET

Stand 1. November 2026 sieht die .NET-Seite so aus:

Wer heute baut, verwendet also stabile Protokoll-Pakete und eine Server-Anbindung in der Vorschau. Für einen Versuch ist das in Ordnung, für die Produktion gehört das in die Risikobewertung. Was sich mit .NET 10 als LTS geändert hat, steht in unserem Beitrag zu .NET 10.

Unser Versuch: ein Lager-Assistent

Für die Demo haben wir einen Assistenten für eine erfundene Firma gebaut, die Beispielwerk GmbH. Er hat zwei Werkzeuge:

Dahinter läuft ein kleines lokales Sprachmodell (Qwen3.5 mit 2 Milliarden Parametern) auf einem Rechner ohne GPU, hinter einer OpenAI-kompatiblen Schnittstelle. Die Wahl ist bewusst: Keine Daten verlassen das Haus, und ein kleines Modell zeigt Schwächen deutlicher als ein großes. Die Hardware ist das absolute Minimum, Antwortzeiten aus diesem Aufbau sagen deshalb nichts über einen produktiven Einsatz. Warum ein lokales Modell trotzdem eine Option ist, beschreibt unsere Seite zu lokaler KI.

Der Server ist erstaunlich kurz. Der Kern (gekürzt):

builder.Services.AddAGUIServer();
// Rückfragen brauchen einen Sitzungsspeicher (laut Framework experimentell)
builder.Services.AddKeyedSingleton<AgentSessionStore>("Beispielwerk", new InMemoryAgentSessionStore());

AITool[] werkzeuge =
[
    AIFunctionFactory.Create(Lagerbestand, name: "lagerbestand"),
    // Schreibende Aktion: läuft erst, wenn ein Mensch zustimmt
    new ApprovalRequiredAIFunction(
        AIFunctionFactory.Create(NachbestellungAnlegen, name: "nachbestellung_anlegen")),
];

AIAgent agent = modell.AsAIAgent(name: "Beispielwerk", instructions: "…", tools: werkzeuge);
app.MapAGUIServer("/agent", agent);

Die Werkzeuge laufen auf dem Server. Die Oberfläche ruft sie nie selbst auf, sie sieht nur die Ereignisse. Als Oberflächen haben wir einen Konsolen-Client und eine kleine Blazor-Seite gebaut, beide mit AGUIChatClient aus dem Paket AGUI.Client.

Was funktioniert hat

Die Lagerabfrage. Auf „Wie viele Taktgeber M (BW-4420) haben wir am Lager?“ lieferte der Server diese Ereignisfolge:

  1. RUN_STARTED
  2. TOOL_CALL_START mit lagerbestand, TOOL_CALL_ARGS mit {"artikelnummer":"BW-4420"}
  3. TOOL_CALL_RESULT: „17 Stück von BW-4420 am Lager.“
  4. acht TEXT_MESSAGE_CONTENT-Stücke: „Am Lager haben wir 17 Stück Taktgeber M (BW-4420).“
  5. RUN_FINISHED mit success

Die Oberfläche kann damit zeigen, welches Werkzeug mit welchen Argumenten lief und was es zurückgab, bevor der Antworttext beginnt. Genau diese Transparenz fehlt in einem reinen Chatfenster.

Das Anhalten vor der Bestellung. Auf „Bestelle 20 Stück BW-4475 nach.“ rief das Modell nachbestellung_anlegen auf. Der Server führte das Werkzeug nicht aus, sondern beendete den Lauf mit einer Unterbrechung:

{"type":"RUN_FINISHED","outcome":{"type":"interrupt","interrupts":[{
  "reason":"tool_call",
  "message":"Approval required for tool call: nachbestellung_anlegen",
  "responseSchema":{"type":"object","properties":{"approved":{"type":"boolean"}}}}]}}

Die Oberfläche zeigt daraufhin den geplanten Aufruf mit Artikel und Menge und die Knöpfe „Freigeben“ und „Ablehnen“. Das Prinzip kennen Sie aus unserem Beitrag über MCP Elicitation: Die Entscheidung trifft der Mensch in der Oberfläche, nicht das Modell im Chat.

Eine gefälschte Freigabe. Wir haben eine Freigabe mit erfundener ID in einem neuen Gesprächsverlauf geschickt. Der Server hat nichts ausgeführt, sondern erneut angehalten.

Was nicht funktioniert hat

Nach einer echten Freigabe schickt die Oberfläche einen zweiten Lauf mit der Antwort auf die Unterbrechung. Der Server sollte dann bestellen. In unserem Test hat er stattdessen dieses Ergebnis gemeldet:

Tool call invocation rejected. No approval response was provided for this approval required tool call.

Das passierte mit dem .NET-Client genauso wie mit handgebauten HTTP-Anfragen nach Protokoll, mit AGUI.Server 1.0.0 genauso wie mit 1.0.1. Im Log des Servers steht dazu eine Ausnahme: Er kann die Antwort auf die Unterbrechung nicht in seiner Sitzung speichern. Microsofts Beispiel für Rückfragen baut gegen den Quellcode im Repository, nicht gegen die veröffentlichten Pakete. Unser Stand ist deshalb: Mit den Paketen von NuGet (Stand 1. November 2026) haben wir die Fortsetzung nach einer Freigabe nicht zum Laufen gebracht. Das kann sich mit der nächsten Vorschau ändern.

Der Fehler hat eine gute Seite: Ohne erkannte Freigabe bestellt der Server nicht. Er scheitert sicher. Ein Fehler, der zur Ausführung ohne Freigabe geführt hätte, wäre deutlich schlimmer gewesen.

Der wichtigste Befund: Das Modell meldet Erfolg

Interessant wurde es beim Antworttext nach der abgelehnten Bestellung. Der Ereignisstrom enthielt zuerst das Ergebnis des Werkzeugs, die Ablehnung. Danach schrieb das Modell:

Ich habe eine Nachbestellung von 20 Stück BW-4475 angesetzt.

Das stimmte nicht. Bestellt war nichts. Und es kam noch deutlicher: Bei „Ablehnen“ schrieb das Modell denselben Satz. Das ist eine Halluzination im Wortsinn, eine Erfolgsmeldung ohne Grundlage, obwohl die Grundlage im selben Verlauf stand.

Ein kleines Modell zeigt das besonders deutlich, große Modelle sind dagegen aber nicht gefeit. In unserem Elicitation-Test meldete der Agent in der Copilot CLI drei gelöschte Einträge, einer davon bestand noch.

Für die Oberfläche folgt daraus eine klare Regel: Was ein Werkzeug gemeldet hat, wird angezeigt, und zwar getrennt vom Text des Modells. In unserer Blazor-Seite stehen Werkzeugaufruf und Werkzeugergebnis deshalb als eigene, farblich abgesetzte Karten im Verlauf. Die Antwort des Modells trägt die Überschrift „Modell schreibt“. Wer dann „angesetzt“ liest und direkt darüber „rejected“, sieht den Widerspruch. In einem reinen Chatfenster sähe er nur „angesetzt“.

AG-UI macht diese Trennung leicht, weil TOOL_CALL_RESULT ein eigenes Ereignis ist. Die Oberfläche muss es nur auch anzeigen.

Worauf es bei einer Agenten-Oberfläche ankommt

Aus der Demo ergeben sich fünf Punkte für eigene Projekte:

  1. Werkzeugergebnisse sichtbar machen. Nicht als Fließtext des Modells, sondern als eigenes Element. Bei schreibenden Aktionen am besten mit Status: ausgeführt, abgelehnt, fehlgeschlagen.
  2. Freigaben im Server erzwingen. Die Oberfläche zeigt den Dialog, aber der Server entscheidet, ob ein Werkzeug läuft. Eine Oberfläche, die selbst „freigegeben“ behauptet, ist keine Prüfung.
  3. Freigaben mit Kontext. Artikel, Menge, Lieferant, Betrag. Ein „Darf ich?“ ohne Details wird durchgeklickt.
  4. Werkzeuge nach Wirkung trennen. Lesen ohne Rückfrage, Schreiben mit. Wie wir festlegen, was ein Agent allein darf, beschreibt unsere Seite zu KI-Agenten.
  5. Schreibaktionen unabhängig prüfen. Nach einer Bestellung liest eine eigene Abfrage nach, ob sie existiert. Die Erfolgsmeldung des Modells ist kein Beleg.

Die Rechte des Agenten selbst bleiben davon unberührt: Ein Agent, der über die Oberfläche nur bestellen soll, braucht ein Konto, das nur bestellen kann. Wie wir das an der eigenen Infrastruktur umsetzen, steht in unserem Beitrag über Grenzen für KI-Agenten.

Für wen sich das heute lohnt

Ja, ausprobieren, wenn Sie bereits einen Agenten haben, der in einem Chatfenster steckt, und sichtbar machen wollen, was er tut. Streaming und Werkzeugereignisse funktionieren mit den veröffentlichten Paketen.

Ja, vor allem, wenn Sie eine bestehende .NET-Anwendung haben, auch auf .NET Framework. Der AG-UI-Client lässt sich dort einbinden, der Agent läuft getrennt auf einem Server. Die Anwendung muss dafür nicht migriert werden. Wie wir bestehende Software erweitern, beschreibt unsere Seite zur Modernisierung.

Noch warten, wenn Freigaben vor schreibenden Aktionen für Sie zwingend sind und Sie sich auf veröffentlichte Pakete stützen müssen. Hier lohnt ein neuer Test mit der nächsten Vorschau der Server-Anbindung.

Häufige Fragen

Ist AG-UI ein Microsoft-Protokoll? Nein. AG-UI ist ein offenes Protokoll aus dem Umfeld von CopilotKit. Das Microsoft Agent Framework ist eines von mehreren Frameworks, die es unterstützen.

Brauche ich AG-UI, wenn ich schon MCP nutze? Die beiden decken verschiedene Strecken ab. MCP verbindet den Agenten mit Werkzeugen, AG-UI den Agenten mit der Oberfläche. Ein Agent kann über MCP ein ERP abfragen und das Ergebnis über AG-UI anzeigen.

Funktioniert das nur mit Blazor? Nein. AG-UI ist HTTP und Server-Sent Events. Jede Oberfläche, die das kann, kann einen AG-UI-Agenten ansprechen: Web, Desktop, mobil. In .NET gibt es den fertigen Client, auch für .NET Framework.

Brauche ich dafür ein Cloud-Modell? Nein. Unsere Demo lief vollständig lokal mit einem offenen Modell. Für den produktiven Einsatz braucht ein lokales Modell aber passende Hardware.

Fazit

AG-UI schließt eine Lücke zwischen Agent und Mensch: Die Oberfläche sieht nicht nur den fertigen Text, sondern jeden Werkzeugaufruf, jedes Ergebnis und jede nötige Freigabe. In .NET sind die Protokoll-Pakete stabil, die Server-Anbindung im Microsoft Agent Framework ist noch eine Vorschau. Streaming und Werkzeugereignisse funktionieren heute, die Fortsetzung nach einer Freigabe hat in unserem Test nicht funktioniert und ist dabei sicher gescheitert.

Der wichtigste Satz aus der Demo stammt aber nicht vom Protokoll, sondern vom Modell: „Ich habe eine Nachbestellung angesetzt“, direkt unter der Ablehnung. Eine gute Agenten-Oberfläche zeigt beides nebeneinander. Wenn Sie einen Agenten an Ihre Anwendungen anbinden und sichtbar machen wollen, was er tut, sprechen Sie uns an. Wie wir dabei selbst mit KI arbeiten, beschreibt unsere Seite So arbeiten wir mit KI.