Agentic UI — Interface wenn der Agent die Arbeit macht
AGENTIC UI — INTERFACE & AUTONOMIE

Agentic UI

Wer handelt, wer beobachtet?

◆ THINKING analysiere Transkript-Struktur …
⬡ TOOL    generate_show_notes({ episode_id: 47 })
✓ RESULT  show_notes_html: 1.2kb, 5 Kapitel
⬡ TOOL    generate_blog_article({ style: "seo" })
█ TEXT    KI in der Podcast-Produktion: Was heu
$ COST    Turn 6 · $0.038 · 2.4s
01 — DIE GRUNDFRAGE

Klassische UI ist Input → Response.
Agentic UI ist anders.

In klassischer UI gibt der Mensch Eingaben, die App antwortet sofort. Klick → Feedback. Submit → Result. Der Mensch ist der Akteur, die App ist passiv.

In Agentic UI dreht sich das um. Du gibst den Impuls — die Intention. Der Agent arbeitet. Das dauert Sekunden, manchmal Minuten. Du schaust zu. Du kannst eingreifen. Das Ergebnis kommt in Teilen, nicht auf einmal.

Das verändert alles: Interaktionsstruktur, Controls, Zeitwahrnehmung, Feedback-Loops. Ein Spinner der 40 Sekunden dreht ist kein UI-Problem — es ist ein Architektur-Problem. Wer Agenten baut muss anders über Interface nachdenken.

„Der Agent ist kein Submit-Button. Er ist ein sichtbarer Prozess mit eigenem Rhythmus."
● RUNNING Turn 6 / 8 generate_blog_article $0.038 42.1s
●
THINKING SICHTBAR
Thinking-Blöcke live gestreamt. 80 Zeichen, dann Update. Der Mensch sieht nicht nur das Ergebnis — er sieht den Weg.
●
TOOL-CALLS INLINE
Toolname + Input + Result — immer sichtbar. Auf 500 Zeichen gekürzt aber da. Kein Black-Box-Gefühl.
●
KOSTEN LIVE
Cost per Turn, kumulativ. Nicht nach dem Run — während er läuft. Der User weiss was er ausgibt.
02 — STREAMING IST VORAUSSETZUNG, NICHT FEATURE

Zwei Transporte. Dieselbe Abstraktion.

Alle guten Agentic UIs streamen live. Das ist keine optionale Verbesserung — es ist der Unterschied zwischen einem Agenten der dem User vertraut und einem der 40 Sekunden Angst erzeugt.

1
SSE (Server-Sent Events)
Direktes Streaming im HTTP-Response. Kein WebSocket-Setup. Ideal für request-synchrone Flows. Header: Content-Type: text/event-stream. Client liest via Fetch ReadableStream. Einfach, HTTP-standard, keine Infrastruktur.
2
Turbo Streams + ActionCable
Agent läuft als Background-Job (Solid Queue). Schreibt asynchron in Turbo-Channel. Browser subscribed via turbo_stream_from @session_id. Partial HTML wird live in DOM gepatcht. Richtig für lange Jobs die nach dem HTTP-Request weiterlaufen.
∞
ClaudeStreamingBridge
Eine Abstraktion über beide Transporte — SseWriter, TurboWriter, MockWriter, AgentRunWriter. Dieselbe Writer-Schnittstelle, anderer Transport. Der Agent-Code ändert sich nicht wenn der Transport wechselt.
03 — CONTROLS

Prompt oder Knöpfe? Beides — aber für verschiedene Dinge.

Der häufigste Fehler in Agentic UI: Knöpfe für Intention, Prompts für Parameter. Das ist falsch herum. Intention — was soll passieren — ist unstrukturiert, individuell, sprachlich. Dafür ist der Prompt da.

Parameter — wie soll es passieren — sind strukturiert und bekannt. Style Level, Safe Mode, Sprache, Modell. Dafür sind Knöpfe da. Nicht als Ersatz für den Prompt, sondern als Ergänzung.

Was immer sichtbar ist: Prompt/Chat-Input, Submit-Button (disabled während Agent läuft). Was situativ erscheint: Stop-Button, Safe-Mode-Toggle, Style-Slider, Message-Injection (User tippt mid-run, Agent liest beim nächsten Turn).

↑
IMMER VORHANDEN
Prompt · Submit (disabled während Run) · Stop-Button
⚙
SITUATIV
Safe-Mode-Toggle · Style-Level-Slider · Mid-Run Message
↻
RENDER-LOOP (selten)
Agent triggert Browser-Aktion (z.B. 3D Render), wartet auf Screenshot als Tool-Result. Agent-zu-Browser-zu-Agent-Loop.
04 — HUMAN-IN-THE-LOOP: EIN SPEKTRUM

Nicht binär. Fünf Stufen zwischen vollautomatisch und manuell.

Human-in-the-Loop ist keine Ja/Nein-Entscheidung. Es ist ein Spektrum. Jede Stufe hat ihre Berechtigung — je nach Task-Art, Risiko und Vertrauen in den Agenten.

01
Kein Eingriff
Wizard vorher, dann Agent durch. Gut für deterministische, niedrig-riskante Tasks. Nutzer sieht nur Ergebnis.
02
Graceful Stop
Stop-Button jederzeit. Agent-Check pro Turn — sauberes Beenden, kein Crash. Nutzer behält Kontrolle ohne permanent einzugreifen.
03
Session Resumption
claude_session_id gespeichert. Weiterführen statt neu starten. Für lange Prozesse über Stunden oder Tage.
04
Message Injection
User tippt mid-run. Agent liest beim nächsten Turn. Kein Stop, kein Neustart — Lenkung während der Fahrt.
05
Render-Loop
Agent triggert Aktion im Browser (Render, Klick, Screenshot). Wartet auf Ergebnis als Tool-Result. Bidirektional.
05 — MONITORING ALS UI-SCHICHT

Wer Agenten deployt muss sehen können was passiert.

Monitoring ist kein Afterthought. Es ist eine eigene UI-Schicht mit eigener Route, eigenem Component-Set, eigenem Update-Rhythmus.

Was gut funktioniert: Grid aus Session-Cards mit Live-Status. Farb-Codierung (grün = aktiv, blau = fertig, rot = Fehler). Events-Timeline mit Timestamps auf Millisekunden. Tool-Calls inline mit Input + gekürztem Result. Cost per Event.

Das AgentRun-Model trackt: cost_usd, input_tokens, output_tokens, turns, current_tool, current_stage, tool_history (JSON), heartbeat_at. Stale bei Heartbeat > 2 Minuten. RunReport nach Abschluss.

SCHLECHTES AGENTIC UI
Spinner + „Bitte warten"
Ergebnis erst ganz am Ende
Kein Stop-Button
Kosten unsichtbar
Kein Monitoring
Modal-Confirm für alles
GUTES AGENTIC UI
Thinking live gestreamt
Ergebnis baut sich auf
Stop jederzeit
Cost per Turn sichtbar
Eigene Monitor-Route
HITL-Stufe nach Task

Watch the Agent Work.