Wer nach einer guten UI und UX für agentische KI sucht, landet erstaunlich schnell bei einer älteren Lektion der Computergeschichte. Nicht weil wir in die 1970er zurückmüssten, sondern weil Unix unter knappen Bedingungen zeigte, wie man große Systeme überhaupt beherrschbar hält.

Unix entstand in den Bell Labs als Gegenbewegung zu Multics, einem System, das zu groß, zu schwer und zu komplex geworden war. Ken Thompson, Dennis Ritchie und später Douglas McIlroy suchten deshalb nicht nach maximaler Fülle, sondern nach Prinzipien, die Komplexität begrenzen: kleine Werkzeuge, klare Zuständigkeiten, Textströme und sichtbare Schnittstellen.

Genau darum lohnt der Vergleich heute wieder. Auch wenn KI inzwischen viel Komplexität für uns verwalten kann, bleibt es entscheidend, dass die Systeme selbst für Menschen verständlich bleiben. Sonst verlieren wir nicht nur Übersicht, sondern auch die Fähigkeit, gute Entscheidungen zu treffen.

Was Unix stark gemacht hat

Aus dieser Knappheit entstand eine Philosophie, die bis heute kaum übertroffen wurde. Ihr erster Pfeiler ist die Modularität. Statt alte Programme mit immer neuen Funktionen aufzublähen, baut man lieber ein neues kleines Werkzeug. Der zweite Pfeiler ist der Textstrom. Text wurde zur universellen Schnittstelle: lesbar für Menschen, verarbeitbar für Programme, speicherbar, prüfbar, weiterreichbar. Der dritte Pfeiler ist die Pipe. Sie ist der eigentliche Geniestreich von Unix, weil sie aus kleinen Programmen Ketten macht.

So entsteht aus einfachen Werkzeugen etwas, das größer ist als ihre Summe:

cat datei.txt | tr ' ' '\n' | sort | uniq -c | sort -nr | head -n 10

Niemand musste dafür ein riesiges Spezialprogramm schreiben, das Wörter zählt, sortiert und die Top 10 anzeigt. Die Lösung lag bereits in der Komposition.

Ebenso radikal war das Prinzip everything is a file. In Unix werden Geräte, Terminals und viele andere Systemressourcen so behandelt, als wären sie Dateien. Man kann sie öffnen, lesen und beschreiben. Der Effekt ist enorm: Werkzeuge müssen nicht ständig wissen, womit sie es im Innersten zu tun haben. Sie arbeiten gegen eine einfache, gemeinsame Form.

Gerade das ist für LLM-Systeme heute wieder interessant. Wenn Wissen bereits in klaren Textdateien, Logs, Markdown oder anderen einfachen Formaten vorliegt, müssen Modelle die relevanten Informationen nicht erst fehleranfällig aus PDFs, Screenshots oder schweren Dokumentformaten herausoperieren. Gute Datenformen reduzieren Fehler schon vor dem ersten Prompt.

Genau darin liegt die bleibende Stärke von Unix. Es ersetzt Komplexität nicht durch Magie, sondern durch gute Schnittstellen.

Warum das plötzlich wieder hochaktuell ist

Die erste Phase der LLM-Welt wirkte noch erstaunlich un-unixartig. Große Chatfenster, viel impliziter Zustand, eine einzige Oberfläche für alles, ein Modell als scheinbare Universalmaschine. Für Demos war das überzeugend. Für ernsthafte Systeme nur bedingt.

Denn sobald ein Modell nicht mehr nur antworten, sondern auch suchen, lesen, schreiben, prüfen, patchen und Werkzeuge aufrufen soll, verändert sich die Aufgabe. Dann baut man nicht länger nur ein Sprachsystem. Man baut eine Arbeitsumgebung. Und genau dort kehren die alten Fragen zurück: Wie bleibt das Ganze verständlich? Wie bleibt es klein genug, um beherrschbar zu sein? Wie läuft es auch auf schmaler Hardware, in Edge-Umgebungen, über SSH oder in sensiblen Infrastrukturen?

Wir brauchen für agentische LLM-Systeme heute im Grunde dieselbe Tugend, die Unix einst hervorgebracht hat: Regeln gegen Überladung.

Welche Oberflächen wir heute sehen

