Ich baue gerade an tmuxllm, einem agentischen Harness, der in einem tmux-Pane läuft. Der Großteil der Designarbeit drehte sich zuletzt um seine Erweiterung: Skills, Agenten, die Koordination mehrerer Agenten, konversationelles Provisioning. Jede Erweiterung begann als Architekturfrage, die sich neu anfühlte, und endete ungefähr am selben Ort: Die richtige Antwort war etwas, das Unix längst bietet, die falsche eine Schicht, die es schlecht nachbaute. Nach genügend solchen Runden war das Muster kein Zufall mehr, sondern eine These.
Meine These: Die CLI ist der richtige Endpunkt für Dienste, die LLMs nutzen, weil die Shell-Umgebung genau die Fähigkeiten bereitstellt, die LLM-Workflows brauchen, und zwar als Eigenschaften des Substrats, nicht als Features. Frameworks, die Dienste in eigene Protokolle verpacken, erfinden diese Fähigkeiten neu, manchmal schlechter, und verlieren dabei die LLM-Freundlichkeit einer Tool-Nutzung über Text.
Was LLM-Workflows wirklich brauchen
Wenn Sie einem LLM-gesteuerten Workflow beim Ablaufen zusehen, tauchen immer wieder drei Eigenschaften auf:
Die erste ist Flexibilität bei der Komposition. Ein LLM-gesteuerter Workflow lässt sich schwer im Voraus vorhersagen. Die Anfrage des Nutzers zerfällt vielleicht in zwei Schritte oder in zwölf. Sie verzweigt sich vielleicht anhand von Zwischenergebnissen. Vielleicht muss der Workflow zurückgehen und es neu versuchen, wenn ein Ansatz scheitert. Vielleicht muss er Alternativen parallel erkunden. Eine starre API kommt damit nicht zurecht. Eine aus der Shell aufgerufene CLI schon, denn die Shell hat bereits jedes Kompositions-Primitiv, das je gebraucht wurde: Pipes, Umleitungen, Subshells, Process Substitution, parallel, xargs, make.
Die zweite ist persistenter Zustand über Aufrufe hinweg. LLM-Workflows erstrecken sich oft über mehrere Turns, manchmal über Tage. Zwischenergebnisse müssen erhalten bleiben. Authentifizierungs-Token müssen irgendwo liegen. Gecachte Antworten sparen echtes Geld bei echten API-Rechnungen. All das erbt die CLI vom Substrat, auf dem sie läuft: dem Dateisystem, den Umgebungsvariablen, der Shell-Session des Nutzers, den üblichen Speicherorten aus der XDG Base Directory Specification.
Die dritte ist, dass sich funktionierende Abläufe festhalten lassen. Sobald ein LLM eine funktionierende Abfolge gefunden hat (die richtigen yt-dlp-Flags, das richtige awk zum Bereinigen der Ausgabe, den richtigen pretext-Aufruf), will diese Abfolge für die Wiederverwendung festgehalten werden. Mit einer CLI ist das trivial: Sie schreiben ein Shell-Skript. Mit einer API heißt festhalten, Client-Code in irgendeiner Sprache mit irgendeiner Bibliothek zu schreiben. Dieser Unterschied in der Reibung entscheidet mit darüber, ob sich festgehaltene Workflows mit der Zeit tatsächlich ansammeln.
Die CLI erfüllt alle drei Eigenschaften nicht, weil sie ein besonders cleveres Endpunktformat wäre, sondern weil sie das Endpunktformat ist, das bereits in einer Umgebung steckt, die diese Probleme löst. Die Shell löst die Komposition. Das Dateisystem löst die Persistenz. Shell-Skripte lösen das Festhalten. Die CLI erbt das alles, weil sie in der Shell lebt. LLM-gesteuerte Workflows haben bestimmte Eigenschaften, diese Eigenschaften decken sich genau mit dem, was die Shell-Umgebung von Haus aus bietet, also passt es strukturell, von LLMs aufgerufene Dienste in die Shell zu legen.
Das „LLM-freundlich“ leistet hier echte Arbeit
LLMs können manches gut und anderes schlecht, und die Asymmetrie ist schärfer, als oft zugegeben wird. Gut sind sie darin, Text in konventionellen Formaten zu erzeugen, strukturierte, aber flexible Daten wie JSON oder Markdown zu lesen und zu schreiben, über textbasierten Zwischenstand nachzudenken und Operationen zusammenzusetzen, für die sie dokumentierte Muster gesehen haben. Schlecht sind sie darin, komplexe zustandsbehaftete Objekte über Turns hinweg zu verwalten, Protokollen mit strikten Invarianten zu folgen, die das Modell nicht sehen kann, über Systeme nachzudenken, deren Verhalten sich nicht als Text darstellen lässt, und mit Operationen umzugehen, die viel undurchsichtigen internen Zustand haben.
Die CLI ist gerade deshalb „LLM-freundlich“, weil jede Eigenschaft der Arbeit über CLIs in die Stärkenzone fällt. CLI-Aufrufe sind Text. Die Ausgabe ist Text. Komposition ist Text: Ein Shell-Skript ist einfach nur Text. Zustand sind Dateien, und die sind Text oder als Text lesbar. Fehler sind Text, mit Exit-Codes und stderr, über die sich nachdenken lässt. Dokumentation ist Text, in Man-Pages und in der --help-Ausgabe, die das Modell anfordern und lesen kann.
Vergleichen Sie das mit einem Framework, das Dienste über Python-Objekte mit Zustand und Methoden bereitstellt. Das Modell muss eine mentale Repräsentation davon aufrechterhalten, welche Objekte existieren, welche Methoden sie haben, in welchem Zustand sie sind, wie Methodenaufrufe diesen Zustand verändern und wie sich Exceptions fortpflanzen. Genau darin sind Modelle schlecht. Kompositionen brechen auf subtile Weise, weil das Modell irgendwo zwischen zwei Methodenaufrufen den Überblick über den Zustand verloren hat.
Die CLI beseitigt diese ganze Fehlerkategorie, indem sie alles zu Text und allen Zustand extern macht. Das Modell braucht keinen mentalen Objektgraphen. Es erzeugt den nächsten Befehl, liest die Ausgabe, erzeugt den nächsten Befehl. Jeder Schritt ist begrenzt und überprüfbar. Die Aufgabe des Modells wird viel leichter, und nicht zufällig lassen sich auch die Fehlerbilder des Systems viel leichter debuggen.
Das ist kein Zufall. Das Design der Shell (Text rein, Text raus, Zustand in Dateien) trifft eben genau die Modalität, in der LLMs am besten arbeiten. Sie sind Text-Engines, die Shell ist eine über Text vermittelte Umgebung. Die Passung ist strukturell.
Warum Protokolle für den lokalen Fall die falsche Abstraktion sind
Der derzeit dominierende Ansatz im Bereich der LLM-Tools ist protokollbasiert, am prominentesten das Model Context Protocol (MCP), aber auch diverse proprietäre Tool-Call-Schemas. Das Argument für Protokolle ist stichhaltig: Sie liefern typisierte Schemas, strukturierte Argumente, Validierung und Interoperabilität zwischen Sprachen. In manchen Fällen sind das echte Gewinne.
Aber für den Hauptfall, „das LLM nutzt lokale Tools, um Arbeit zu erledigen“, ist der Protokollansatz strukturell schlechter als der CLI-Ansatz, und zwar aus drei Gründen.
Der erste: Protokolle zwingen die Komposition durch das Modell. Wenn Sie zwei protokollbasierte Tools A und B haben und B die Ausgabe von A verarbeiten soll, ist das LLM die Kompositionsschicht. Es ruft A auf, liest das Ergebnis, formatiert die Argumente für B, ruft B auf. Über jeden Zwischenschritt muss das Modell nachdenken. Mit CLIs schreiben Sie A | B und die Shell erledigt den Rest. Um diese Klempnerarbeit muss sich das LLM nicht kümmern.
Das ist nicht bloß ineffizient, es sind Token-Kosten, die sich aufsummieren. Eine Pipeline mit fünf Tool-Aufrufen braucht fünf LLM-Aufrufe für die Orchestrierung, jeder mit dem vollen Kontext im Gepäck. Dieselbe Pipeline als Shell-Befehl braucht einen LLM-Aufruf, der den Befehl erzeugt hat, und der Rest ist Shell-Ausführung.
Der zweite: Protokolle bauen Zustandsmechanismen schlecht nach. Die Shell hat längst Umgebungsvariablen, Dateien und Entsprechungen zu sessionStorage. Eine protokollbasierte Tool-Schicht erfindet diese meist als eigenes Zustandsmodell neu (Sessions, Kontexte, gecachte Tool-Ergebnisse), das im Framework lebt. Der Zustand ist damit auf zwei Systeme verteilt (Shell und Framework), das LLM sieht immer nur eines davon, und zum Debuggen müssen Sie beide verstehen. Eine CLI-basierte Tool-Schicht nutzt dagegen einfach den Zustand der Shell, den das Modell mit ls, cat, env untersuchen kann.
Der dritte: Protokolle lassen sich nicht mit bestehenden Unix-Tools kombinieren. Wenn Ihr Workflow lautet: „Daten von Dienst X holen, mit jq filtern, mit awk umformen, an Dienst Y schicken“, dann fügt sich die als CLI verpackte Version von X und Y sauber neben jq und awk in die Pipeline ein. Die Protokollversion verlangt, dass das LLM den Filter- und den Umformschritt vermittelt: entweder über weitere Protokoll-Tools (falls es welche für diese Operationen gibt) oder indem es in seinem eigenen Kontext über JSON nachdenkt (was Token verbrennt). Die CLI-Version erbt gratis die Unix-Werkzeuge aus Jahrzehnten. Die Protokollversion fängt bei Fähigkeiten, die die Shell seit fünfzig Jahren hat, bei null an.
Ich will hier allerdings vorsichtig sein. Protokolle sind nicht überall falsch. Bei tatsächlich entfernten Diensten, die Sie ohnehin per HTTP aufrufen würden, leistet die Protokollschicht echte Arbeit. In Sandbox-Umgebungen ohne Shell-Zugang brauchen Sie irgendetwas, und ein Protokoll ist vernünftig. Bei Diensten, die bidirektionales Streaming brauchen, können Protokolle das besser als CLIs. Das sind aber die Ausnahmen von einem Muster, in dem der Standardfall (lokale Dienste, mit denen das LLM arbeitet) besser zu CLIs passt als zu Protokollen.
Die Architekturantwort, die daraus folgt: Lokale CLIs sind die primäre Oberfläche, entfernte Dienste werden über CLI-Wrapper (gcloud, aws, kubectl, mcp-cli) erreicht, die sie zu lokalen Befehlen machen. In der Wrapper-Schicht steckt das Protokollzeug, versteckt hinter einem --help-Text. Ist der Dienst einmal verpackt, ist die Komposition wieder shell-nativ. Dieselbe These, mit einem zusätzlichen Schritt an der Grenze zwischen lokal und entfernt.
Was das für die Architektur bedeutet
Sobald Sie die These akzeptieren, werden mehrere Architekturentscheidungen zu erzwungenen Zügen statt zu Vorlieben. Ich gehe fünf davon durch.
Skills sollten CLI-Befehle sein. Ein Skill ist eine Einheit prozeduralen Wissens, das LLM-Gegenstück zu „wie man X macht“. Werden Skills als irgendetwas anderes als CLI-Befehle bereitgestellt, haben Sie zwischen LLM und Fähigkeit eine Nicht-Text-Schnittstelle eingeführt, und genau diese Reibung wollen wir vermeiden. Ein Skill ist ein Verzeichnis mit einer SKILL.md, eventuell ein paar mitgelieferten Skripten und einem Einstiegspunkt, der sich aus der Shell aufrufen lässt. Architektonisch komplizierter ist das nicht.
Zustand sollte im Dateisystem liegen. JSONL-Logs, Skill-Bibliotheken, Agentendefinitionen, Task-Queues: alles Dateien. Alles, was in undurchsichtigem Framework-Zustand steckt, ist für das LLM unsichtbar und neigt zum Auseinanderdriften. Das Modell kann mit ls ein Verzeichnis ansehen, mit cat eine JSON-Datei lesen, mit tail -f ein Log verfolgen. Einen Python-Objektgraphen kann es nicht auf dieselbe Weise untersuchen. Machen Sie den Zustand in dem Substrat sichtbar, in dem das Modell denkt.
Komposition sollte über die Shell laufen. Pipes, Skripte, make, xargs. Keine eigene DSL. Jedes Kompositions-Primitiv, das Sie bauen könnten, hat die Shell bereits, und das LLM kann schon damit umgehen, weil Shells in den Trainingsdaten stark vertreten sind. Eigene DSLs sind in Trainingsdaten kaum zu finden, die Shell dafür überall. Das Modell kennt die Shell.
Ausgaben sollten zuerst Text sein, JSON auf Anfrage. Standardmäßig menschenlesbare Ausgabe, dazu --json für strukturierte Ausgabe. Dieselbe Konvention wie git status gegenüber git status --porcelain. Die Textversion ist für Menschen und die beiläufige Nutzung durch LLMs, die JSON-Version für Skills, die in andere Skills pipen. Beide sind Text, beide lassen sich untersuchen, keine versteckt Zustand vor dem Modell.
Fehler sollten laut und lokalisierbar sein. Exit-Codes, stderr-Meldungen, rückverfolgbar auf bestimmte Befehle. Das LLM sollte den Fehler lesen und darüber nachdenken können. Stille Fehler sind der schlimmste Fall: Ein Tool meldet „success“, liefert aber falsche Ausgabe, und das Modell macht selbstsicher weiter. Laute Fehler mit auffindbarer Ursache lassen sich debuggen. Bauen Sie auf Debugbarkeit hin.
Das sind nicht fünf getrennte Entscheidungen, sondern dieselbe Entscheidung auf fünf Ebenen. Jede sagt: „Bleiben Sie in dem Substrat, in dem das LLM gut ist.“ Zusammen ergeben sie die architektonische Festlegung.
Die konvergierenden Belege
Boris Cherny, der Claude Code bei Anthropic leitet, hat es als „ein Unix-Werkzeug und kein traditionelles Produkt, gebaut aus den kleinsten Bausteinen, die nützlich, verständlich und erweiterbar sind“ beschrieben. Die Architektur investiert in deterministische Infrastruktur (Kontextverwaltung, Tool-Routing, Wiederherstellung) statt in Entscheidungsgerüste (explizite Planer oder Zustandsgraphen). Die Kernphilosophie: „Das Produkt ist das Modell“. Das Modell also möglichst direkt freilegen, mit einem minimalen Satz an Tools und minimalem Gerüst.
Die Kernschleife von Claude Code ist klein. Das Zustandsmodell ist minimal, im Wesentlichen ein Message-Array. Die Tools haben CLI-Form: Dateien lesen, Dateien bearbeiten, Shell-Befehle ausführen, suchen. Es gibt keine Workflow-Engine. Es gibt keinen Graphen von Zustandsübergängen. Es gibt keine DSL für die Komposition. Das Modell treibt die Schleife, die Shell führt die Arbeit aus, Dateien halten den Zustand.
Das ist dieselbe Architekturantwort, zu der tmuxllm nach und nach gekommen ist, nur konkret auf Softwareentwicklung angewandt. Zwei unabhängige Vorhaben, die bei derselben Architektur landen, sind ein ernstzunehmender Beleg dafür, dass die Architektur stimmt. Es sind nicht „zwei verschiedene Wetten“, sondern „zwei Umsetzungen der Schlussfolgerung, zu der sorgfältiges Nachdenken über LLMs plus Tools führt“.
Die meisten „KI-Agenten“-Frameworks auf dem Markt machen derzeit das Gegenteil. Sie bauen protokollbasierte Tool-Schichten, eigene Zustandsmodelle, Workflow-DSLs, frameworkspezifische Kompositions-Primitive. Ihr implizites Argument ist, dass dies die richtigen Abstraktionen sind. Die konvergierenden Belege aus tmuxllm und Claude Code sprechen dagegen: Das Substrat, auf dem der Agent läuft, bietet von all dem bereits bessere Versionen, und Frameworks, die sie neu erfinden, verlieren mehr, als sie gewinnen.
Ein Grenzfall, den man im Blick behalten sollte
Sollten sich LLMs so verbessern, dass sich ändert, worin sie gut sind (sagen wir, sie werden wirklich gut im Verwalten komplexer zustandsbehafteter Objektgraphen, oder sie werden so schnell, dass die Orchestrierungskosten für das Vermitteln jedes Schritts vernachlässigbar werden), dann schwächt das die These. Das Argument für CLIs und gegen Protokolle beruht auf den aktuellen Stärken und Schwächen der Modelle. Die können sich ändern.
Beim Stand von 2026 hält die These. Modelle sind immer noch Text-Engines. Sie tun sich immer noch schwer mit undurchsichtigem Zustand. Sie profitieren immer noch von untersuchbaren, dateibasierten Zwischenständen. Die Shell passt für lokale agentische Arbeit immer noch besser als das Protokoll. Das ist aber eine empirische Aussage über aktuelle Modelle, keine ewige Architekturwahrheit. Verschiebt sich die zugrunde liegende Aussage, sollte sich die Architektur mit ihr verschieben.
Beständiger finde ich allerdings das Metamuster: Beim Entwurf von Systemen für LLMs ist der richtige Zug, darauf zu schauen, worin das LLM tatsächlich gut ist, und das Substrat zu wählen, dessen Eigenschaften dazu passen. Heute sind das Text und Shell. Morgen ist es vielleicht etwas anderes. Die Disziplin lautet nicht „immer Shells verwenden“, sondern „das Substrat an die Stärkenzone des Modells anpassen und Substrateigenschaften nicht im Framework-Code nachbauen“.
Worauf ich als Nächstes achten würde
Überleben werden jene Agenten-Frameworks, die sich darauf einlassen, vom Substrat zu erben, statt dagegen anzukämpfen. Diejenigen, die die polierteste Framework-Abstraktion bauen, werden schneller Wartungslast anhäufen als Fähigkeiten und irgendwann von leichteren Alternativen abgelöst werden, die einfach die Shell aufrufen.
Das MCP-Ökosystem wird sich aufspalten: Gut gewartete CLI-Wrapper um entfernte Dienste dürften durchaus gedeihen, rein protokollbasierte Implementierungen lokaler Tools werden gegenüber Ansätzen mit Skills und Shell-Skripten wahrscheinlich an Boden verlieren. Das Wrapping-Muster (mcp-cli und Ähnliches) ist die Brücke zwischen beiden Welten und wird mit der Zeit stärker befahren werden.
Skill-Bibliotheken werden zur Einheit angesammelter Kompetenz in agentischen Systemen. Nicht Gesprächsverläufe im Vektorspeicher, nicht in Modellgewichte eingebranntes gelerntes Verhalten, nicht frameworkspezifische Plugins, sondern versionierte Skills, die im Dateisystem liegen, aus der Shell aufrufbar sind, über die Zeit geschrieben und zwischen Nutzern geteilt werden. Der Wert, der sich aufzinst, ist die Bibliothek, nicht der Agent.
Die Idee vom „Betriebssystem für KI-Agenten“ wird immer wieder aufgegriffen werden, und die Versuche werden immer wieder scheitern, denn das Betriebssystem gibt es schon. Es heißt Unix. Die Aufgabe ist nicht, ein neues OS für Agenten zu bauen, sondern eine dünne Runtime, mit der Agenten das vorhandene gut nutzen können.
Die Synthese
Nach genügend architektonischen Wendungen ist meine These eine meinungsstarke Wette auf eine einzige Aussage: LLMs arbeiten am besten, wenn ihre Fähigkeiten als CLI-Befehle in einer Shell-Umgebung bereitstehen, und die konsequent angewandten Folgen dieser Aussage ergeben ein brauchbares System.
Skills sind CLIs. Komposition ist Shell. Zustand ist Dateisystem. Koordination sind Prozessbäume. Verteilung sind Dateien. Jedes davon ist die substratnative Antwort auf ein Problem, das die meisten Frameworks mit eigener Maschinerie lösen. Jedes davon passt besser zur Nutzung durch LLMs, weil Text und Prozesse das native Medium des LLM sind.
Die Architektur ist eine Position. Die Position ist falsifizierbar. Stand 2026 hält sie. Die Arbeit von hier an besteht darin, weiterzubauen, damit die Implementierung die Aussage stützt, und die Vergleiche und Benchmarks zu veröffentlichen, mit denen andere sie falsifizieren könnten, wenn sie sie für falsch halten.
Wenn Sie ein System entwerfen, das LLMs nutzen sollen, lohnt sich vor dem Griff zum Protokoll die Frage: Was gibt mir dieses Protokoll, was die Shell nicht hat? Lautet die Antwort „Fernzugriff, Sandboxing oder bidirektionales Streaming“, gut, bauen Sie das Protokoll. Lautet sie „strukturierte Typen, validierte Argumente oder sprachübergreifende Aufrufe“, bedenken Sie, dass die Shell all das in anderer Form hat (--help-Text, Exit-Codes, JSON-Ausgabe, Befehlssuche) und dass es mehr kostet, das nachzubauen, als es wiederzuverwenden.
Unix hat die meisten dieser Probleme schon vor langer Zeit zufriedenstellend gelöst. Die Arbeit an der LLM-Tool-Integration besteht vor allem darin zu erkennen, welche Probleme Unix schon gelöst hat, und sie nicht noch einmal zu lösen.
Aus dem Englischen übersetzt: zum Originalbeitrag