Chat ist nicht falsch. Chat als Default ist falsch.
Seit Jahren bekommt fast jedes neue AI-Feature dasselbe Gesicht: ein Textfeld unten, ein Antwortstrom darüber. Egal ob ich eine Frage stelle, einen Text umschreiben lasse oder einen Agenten an eine Datenbank lasse - die Oberfläche ist immer dieselbe Sprechblasen-Spalte. Das ist billig zu bauen und fühlt sich vertraut an. Nur passt es selten zu dem, was wir mit dem Output eigentlich tun.
Sobald ein Agent nicht nur antwortet, sondern etwas produziert, mit dem ich weiterarbeite - einen Plan, eine Migration, eine Erstattung -, fängt das eigentliche Problem an. Mit so einem Ergebnis will ich ganz unterschiedliche Dinge tun, und die wenigsten davon sind „noch eine Nachricht tippen“. Für die meisten gibt es eine Fläche, die besser passt als ein weiteres Textfeld: einen Editor, einen Diff, ein Approval-Panel, eine Timeline.
Dieser Post geht diese Flächen einzeln durch, an einem durchgehenden Beispiel: einem Werkzeug, das aus einem GitHub-Issue einen Umsetzungsplan macht. Er ist die Interaktions-Schicht über einer Serie, in der es bisher ums Innenleben von Agent-Systemen ging - Contracts, Tool-Sicherheit, Approval, Observability. Die Oberfläche ist der Ort, an dem dieses Innenleben sichtbar wird oder unsichtbar bleibt.
Issue rein, 40 Zeilen Plan raus - LGTM?
Du kopierst die URL eines GitHub-Issues, fügst sie in ein Feld ein, klickst „Analysieren“. Ein paar Sekunden später beginnt Text einzulaufen: erst eine Zusammenfassung, was das Issue eigentlich will. Dann die betroffenen Bereiche im Code. Dann eine Liste der Risiken, die konkreten Umsetzungsschritte, am Ende ein paar Testideen. 40 Zeilen, sauber gegliedert, mit Überschriften und Aufzählungen. Ein Plan, kein Geplauder.
In den meisten Tools, die ich kenne, wäre das ein Chatverlauf. Eine Sprechblase nach der anderen, von oben nach unten, du scrollst mit. Hier ist es etwas anderes: ein Dokument. Strukturiert, an einem Stück lesbar, mit klaren Abschnitten statt einem endlosen Strang aus Antwort und Rückfrage. Der Unterschied wirkt zunächst kosmetisch. Er ist es nicht.
Denn jetzt kommt die Frage, die diesen ganzen Post trägt: Was tust du als Nächstes mit diesem Plan?
Du liest ihn gründlich, nicht überfliegend, weil gleich Code daraus wird. Du stolperst über Schritt 3, der die Migration vor das Backup setzt, und willst diese eine Zeile korrigieren. Du willst den Plan gegen das ursprüngliche Issue halten, um zu sehen, ob er die Anforderung wirklich trifft oder daran vorbeiplant. Du willst die zwei riskanten Schritte - die Schema-Migration, der Eingriff in die Auth - explizit freigeben, bevor irgendetwas passiert. Und dann willst du den Plan anwenden, ihn in echte Arbeit überführen.
Fünf Tätigkeiten am fertigen Plan. Lesen, korrigieren, vergleichen, freigeben, anwenden. Und keine einzige davon heißt „weiterchatten“.
Das ist der Moment, an dem die Chat-Oberfläche leise versagt. 40 Zeilen Plan. LGTM. Approve. Done. Oder… in welches Textfeld tippe ich jetzt die Korrektur für Schritt 3? Schreibe ich „ändere bitte Schritt 3, die Migration muss nach dem Backup laufen“ und hoffe, dass das Modell die richtige Zeile trifft, ohne die anderen 39 umzuschreiben? Das ist kein Editieren. Das ist Editieren beschreiben und beten.
Sobald ein Agent etwas produziert, mit dem du arbeitest, zerfällt die eine Konversation in mehrere unterschiedliche Tätigkeiten. Chat presst sie alle in dasselbe Textfeld zurück. Warum das überhaupt die Voreinstellung für alles ist, obwohl es so selten passt, ist die eigentliche Frage.
Sechs Aufgaben, ein Textfeld
Schauen wir uns an, was rund um den Plan aus dem letzten Kapitel passiert. Eingabe und Generierung kommen davor - und dann die Dinge am fertigen Plan: lesen und prüfen, editieren, freigeben, anwenden. Ein halbes Dutzend Tätigkeiten, jede mit ihrem eigenen Takt. Eingeben ist ein kurzer Stoß. Review ist langsames, springendes Lesen. Editieren ist punktuell. Freigeben ist ein bewusster, einzelner Moment. Und ein Chatthread serialisiert all das in eine einzige, nach unten wachsende Spalte.
Hier liegt die Reibung. Ein Thread ist ein schlechter Workflow-Tracker, weil Konversations-Takt und Workflow-Takt verschiedene Uhren sind. Die Konversation will, dass ich auf die letzte Nachricht antworte. Der Workflow will, dass ich zu Schritt drei zurückspringe, dort zwei Zeilen ändere und den Rest stehen lasse. Im Thread heißt das: scrollen, suchen, den Kontext im Kopf rekonstruieren, eine neue Nachricht tippen, die beschreibt, was ich eigentlich direkt anfassen wollte. Der Plan ist ein Objekt mit Zuständen - der Thread behandelt ihn als Abfolge von Sprechakten.
Im UX-Diskurs zu Agent-Interfaces wird 2026 eine Pointe stark gemacht, unter anderem von Adi Leviim im UX Collective: Chat ist das Interface, das sich am schnellsten ausliefern ließ. Am besten funktioniert es damit noch lange nicht. Ein Textfeld plus Antwortstrom ist billig zu bauen und für jeden Use Case einsetzbar. Der Preis dafür ist verschoben, nicht verschwunden. Sechs unterschiedliche Aufgabentypen, ein Eingabefeld - und die Last, zwischen den Modi zu unterscheiden, trägt der User. Ich muss in Prosa formulieren, ob ich gerade fragen, korrigieren oder freigeben will - obwohl die UI diese Unterscheidung übernehmen könnte. Sie weiß ja, in welchem Schritt wir stehen.
Das ist dieselbe Bewegung wie bei der Autonomie - ein Regler, den die meisten Systeme nicht ganz aufdrehen. Bei der UI gilt das Analoge: Die Oberfläche ist eine Auswahl pro Aufgabe. Welche Fläche zu welcher Aufgabe passt, lässt sich ziemlich direkt aufschreiben:
| Aufgabentyp | Passende Fläche |
|---|---|
| Plan ansehen, Überblick gewinnen | Dokument |
| eine Zeile ändern | Inline-Edit |
| gegen die Anforderung prüfen | Diff- / Compare-View |
| einen riskanten Schritt freigeben | Approval-Panel |
| nachvollziehen, was gelaufen ist | Timeline |
| offen explorieren, noch ohne Form | Chat |
Chat steht in der letzten Zeile, und das ist kein Abschied: Für offenes Explorieren, wenn die Aufgabe noch keine Form hat, ist ein Textfeld die richtige Wahl. Das Problem ist nicht Chat. Das Problem ist Chat als Default für alles - auch für die fünf Zeilen darüber, wo eine spezifischere Fläche die Arbeit übernähme.
Fangen wir oben in der Tabelle an. Wenn ein Werkzeug aus einem Issue einen Umsetzungsplan macht, ist das Erste, was ich mit diesem Plan tue, ihn zu lesen und Struktur zu erkennen. Dafür ist die passende Fläche kein Gesprächsverlauf, sondern ein Dokument - ein Plan ist ein Editor-Problem.
Der Editor: ein Plan ist ein Dokument
Zurück zu unserem Plan: Eine Zeile stimmt nicht ganz - die Migration soll erst nach dem Backup laufen.
In einem Chat schreibst du jetzt zurück: „Nein, dreh Schritt 3 und 4 um, das Backup muss zuerst.“ Der Agent liest deinen Freitext, interpretiert ihn und generiert dir den Plan neu. Im besseren Fall ist die Reihenfolge jetzt korrekt. Im schlechteren hat sich Schritt 6, der vorher richtig war, leise mitverschoben - weil eine Re-Generierung den ganzen State neu würfelt und keine Garantie kennt, dass alles außer deiner einen Änderung gleich bleibt.
Das ist der Kern des Problems mit Re-Prompting als Korrekturmechanismus: Du hast einen strukturierten State - ein typisiertes Plan-Objekt mit summary, steps[], risks[] - und jagst ihn durch eine Freitext-Interpretation, um eine punktuelle Änderung zu machen. Der Agent muss aus deinem Satz erst rekonstruieren, was du meinst, und produziert dann ein komplett neues Objekt. Der Contract zwischen UI und Agent existiert noch, aber er wird bei jeder Korrektur einmal komplett neu erfüllt statt gezielt angefasst.
Ein Plan ist ein Artefakt. Artefakte editiert man direkt: Klick auf die Zeile von Schritt 3, ändere den Text im Dokument, fertig. Die UI ersetzt nur diesen einen Eintrag im Plan-Objekt und lässt den Rest unangetastet. Der Contract bleibt intakt, weil du auf der Ebene des Objekts arbeitest, nicht auf der Ebene einer neuen Generierung.
// Korrektur als Freitext zurück an den Agenten.
// Der re-generiert das GANZE Plan-Objekt aus deinem Satz -
// summary, steps[] und risks[] werden neu interpretiert.
// Was vorher korrekt war, kann sich dabei mitverschieben.
async function correctViaChat(message: string) {
const newPlan = await agent.send({
role: "user",
content: message, // "Nein, dreh Schritt 3 und 4 um"
});
setPlan(newPlan); // kompletter Ersatz, kein Diff
}// Direkte Manipulation eines typisierten Plan-Objekts.
// Nur der angefasste Schritt wird ersetzt, der Contract
// (summary, steps[], risks[]) bleibt strukturell intakt.
function onSave(stepId: string, next: string) {
setPlan((plan) => ({
...plan,
steps: plan.steps.map((step) =>
step.id === stepId ? { ...step, text: next } : step,
),
}));
}Der Unterschied liest sich abstrakt, bis man ihn anfasst. Klick im Plan auf eine Zeile und ändere sie direkt:
Wenn du den Autonomie-Regler von eben im Kopf behältst, ist das hier dieselbe Trennung auf UI-Ebene: Intent gegen Execution. Du editierst das Ergebnis, nicht den Prompt. Die Absicht hast du längst formuliert - jetzt korrigierst du die Ausführung, ohne den ganzen Apparat neu anzuwerfen.
Eine ehrliche Einschränkung: Dieser flache State - Schritte als Liste, ein Feld pro Eintrag - ist eine bewusste Entscheidung, keine Notlösung. Solange die Schritte unabhängig nebeneinander stehen, reicht ein Array. Erst wenn Schritte echte Reihenfolge-Abhängigkeiten haben (Schritt 5 darf nur laufen, wenn 2 und 3 erfolgreich waren), brauchst du einen Task-Graph statt einer Liste. Das ist eine andere Datenstruktur und ein anderes Editier-Modell - und für die meisten Pläne brauchst du es schlicht nicht.
Editieren löst das eine Problem: Ich kann den Plan formen, ohne den State zu zerschießen. Es löst das andere nicht. Woher weiß ich, dass der Plan überhaupt das trifft, was im Issue stand? Eine flüssig formulierte Schrittliste sieht immer plausibel aus. Ob sie die Anforderung tatsächlich erfüllt, sehe ich erst, wenn ich beides nebeneinanderlege.
Der Compare-View: was der Agent sagt vs. was passiert
Erinnern wir uns an den Refund-Agent aus dieser Serie. Im Chat steht der freundliche Satz: „Rückerstattung veranlasst, der Betrag ist in wenigen Tagen zurück auf dem Konto.“ Der Tool-Call ist durchgelaufen, kein Fehler, kein roter Rand. Nur bewegt sich kein Geld. Im Ledger steht nichts - kein Eintrag, keine Transaktion, keine Spur. Der Agent hat eine Behauptung produziert, kein Ergebnis. Genau das ist False Success: eine Antwort, die nach Erfolg aussieht, während der Backend-State unberührt bleibt.
Ein Chat-Absatz lädt zum Überfliegen ein. Er ist fließend formuliert, höflich, plausibel - und unsere Augen rutschen über die Zusammenfassung, weil sie sich liest wie ein Ergebnis. Ein Diff tut das Gegenteil. Er stellt zwei Zustände nebeneinander und zwingt uns zum Hinsehen: links das eine, rechts das andere, dazwischen die Differenz. Wo der Chat erzählt, vergleicht der Compare-View.
Ein grüner Chatverlauf mit kaputtem Backend-State ist gefährlicher als ein roter Stacktrace. Der Stacktrace schreit dich an. Der grüne Verlauf flüstert dir zu, dass alles in Ordnung sei.
Der Diff hat in Agent-Systemen zwei Spielarten, und beide decken unterschiedliche Lücken auf.
Die erste: Original-Issue ↔ generierter Plan. Hier liegt die Anforderung neben dem, was der Agent daraus gemacht hat. Deckt der Plan wirklich alle drei Punkte aus dem Issue ab, oder sind es nur zwei, weil der dritte unterwegs still verschluckt wurde? Im Fließtext fällt eine fehlende Anforderung kaum auf - der Plan klingt vollständig, solange wir das Issue nicht danebenlegen. Der Vergleich macht die Auslassung sichtbar, bevor irgendein Code entsteht.
Die zweite: Behauptung ↔ Systemzustand. Was der Agent behauptet getan zu haben, gegen das, was das System tatsächlich zeigt. „Refund veranlasst“ links - der fehlende Ledger-Eintrag rechts. Diese Spielart ist die wichtigere, weil sie dort ansetzt, wo der Chat am überzeugendsten lügt: bei der Erfolgsmeldung nach einer mutierenden Aktion. Der Agent darf gern behaupten. Wir prüfen die Behauptung gegen den State.
Beide Spielarten, nebeneinandergelegt - schalt zwischen ihnen um:
- Login per E-Mail + Passwort
- MFA über TOTP
- Rate-Limiting für Fehlversuche
- Schritt: E-Mail/Passwort-Flow
- Schritt: TOTP-Setup + Verify
- — nicht im Plan —
Diese Idee ist kein Einzelfund. In mehreren UX-Leitfäden für Agent-Systeme aus 2026 tauchen Muster auf, die im Kern dasselbe meinen: das „Action Receipt“, das jede Aktion mit einem Beleg quittiert, oder das Tool-Call-Review mit Before/After-Diff und Rollback-Pfad. Unterschiedliche Namen, eine Bewegung hin zum prüfbaren Vergleich. Jede Agent-Aktion produziert nicht nur eine Aussage darüber, was passiert sein soll, sondern ein Artefakt, an dem wir nachsehen können, was passiert ist.
Ein grüner Plan ist keine erfüllte Anforderung - so wenig wie ein grüner Eval-Score eine Produktionsfreigabe ist. Der Diff zeigt dir die Differenz zwischen Behauptung und Realität. Was du mit dieser Differenz machst, bleibt deine Disziplin: erst wenn der rechte Zustand den linken einlöst, ist die Aktion fertig. Nicht der Chatverlauf entscheidet das.
Der Compare-View löst ein Problem der Sichtbarkeit. Er macht die Differenz zwischen Anspruch und Wirkung greifbar, statt sie im Fließtext zu verstecken. Aber Sichtbarkeit ist nicht Kontrolle. Ein Diff zeigt mir, dass der Plan eine Datenbank migriert oder eine Zahlung auslöst - er hält den Schritt nicht auf. Bei den harmlosen Aktionen reicht das Hinsehen im Nachhinein. Bei den riskanten brauche ich eine Instanz davor: einen Punkt, an dem ich entscheide, ob dieser Schritt überhaupt laufen darf.
Das Approval-Panel: Freigabe als primäre Interaktion
Der Compare-View endete mit einer offenen Frage: Wer gibt den riskanten Schritt frei? Im Chat ist die Antwort meist ein Popup, das mitten in den Verlauf platzt - ein modaler Interrupt, der dich aus dem Lesefluss reißt und mit einer Ja/Nein-Entscheidung allein lässt. Du klickst, der Dialog verschwindet, und was du gerade bestätigt hast, scrollt nach oben weg. Freigabe verdient eine eigene Fläche, kein Overlay über dem Gespräch.
Ein Approval-Panel macht den Zustand sichtbar und scannbar: ausstehend → in Bestätigung → freigegeben. Es zeigt, welcher Tool-Call mit welchen Argumenten laufen würde, bevor er läuft - nicht als Fließtext-Beschreibung, sondern als konkreter, geparster Vorschlag. Du siehst die Mutation, nicht die Erzählung darüber. Und du siehst sie an einem festen Ort, der nicht im Verlauf untergeht, solange noch etwas auf deine Entscheidung wartet.
Damit nicht jeder Schritt vor dir landet, brauchst du eine Vorsortierung nach Risiko: read-only, low-risk Mutation, high-risk Mutation, irreversibel. Das Modell kann selbst markieren, was Freigabe braucht - ein requiresApproval-Flag, gesetzt bei DB-Migrationen, Auth- und Berechtigungs-Änderungen, Billing-Logik, destruktiven oder nach außen wirkenden Breaking Changes. Verlässlicher ist es, diese Einstufung als Policy auf Tool-Ebene zu erzwingen - eine Allowlist nach Tool-Typ. Allein der Selbsteinschätzung des Modells zu trauen ist riskant: Bei Prompt-Injection oder Halluzination nennt es ausgerechnet die heikle Aktion harmlos. So passiert ein Read still im Hintergrund, während ein DROP-Statement zur Bestätigung anhält. Vor dem Menschen landet nur, was die Reibung wirklich rechtfertigt.
Und hier lauert das eigentliche Problem. Ein Freigabe-Button verführt zum Durchwinken. Wer zehnmal hintereinander „Approve“ klickt, prüft beim elften Mal nicht mehr - das ist Rubber-Stamping, und es ist messbar gefährlich. Im Human-in-the-Loop-Diskurs wird Automation Complacency seit Jahren beschrieben: Sobald die vorgeschlagenen Antworten falsch waren und blind übernommen wurden, sank die Trefferquote der Beteiligten messbar - der falsche Vorschlag zog sie mit nach unten, statt von ihnen korrigiert zu werden. Eine Aufsicht, die nur nickt, ist keine Aufsicht.
Die Gegenmaßnahme heißt Cognitive Forcing: ein bewusster Zwischenschritt, der den Reflex bricht. Der Zustand „in Bestätigung“ ist solch ein Schritt - eine kurze Pause mit Begründungspflicht, in der du nicht nur klickst, sondern in einem Satz festhältst, warum diese Mutation laufen darf. Die Reibung ist hier das Feature. Sie zwingt den Blick zurück auf die Argumente des Tool-Calls, bevor er Realität wird.
Versuch, den Schritt freizugeben - ohne Begründung geht es nicht:
run_migration({
table: "users",
statement: "ALTER TABLE users DROP COLUMN legacy_token",
reversible: false
})Ein Freigabe-Button, der im System nichts auslöst, trainiert genau das Rubber-Stamping, das er verhindern soll. Wenn „Approve“ folgenlos bleibt, lernt der Mensch, dass Klicken reicht - und das Panel wird zur Fassade über einer Automatik, die längst allein entscheidet.
Im UX-Diskurs zeichnen sich dafür konkrete Muster ab. Eine „Intent Preview“ zeigt dir, was der Agent vorhat, und gibt dir mehr als ein binäres Ja - etwa: weiter, Plan ändern oder selbst übernehmen. Die „Autonomy Dial“ aus 2026er-UX-Leitfäden - unter anderem bei Smashing Magazine beschrieben - macht den Grad der Eigenständigkeit selbst zur einstellbaren Größe, statt ihn fest zu verdrahten. Die Faustregel dahinter: nudge, don’t nag. Frag dort, wo es zählt, nicht bei jedem Schritt - sonst stumpft die Aufmerksamkeit ab, und du bist zurück beim Durchwinken.
Ist die Freigabe erteilt, beginnt die Arbeit. Mehrere Tool-Calls laufen, Zustände ändern sich, etwas wird geschrieben, gelöscht, verschickt. Das Panel hat dir gezeigt, was passieren sollte. Aber woher weiß ich, was tatsächlich passiert ist - in welcher Reihenfolge, mit welchem Ergebnis, an welcher Stelle es klemmte? Der Chatverlauf gibt es bestenfalls nacherzählend wieder.
Die Timeline: Trace statt Chatverlauf
Nach der Freigabe läuft etwas - und hier zeigt sich der Unterschied zwischen zwei Arten von Aufzeichnung. Ein Chatverlauf erzählt, was gesagt wurde. Ein Audit-Log oder ein Trace zeigt, was tatsächlich passiert ist. Das ist nicht dasselbe, und der Spalt zwischen beidem ist exakt die Stelle, an der False Success wohnt: Der Agent sagt „Erstattung ist raus“, der Scrollback liest sich wie ein gelöstes Ticket - und im Trace steht, dass der entscheidende Tool-Call nie durchlief.
Eine Timeline ist mehr als der Chatverlauf in hübsch: Sie ist der Trace-Waterfall - die hierarchische Abfolge dessen, was das System getan hat, mit Dauer, Verschachtelung und Ergebnis pro Schritt.
Was so eine Fläche zeigt, kennen wir bereits aus dem Observability-Post: Tool-Execution-Spans mit Argumenten und Ergebnis, Approval-Events als Pause im Ablauf, Timestamps, Dauer. Im Kern sind es LLM-Calls für die Modell-Interaktionen, Tool-Executions für jeden Tool-Call und die Agent-Orchestration als Root-Span, der alles zusammenhält. In einer guten Timeline kann ich filtern (nur Tool-Calls, nur Fehler), zoomen und direkt zu einem Schritt springen - statt durch hunderte Chat-Bubbles zu scrollen.
Das ist der Punkt, den der Agent-UX-Diskurs immer wieder macht: In einer langen, teils autonomen Session entstehen schnell hunderte Ereignisse. Die Frage „Was geschah zwischen Minute 30 und 45?“ ist in einem linearen Chat praktisch nicht zu beantworten - du scrollst, suchst, verlierst den Faden. In einer filterbaren Timeline ist sie eine Bereichsauswahl.
Bleiben wir ehrlich bei der Einordnung. Bei einer einmaligen Plan-Generierung - single-shot, ein Modell-Call, ein Ergebnis - zahlt eine Timeline noch wenig. Da ist kaum etwas zu verschachteln, der „Trace“ ist eine Zeile. Ihr Wert steigt in dem Moment, in dem der Plan angewendet wird: mehrere Tool-Calls hintereinander, mehrere geschriebene Sub-Issues, eine Freigabe mittendrin, vielleicht ein Retry nach einem Fehler. Dann ist die Timeline der Unterschied zwischen „Ich glaube, es lief“ und „Ich sehe, was lief - und wo es klemmte“.
Das ist auch der Grund, warum diese Fläche und Observability nicht zwei Themen sind, sondern eines. Die Timeline ist das Frontend desselben Traces, den du im Backend ohnehin brauchst, um Incidents zu debuggen. Wer ordentlich instrumentiert, bekommt die Nachvollziehbarkeits-Oberfläche fast geschenkt.
Damit haben wir vier Flächen gesehen, die in vielen Fällen besser funktionieren als ein Chatfenster: Editor, Diff, Approval-Panel, Timeline. Bleibt der Chat selbst.
Wann Chat doch richtig ist
Chat hat ausgedient? Nein - aber nur für eine bestimmte Sorte Aufgabe. Die Unterscheidung, auf die es hier ankommt, ist nicht „Chat vs. UI“, sondern divergent vs. konvergent.
Divergente Arbeit öffnet den Suchraum. Der Zielzustand steht noch nicht fest, er entsteht erst im Verlauf. Du tastest dich heran, verwirfst, probierst eine andere Richtung. Dafür ist eine Konversation gebaut: Jeder Turn darf vage sein, jeder nächste Schritt korrigiert den vorherigen. Konvergente Arbeit ist das Gegenteil. Es gibt einen prüfbaren Endzustand - eine Freigabe, einen Vergleich, ein angewendetes Ergebnis - und die Frage ist nur noch, ob dieser Zustand stimmt. Hier wird Chat schwach, weil er das Prüfen in eine Textspur zwingt, die du selbst rekonstruieren musst.
Ein Beispiel, das beides zeigt: Du verfeinerst ein UI-Mockup. „Füg ein Suchfeld über der Tabelle hinzu.“ „Mach die Tabelle kompakter.“ „Nimm die zweite Spalte wieder raus.“ Jeder Satz verengt den Suchraum ein Stück, und das Ziel - das gute Layout - existiert am Anfang noch gar nicht als Spezifikation. Es kristallisiert sich im Dialog heraus. Das ist das exakte Gegenteil eines Plans, den du vorab freigibst. Niemand würde diesen Prozess in ein Approval-Formular pressen wollen, weil es nichts Fertiges zum Freigeben gibt. Die Konversation ist hier das Werkzeug.
Technisch muss „Chat“ dabei längst nicht nackter Text sein. Moderne Frameworks erlauben Generative UI: Der Agent rendert zur Laufzeit echte Komponenten, statt nur zu schreiben. Ein Tool liefert dann ein Formular, eine Tabelle oder eine Reihe Metric-Cards statt bloßem Text - im Vercel AI SDK etwa über Tool-Invocations, die das Frontend in Components übersetzen. Ein ehrlicher Hinweis dazu: Der Weg über React Server Components ist beim AI SDK aktuell pausiert; empfohlen wird die client-seitige Variante mit useChat plus den Tool-Invocations. Das Ergebnis ist trotzdem eine Chat-Oberfläche - aber eine mit strukturierten, interaktiven Bausteinen darin.
Und das ist kein Bruch mit der These dieses Posts, sondern ihre Bestätigung. Wir wählen die Fläche nach der Aufgabe. Wenn die Aufgabe divergentes Explorieren ist, gewinnt Chat - und sobald innerhalb dieser Exploration ein konvergenter Moment auftaucht, schiebst du eben einen strukturierten Baustein in den Stream. Selbst „Chat“ ist dann oft Chat-plus-Struktur, nicht die Rohform, mit der das alles anfing.
Faustregel: divergent und explorativ, ohne festen Zielzustand → Chat. Konvergent, prüfend, handelnd, mit klarem Endzustand → strukturierte Fläche (Editor, Diff, Approval, Timeline).
Wann Chat gewinnt - und wann er verliert
Chat gewinnt:
- offenes Brainstorming, bei dem die Richtung noch offen ist
- Mockup- und Entwurfs-Refinement Schritt für Schritt
- Fragen an eine Wissensbasis
- frühe Exploration, in der es noch keinen definierten Zielzustand gibt
Chat verliert:
- die Freigabe einer riskanten Aktion
- der Vergleich zweier Zustände nebeneinander
- das Nachvollziehen eines langen, mehrstufigen Ablaufs
- das präzise Editieren eines strukturierten Artefakts
Damit haben wir die ehrliche Version der These: Chat ist eine Fläche unter mehreren, und sie hat einen klaren Einsatzort. Wenn wir sie konsequent nach der Aufgabe wählen - was heißt das für den Bau von Agent-Systemen?
Die Kontrolloberfläche ist der Moat
Blake Crosley hat es im Diskurs von 2026 auf eine Formel gebracht, die hängenbleibt: Über produktiv einsetzbare Agenten entscheidet nicht das Modell und nicht die Größe des Kontextfensters, sondern die Oberfläche, die ihre Arbeit sichtbar, prüfbar und freigebbar macht. Der Wettbewerbsvorteil sitzt eine Etage über dem Reasoning, in der Fläche, die es bedienbar macht. Die Control Surface ist der eigentliche Moat - das, was du von der Arbeit des Agenten siehst und im Zweifel stoppen kannst.
Das bündelt den ganzen Post. Ein Agent kann einen sauberen Contract erfüllen, jede Eval bestehen und einen lückenlosen Trace schreiben - und der Nutzer merkt davon nichts, solange keine UI es zeigt. Governance, die nur im Backend existiert, bleibt für den Menschen am anderen Ende unsichtbar. Der Editor zeigt den Contract, bevor er ausgeführt wird. Der Diff zeigt die Wirkung im Vorher-Nachher. Das Approval-Panel macht die Freigabe zu einer bewussten Entscheidung. Die Timeline hält den Verlauf fest, abrufbar statt aus dem Gedächtnis rekonstruiert. Ein Chat kann von all dem erzählen. Die strukturierten Flächen machen es prüfbar.
Damit schließt sich der Bogen über die Serie. Jede Fläche aus diesem Post hat ihre Wurzel in einem früheren Engineering-Problem:
- Autonomie-Regler statt freier Loop - wer Entscheidungspunkte definiert, braucht eine Oberfläche, die an diesen Punkten die Kontrolle zurückgibt.
- Intent vs. Execution - der Diff existiert, weil ein erfolgreicher Tool-Call noch keine richtige Wirkung ist; False Success wird erst im Vorher-Nachher sichtbar.
- Approval als Qualitätssicherung - das Approval-Panel ist die UI-Form von Human-in-the-Loop, die Freigabe als bewussten Schritt und nicht als Reflex.
- Trace statt Spekulation - die Timeline ist Observability für den Nutzer, der Verlauf als Beleg statt als Vermutung.
Eine Fläche fehlt in dieser Aufzählung noch, und sie sitzt am Anfang statt am Ende: die strukturierte Eingabe selbst - das Formular mit Assistenz, bei dem der Agent die Felder ausfüllt, statt nach ihnen zu fragen. Das ist das nächste Stück.
Die beste Oberfläche für einen Agenten macht seine Arbeit prüfbar - ein Chat macht sie nur erzählbar.