Im Moment entstehen vor allem drei Klassen solcher Oberflächen. Im Terminal arbeiten Modell und Operator direkt im laufenden Arbeitsprozess zusammen. Das ist bei Werkzeugen wie Claude Code, Gemini CLI oder Codex besonders sichtbar. Hier wird das Modell nicht nur gefragt, sondern eingesetzt: Dateien lesen, Befehle ausführen, Änderungen vorbereiten, Diffs prüfen. Das Terminal bleibt deshalb so stark, weil es bereits ein robustes Kompositionsmodell mitbringt: stdin, stdout, Exit-Codes, Pipes und Dateien.

Die zweite Form ist die App oder IDE-nahe Oberfläche. Dort verschiebt sich der Schwerpunkt von Ausführung zu Aufsicht. Mehrere Aufgaben laufen parallel, Diffs werden komfortabel geprüft, Freigaben verwaltet, längere Prozesse zwischengespeichert. Die Codex App ist genau dafür ein gutes Beispiel: weniger Kommandozeile, mehr Leitstand.

Die dritte Form ist die Web-Oberfläche. Sie ist am stärksten, wenn Delegation, Teamkoordination und Hintergrundarbeit wichtig werden. Dort arbeitet man nicht mehr Zug um Zug mit dem Modell, sondern verteilt Arbeit und prüft Ergebnisse später. Für lokale und sensible Umgebungen ist das selten die beste erste Oberfläche. Für asynchrone Zusammenarbeit dagegen schon.

Die entscheidende Beobachtung lautet: Diese drei Formen sind nicht bloß Stilvarianten. Sie repräsentieren unterschiedliche Modi von Arbeit. Terminal für unmittelbare Operation, App für Aufsicht, Web für Delegation.

Wenn KI zur Betriebsschicht wird

An dieser Stelle verändert sich noch etwas Grundsätzlicheres. Lange bestand Software aus Apps, jede mit ihrem eigenen Fenster, Menü und kleinen Hoheitsraum. Mit agentischen LLM-Systemen beginnt sich diese Ordnung zu verschieben. Wenn Modelle suchen, lesen, patchen, Tools aufrufen und Prozesse koordinieren, dann sind sie nicht mehr nur eine weitere Anwendung. Sie werden zu einer Art Betriebsschicht über vorhandenen Systemen.

Das ist mehr als ein hübsches Bild. Es bedeutet, dass die eigentliche Innovation nicht mehr nur im Modell liegt, sondern in der Ordnung, in der Modelle mit Tools, Daten, Rechten und Kontexten arbeiten. Wer diese Kopplung nicht sauber baut, bekommt kein neues Betriebssystem, sondern nur eine unruhigere Oberfläche. Gerade deshalb hängt gute UX hier nicht bloß an Buttons oder Layouts. Sie hängt an Architektur.

Wenn KI Teil der Betriebsordnung wird, verschiebt sich auch die Verantwortung der Oberfläche. Sie muss nicht nur Antworten anzeigen. Sie muss sichtbar machen, welches Modell gerade welche Rolle übernimmt, welche Datenquellen berührt werden, welche Rechte aktiv sind und welche Aktion nur vorgeschlagen oder schon ausgeführt wurde. Die UI wird damit weniger Schaufenster und mehr Kontrollpult einer neuen Steuerungsebene.

Wenn aus einem Agenten mehrere werden

Die nächste Verschiebung ist fast zwangsläufig: Ein einzelnes Modell reicht oft nicht mehr aus. Sobald Aufgaben mehrstufig werden, Werkzeuge zunehmen und Fehler teurer werden, entsteht schnell eine andere Architektur. Ein Agent plant, ein anderer recherchiert, ein dritter prüft, ein vierter führt kontrolliert aus. Der eigentliche Fortschritt liegt dann nicht in digitalem Theater, sondern in Arbeitsteilung.

Gerade dadurch wird Multi-Agenten-KI zu einer UI- und UX-Frage. Denn mehrere Rollen erzeugen nicht automatisch mehr Klarheit. Im Gegenteil: Ohne gute Oberfläche wächst nur die Unübersichtlichkeit. Wer arbeitet gerade woran? Welcher Agent darf lesen, welcher schreiben, welcher nur prüfen? Wo endet Analyse und wo beginnt Ausführung? Welche Zwischenschritte sind schon bestätigt, welche nur vorgeschlagen?

Genau deshalb darf man Multi-Agenten-Systeme nicht nur als Modellarchitektur betrachten. Sie sind immer auch eine Frage von Sichtbarkeit. Gute Multi-Agenten-UX muss Rollen, Zuständigkeiten, Übergaben und Freigaben erkennbar machen. Sonst wird aus koordinierter Arbeit nur eine neue Form von implizitem Zustand.

Was die Forschung dazu bereits zeigt

Die Forschung ist noch jung, aber einige Muster sind bereits erstaunlich klar. Die Arbeit Prototypical Human-AI Collaboration Behaviors from LLM-Assisted Writing in the Wild zeigt, dass Nutzer nicht einfach einen Prompt abschicken und das Ergebnis abnicken. Sie arbeiten iterativ: umformulieren, weiterführen, Varianten prüfen, Richtung wechseln. Für die UX heißt das: Gute Oberflächen müssen Revision, Vergleich und schrittweise Steuerung erlauben. Ein einzelnes Chatfeld ist dafür oft zu grob.

Noch näher an agentischen Systemen liegt ReAct: Synergizing Reasoning and Acting in Language Models. Die Grundidee ist, Denken und Handeln zu verschränken. Nicht erst planen und dann stumm ausführen, sondern in einer Folge aus Überlegung, Aktion und Beobachtung arbeiten. Im Paper verbessert das die Erfolgsraten in interaktiven Umgebungen und macht die Abläufe interpretierbarer. Für die UI folgt daraus ein sehr praktischer Schluss: Nutzer sollten nicht nur die Endantwort sehen, sondern auch Plan, Werkzeugaufrufe, Beobachtungen und den nächsten sinnvollen Schritt.

Sobald Agenten eigenständig handeln dürfen, wird Aufsicht zum UI-Thema. Genau darauf verweist On scalable oversight with weak LLMs judging strong LLMs. Die Arbeit zeigt, dass Debatten- und Gegenredeformate oft robuster sind als eine einzelne beratende Erklärung. Übersetzt in Produktdesign heißt das: Ein gutes Agentensystem braucht nicht nur Antworten, sondern auch Review, Vergleich, Widerspruch und Zweitmeinung.

Konzeptionell am weitesten geht Human-Centered LLM-Agent User Interface: A Position Paper von Chin, Wang und Xia. Die Autoren schlagen vor, agentische Oberflächen nicht bloß als Chat oder als explorierbare GUI zu denken, sondern als Systeme, die gemeinsam mit dem Nutzer einen Workflow entdecken. Das ist noch kein fertiges Produktrezept, aber ein wichtiger Hinweis: Gute Agenten-UX wird wahrscheinlich stärker workflow-orientiert und weniger menüförmig sein.

Zusammen genommen sprechen diese Arbeiten eine deutliche Sprache. Gute Agenten-UX wird iterativer, sichtbarer und widerspruchsfähiger sein. Nicht glatter, sondern kontrollierbarer.

Welche Designprinzipien sich daraus ableiten lassen

Wenn man Unix ernst nimmt und die Forschung danebenlegt, dann ergeben sich für agentische LLM-Systeme auf kleinen und mittleren Umgebungen einige recht klare Prinzipien.

Das erste Prinzip lautet: ein Operator, eine Aufgabe. Das wirkt im Zeitalter freier Sprache zunächst altmodisch. Man könnte einwenden: Reicht es nicht, wenn ich der KI einfach sage, was ich will? Für manche Fälle reicht das tatsächlich. Für Zusammenfassungen, Entwürfe oder offene Analyse ist freie Sprache oft genau richtig. Das Problem beginnt dort, wo aus Sprache Operation wird: Dateien lesen, Dateien schreiben, Shell-Befehle ausführen, Änderungen übernehmen, Systeme berühren.

Genau dort sind Operatoren nicht nur Komfort, sondern Rechte- und Verhaltensgrenzen. review heißt dann: lesen, prüfen, bewerten, aber nichts verändern. patch heißt: Änderungen vorschlagen, aber noch nicht anwenden. run heißt: Werkzeuge tatsächlich ausführen, also näher an Wirkung und Risiko arbeiten. Der Unterschied ist nicht semantische Pedanterie, sondern Zugriffslogik.

Freie Sprache bleibt trotzdem wichtig. Sie beschreibt Ziel, Kontext und Absicht. Die Operatoren beschreiben, was das System dabei darf. Die robustere Architektur ist deshalb meist zweischichtig: oben freie Sprache, unten klare Modi und Rechte.

Das zweite Prinzip lautet: Text- und Datenströme als universelle Schnittstelle. Nicht alles muss Text sein. Für Agentensysteme sind auch JSON, Diffs und Logs zentral. Entscheidend ist die Lesbarkeit und Weiterverarbeitbarkeit. Ein gutes System kann seine Ergebnisse in Formen ausgeben, die Menschen prüfen und Werkzeuge weiterverwenden können. Und je mehr Wissen schon in einfachen, sauberen Dateien vorliegt, desto weniger muss das Modell es erst mühsam und fehleranfällig aus schweren Formaten extrahieren.

Das dritte Prinzip lautet: Pipes statt Monolithen. Ein LLM sollte die Shell nicht ersetzen, sondern erweitern. Suche bleibt Suche, git diff bleibt git diff, make bleibt make. Das Modell übernimmt Verdichtung, Planung, Formulierung und Koordination. Die Unix-Werkzeuge bleiben die eigentlichen Operatoren.

Das vierte Prinzip lautet: Ressourcen brauchen eine einheitliche Form. Unix hatte dafür die Datei. In agentischen Systemen kann diese Rolle eine saubere Tool- und Protokollschicht übernehmen. Genau hier wird das Model Context Protocol (MCP) interessant. Es trennt Host, Client und Server, nutzt JSON-RPC 2.0 und funktioniert lokal besonders elegant über stdio. Für kleine Systeme ist das fast die moderne Fortsetzung der alten Unix-Idee: ein Prozess startet einen anderen, spricht strukturiert mit ihm und kann ihn leicht beobachten oder austauschen.

Das fünfte Prinzip lautet: Aufsicht ist kein Zusatz, sondern Kern der Oberfläche. Wenn eine Agenten-UI keine klaren Freigaben, keine prüfbaren Zwischenschritte und keine Zweitmeinung zulässt, ist sie für produktive Umgebungen schnell zu leichtsinnig. Gerade die Oversight-Arbeiten sprechen sehr klar dafür, Kritik und Review nicht als Misstrauensgeste, sondern als Teil der normalen Bedienung zu behandeln. Komplexität darf von der Maschine bearbeitet werden. Für den Menschen muss sie trotzdem lesbar bleiben.

Daraus folgt allerdings noch etwas Unbequemes: Viele Nutzer werden auf Dauer kaum Lust haben, eine Bedienungsanleitung für review, patch und run zu lesen. Wenn die Oberfläche diese Unterschiede nur dokumentiert, aber nicht spürbar macht, werden am Ende viele schlicht immer run verwenden. Genau deshalb muss die UX die Rechte sichtbar machen: durch gute Defaults, klare Benennung, erkennbare Freigabestufen und eine Sprache, die den Unterschied zwischen Prüfen, Vorschlagen und Ausführen unmittelbar verständlich macht. Sonst gewinnt wieder die bequemste Taste, und das ist fast immer die gefährlichere.

Das sechste Prinzip lautet: lokal zuerst, Eskalation nur wenn nötig. Kleine und mittlere Modelle sind für viele Analyse-, Routing-, Review- und Zusammenfassungsaufgaben oft ausreichend. Größere Cloud-Modelle sollten dort eingesetzt werden, wo der Qualitätsgewinn die zusätzliche Komplexität rechtfertigt. Die UX sollte dabei möglichst gleich bleiben, auch wenn sich das Backend ändert.

Das siebte Prinzip lautet schließlich: schwere Oberflächen nur auf einen leichten Kern setzen. Eine App, eine Web-Oberfläche oder eine TUI können sehr nützlich sein. Aber sie sollten Aufbauten über einem klaren Kern sein, nicht sein Ersatz.

Das achte Prinzip lautet: mehrere Agenten brauchen sichtbare Rollen. Wenn Planung, Recherche, Ausführung und Review auf unterschiedliche Einheiten verteilt werden, muss die Oberfläche diese Trennung mittragen. Multi-Agenten-UX braucht daher mindestens vier Dinge: klare Rollennamen, erkennbare Übergaben, getrennte Rechte und eine sichtbare Eskalationslogik. Gerade in der Softwareentwicklung oder in dokumentenlastigen Prozessen entscheidet sich hier, ob ein System geordnet wirkt oder nur laut.

Das neunte Prinzip lautet: Parallelität braucht Verdichtung. Mehrere Agenten gleichzeitig sind nur dann ein Vorteil, wenn die Oberfläche den entstehenden Zustand wieder auf eine lesbare Form zurückführt. Ein Mensch will keine fünf laufenden Innenansichten verfolgen. Er will wissen: Was ist fertig, was ist strittig, was braucht Freigabe, wo gibt es Risiko? Gute UX für Multi-Agenten-Systeme ist deshalb weniger ein Chatfenster und eher ein Leitstand mit sinnvoll verdichteten Statuswechseln.

Das zehnte Prinzip lautet: kleine Dienste schlagen monolithische Super-Apps. Ein gutes System besteht oft nicht aus einem einzigen allmächtigen Programm, sondern aus einer kleinen Zahl klarer Bausteine: Suchdienst, Dateidienst, Git-Dienst, Modellrouter, Agenten-Runner, Dokumentenzugriff. Das reduziert Kopplung, erhöht Austauschbarkeit und macht Fehler leichter eingrenzbar.

Das elfte Prinzip lautet: verständliche Ausgaben sind ein Produktivitätsfaktor. Text, JSON, Diffs und Logs wirken im Vergleich zu glatten Oberflächen manchmal alt. In Wirklichkeit sind sie oft die Form, in der Menschen, Modelle und Werkzeuge am zuverlässigsten zusammenarbeiten. Lesbarkeit ist hier kein Komfortdetail, sondern Teil der Architektur.

Wie ein solcher Ansatz konkret aussehen könnte

Für einen schlanken Stack würde schon ein erstaunlich kleines Set genügen. Außen ein leichtes CLI:

geist ask README.md
geist plan issue.md --json
geist review git.diff
geist patch fix-note.md > change.diff
geist run "Suche alle ungenutzten CSS-Klassen und schlage kleine Bereinigungen vor" \
  --allow search,files.read,files.write \
  --confirm write

Darunter eine kleine Sammlung von Diensten oder Servern für files, search, git, shell und docs. Optional darüber eine TUI für Diff-Review, Freigaben und kurze Verlaufssichten. Und ganz oben, wenn nötig, eine App oder Weboberfläche für Leitstand, Delegation und Teamkoordination.

Wenn mehrere Agenten hinzukommen, würde ich diese Logik nicht verstecken, sondern explizit machen. Dann gibt es etwa einen Plan-Agenten, einen Search-Agenten, einen Review-Agenten und einen Run-Agenten mit unterschiedlichen Rechten. Die Oberfläche muss daraus aber wieder etwas Einfaches machen: nicht vier konkurrierende Stimmen, sondern einen geordneten Arbeitsfluss mit klaren Zuständen.

Entscheidend ist die Reihenfolge. Erst der ruhige Kern, dann die komfortable Oberfläche. Nicht umgekehrt.

Was das für geisten bedeutet

Für geisten passt genau dieser Ansatz. Wir denken von lokaler KI, kleinen bis mittleren Modellen, CPU-effizienter Inference und kontrollierbaren Systemen her. Für uns ist die interessante Frage daher nicht, wie man die größte Agenten-App baut. Die interessantere Frage lautet: Wie baut man eine agentische Betriebsschicht, die auf kleinen Umgebungen läuft, sich gut überwachen lässt und vorhandene Werkzeuge ergänzt, statt sie zu verdecken?

Das spricht für Terminal-first, für klare Modi statt Universalchat, für MCP oder ähnliche offene Schnittstellen, für lokale stdio-basierte Tool-Kommunikation und für optionale Aufsichtsoberflächen, nicht für monolithische Super-Frontends. Es spricht außerdem eher für Schichten als für Magie: außen eine leichte Bedienoberfläche, darunter kleine Dienste für Suche, Dateien, Git, Shell und Dokumente, darunter Modelladapter für lokale oder entfernte Ausführung. Anders gesagt: nicht noch eine Chat-App, sondern eine nüchterne, leistungsfähige und gut komponierbare Erweiterung der Unix-Toolbox.

Fazit

Unix entstand, weil große Systeme zu schwer geworden waren. Diese Einsicht ist im Zeitalter agentischer LLMs plötzlich wieder sehr modern.

Auch heute stehen wir vor der Versuchung, immer größere, immer glattere und immer magischer wirkende Systeme zu bauen. Für manche Zwecke wird das sinnvoll sein. Für viele praktische, lokale und edge-nahe Anwendungen gilt wahrscheinlich das Gegenteil: Je wichtiger Kontrolle, Nachvollziehbarkeit und Effizienz werden, desto wertvoller werden kleine Werkzeuge, sichtbare Datenströme, klare Rechte und offene Schnittstellen.

Vielleicht ist das die eigentliche Pointe. Die Zukunft agentischer Systeme wird nicht allein in neuen Modellen entschieden. Sie wird auch an der Frage entschieden, ob wir wieder lernen, gute Werkzeuge zu bauen.

Weiterführende Quellen

Wenn Sie an einer lokalen, agentischen Kommandozeilen-UX für kleine Modelle, Edge-Systeme oder CPU-nahe Inference arbeiten, sprechen Sie uns gerne an: info@geisten.com