Ein Blick in Claude Code: Es zählt das System, nicht das Modell
Es gibt einen präzisen Moment, in dem ein Assistent aufhört zu antworten und anfängt zu handeln. Das ist keine Frage der Intelligenz, zumindest nicht nur: Es ist eine Frage der Architektur. Klassische Chatbots funktionieren wie hochentwickelte Jukeboxen: Sie nehmen eine Anfrage entgegen und liefern ein Ergebnis. Coding-Agenten wie Claude Code tun etwas grundlegend anderes: Sie öffnen Dateien, führen Befehle aus, lesen das Ergebnis, korrigieren Fehler und wiederholen das Ganze – völlig eigenständig, bis die Aufgabe erledigt ist oder jemand sie stoppt. Dieser Sprung von der Autovervollständigung zur Autonomie ist nicht nur kosmetischer Natur. Er erfordert eine Infrastruktur, die Chatbots bisher nie aufbauen mussten.
Genau das ist das zentrale Thema von Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems, einem Tech Report, der im April 2026 von Forschern der Mohamed bin Zayed University of Artificial Intelligence und des University College London veröffentlicht wurde. Bei der Arbeit handelt es sich weder um eine Produktbewertung noch um einen Benchmark: Es ist eine Architekturanalyse, die durch direktes Lesen des öffentlichen TypeScript-Codes von Claude Code (in der Version v2.1.88) durchgeführt wurde. Dieser wurde mit OpenClaw verglichen, einem Open-Source-Agentensystem mit ähnlichen Zielen, aber sehr unterschiedlichen Designentscheidungen. Das Ergebnis ist etwas Seltenes in der KI-Literatur: eine fundierte Landkarte darüber, wie ein autonomer Agent wirklich gebaut wird und warum bestimmte Entscheidungen ihren Preis haben.
Ein notwendiger Warnhinweis, den die Autoren selbst aussprechen: Es handelt sich um eine Analyse der öffentlichen Codebasis, nicht um eine kausale Studie über die Performance in der Produktion. Einige Schlussfolgerungen sind eher architektonische Ableitungen als experimentelle Beweise. Die Architektur ist jedoch das aufschlussreichste Element überhaupt, denn Designentscheidungen verkörpern Werte, und Werte lassen sich im Code besser ablesen als in jeder Pressemitteilung.
Der Code um den Loop
Das technische Herz von Claude Code ist entwaffnend einfach: ein while-true-Loop, der das Modell aufruft, die Tools ausführt, die Ergebnisse sammelt und von vorn beginnt. Das gleiche Grundschema findet man in jedem Einführungs-Tutorial über LLM-Agenten. Darin liegt nicht der Wettbewerbsvorteil. Das Interessante – worauf das Paper systematisch fokussiert – ist der gesamte Code, der um diesen Loop herum liegt.
Es ist ein bisschen wie bei einem Formel-1-Motor: Technisch gesehen ist es ein Verbrennungsmotor wie der in Ihrem Auto, aber der wahre Vorteil von Ferrari in der Qualifikationsrunde liegt nicht im Otto-Zyklus, sondern im Wärmemanagementsystem, im elektrobetätigten Getriebe, in der aerodynamischen Simulation, die über den Winkel der Flügel entschieden hat.
Es gibt eine Zahl, die mehr wert ist als jede Unternehmenspräsentation: Laut der Codebasis-Analyse besteht Claude Code nur zu 1,6 % aus KI-Entscheidungslogik im engeren Sinne. Die restlichen 98,4 % sind operative Infrastruktur, Kontextmanagement, Tool-Routing und Retrieval-Pipelines. Das Modell – dasjenige, das in Pressemitteilungen immer auf dem Cover steht – nimmt weniger als zwei von hundert Zeilen ein. Der Rest ist das Gerüst, das es in der realen Welt nützlich macht.
Ebenso zeigt die Untersuchung von Claude Code, dass sich die tatsächliche Komplexität auf fünf Makro-Komponenten verteilt: ein Berechtigungssystem, eine Pipeline zur Kontextkomprimierung, vier Erweiterungsmechanismen, ein System zur Delegation an Subagenten und ein Session-Archiv mit einer Append-orientierten Struktur. Keine davon ist das „KI-Modell“. Alle bestimmen jedoch, ob das KI-Modell in der realen Welt etwas Nützliches bewirken kann.
Diese Verschiebung des architektonischen Schwerpunkts vom Modell zur umgebenden Infrastruktur ist die zentrale These des Papers und hat Auswirkungen, die weit über Claude Code hinausgehen: Sie legt nahe, dass das nächste Schlachtfeld im Krieg der Agenten nicht so sehr die Qualität des Basismodells sein wird, sondern die Solidität des Systems, das es enthält, begrenzt und befähigt.
Erst ablehnen, dann fragen
Das Berechtigungssystem von Claude Code basiert auf einem Prinzip, das in der IT-Sicherheit als deny by default (standardmäßige Ablehnung) bezeichnet wird: Der Agent darf nichts tun, es sei denn, er wird explizit dazu autorisiert. In der Praxis übersetzt sich dies in sieben Betriebsmodi, die von „Bestätigung für jede Aktion anfordern“ bis zu „autonomes Handeln innerhalb eines vordefinierten Rahmens“ reichen. Die Wahl des aktiven Modus ist nicht statisch: Sie hängt vom Kontext, der Session und der Art des Tools ab, das gerade aufgerufen werden soll.
Was das System besonders interessant macht, ist ein auf maschinellem Lernen basierender Klassifikator, der im Code als auto-mode classifier bezeichnet wird. Seine Aufgabe ist es, für jede vom Agenten angeforderte Aktion zu entscheiden, ob die Operation in die Kategorie „sicher für autonomes Handeln“ fällt oder ob sie die explizite Zustimmung des Benutzers erfordert. Die zugrunde liegende Logik ist raffiniert: Anstatt den Benutzer mit Bestätigungsanfragen für jedes Lesen einer Datei zu bombardieren (die sogenannte prompt fatigue, die Abstumpfung durch Benachrichtigungs-Overload, die dazu führt, dass Menschen überall auf „Ja“ klicken), versucht das System, die menschliche Kontrolle nur an den wirklich kritischen Punkten anzusetzen.
Der Vorteil ist offensichtlich: Ein Agent, der für jede Mikrotätigkeit um Erlaubnis fragt, wird unbrauchbar. Aber das spiegelbildliche Risiko ist ebenso real: Ein ML-Klassifikator, der entscheidet, was „sicher“ ist, führt eine subtile Angriffsfläche ein – nämlich jene Aktionen, die der Klassifikator nicht als gefährlich erkennt, obwohl sie es sind. Das Paper weist explizit auf dieses architektonische Spannungsfeld zwischen Sicherheit und operativer Autonomie hin, für das es keine endgültige Lösung gibt, sondern nur kontinuierliche Kalibrierungen. Die Autorisierungs-Pipeline fügt weitere Ebenen hinzu: Pre-Filtering, PreToolUse-Hooks, Regelauswertung und Permission Handler nacheinander. Es ist ein schichtweises, kein monolithisches System, was es erweiterbar, aber auch in seiner Gesamtheit komplex macht.
Das Gedächtnis, das vergisst
Wenn es ein Problem gibt, das jeder Entwickler kennt, der einen LLM-Agenten für komplexe Aufgaben eingesetzt hat, dann ist es dieses: Irgendwann, mitten in einer langen Arbeit, wirkt der Agent plötzlich verwirrt. Er verliert den Faden. Er wiederholt bereits ausgeführte Aktionen. Er trifft Entscheidungen, die den vorherigen widersprechen. Das ist kein Intelligenzproblem: Es ist ein Kontextproblem. Sprachmodelle haben ein begrenztes Kontextfenster, einen Arbeitsspeicher, der voll wird, und wenn er voll ist, muss entschieden werden, was behalten und was verworfen wird.
Die Lösung von Claude Code ist eine Pipeline zur Kontextkomprimierung, die in fünf Phasen unterteilt ist und im Paper als Budget Reduction, Snip, Microcompact, Context Collapse und Auto-Compact bezeichnet wird. Jede Phase entspricht einer anderen Reduktionsstrategie: vom einfachen Abschneiden weniger relevanter Abschnitte bis zur aktiven Zusammenfassung von Teilen der Konversation durch das Modell selbst. Der letzte Mechanismus, Auto-Compact, greift automatisch ein, wenn der Kontext sich dem Maximum nähert, und erstellt eine komprimierte Zusammenfassung der gesamten Sitzung, die dann als Ausgangspunkt für die Fortsetzung dient.
Der Trade-off hier ist real und unvermeidbar: Jede Komprimierung ist ein Verlust. Eine Zusammenfassung ist per Definition weniger informativ als das Original, und die Kohärenz bei sehr langen Aufgaben – die Stunden oder Tage dauern und viele Teile einer Codebasis berühren – leidet zwangsläufig. Es ist das Problem der Stillen Post angewandt auf KI: Jeder Komprimierungsschritt führt eine gewisse Verzerrung ein. Das Paper identifiziert das Speichermanagement als eine der sechs offenen Richtungen für Agentensysteme der Zukunft, da noch niemand eine zufriedenstellende Lösung gefunden hat, die weder Effizienz noch Kohärenz opfert.
Erweitern ohne zu explodieren
Eine der kniffligsten Designfragen für jede Plattform lautet: Wie fügt man Funktionen hinzu, ohne das System unüberschaubar zu machen? Claude Code antwortet mit vier verschiedenen Erweiterungsmechanismen: MCP-Server (Model Context Protocol), Plugins, Skills und Hooks. Das ist keine Redundanz, jeder dient einem spezifischen Zweck in der Architektur.
MCPs sind der am weitesten gefasste Mechanismus: Sie ermöglichen es, Claude Code über ein standardisiertes Protokoll mit externen Diensten zu verbinden, das Anthropic als offenen Standard für das Ökosystem entworfen hat. Plugins verändern das Verhalten des Agenten, indem sie neue Tools zu seinem Repertoire hinzufügen. Skills sind strukturierte Anweisungen, die den Agenten bei der Ausführung komplexer Prozeduren anleiten. Hooks sind der präziseste Mechanismus: Codestücke, die sich an exakten Stellen im Ausführungszyklus (Pre-Action, Post-Action) einfügen, um Operationen zu überwachen, zu transformieren oder zu blockieren. Das Paper beschreibt das tool pool assembly, also den Prozess, mit dem Claude Code entscheidet, welche Tools dem Agenten in jeder Sitzung zur Verfügung gestellt werden, als kritischen Moment, in dem diese vier Mechanismen ineinandergreifen.
Vier Mechanismen statt einem sind kein Fall von Over-Engineering: Es spiegelt die bewusste Entscheidung wider, Zuständigkeiten zu trennen. Ein Hook tut nicht dasselbe wie ein Plugin, und sie zu verwechseln, würde ein System hervorbringen, das oberflächlich einfacher, in der Praxis aber fragiler wäre. Das Risiko ist jedoch die kombinatorische Komplexität: Jeder Mechanismus interagiert mit den anderen, und die Angriffsfläche wächst mit jeder hinzugefügten Erweiterung. Hier kann die Grenze zwischen „mächtigem Tool“ und „Injektionsvektor“ fließend werden.
Agenten-Teams, Kontext-Inseln
Wenn eine Aufgabe zu groß für einen einzelnen Agenten ist, kann Claude Code sie an Subagenten delegieren. Der Mechanismus wird im Code einfach als Agent Tool bezeichnet und ist einer der stärksten Punkte der Architektur. Die Idee: Der Hauptagent zerlegt das Problem, überträgt Unterprobleme an separate Instanzen des Modells, sammelt die Ergebnisse und fasst sie zusammen. In der Praxis ist das wie das Management eines Teams: Der Projektleiter macht nicht alles selbst, sondern koordiniert Spezialisten.
Jeder Subagent agiert isoliert, mit seinem eigenen Kontext und optional seinem eigenen separaten Git-Worktree. Diese Isolation ist zugleich eine Stärke und eine Schwäche. Einerseits verhindert sie Störungen: Zwei Subagenten, die an verschiedenen Modulen desselben Projekts arbeiten, kommen sich nicht in die Quere. Andererseits erzeugt sie das, was das Paper als Kontext-Fragmentierung bezeichnet: Subagenten teilen ihr Wissen nicht automatisch, und das Zusammenfügen des verteilten Wissens erfordert einen expliziten Koordinationsaufwand. Wenn ein Subagent im Modul A etwas Wichtiges entdeckt hat, weiß der Subagent, der am Modul B arbeitet, nichts davon, es sei denn, der orchestrierende Agent übermittelt es explizit.
Die Transkripte der Subagenten, sogenannte sidechain transcripts, werden getrennt vom Haupttranskript der Sitzung aufbewahrt. Dies ist eine Entscheidung, die im Einklang mit dem allgemeinen architektonischen Prinzip des Systems steht: Alles ist Append-orientiert, alles ist verifizierbar, nichts wird gelöscht. Aber es erhöht die Komplexität des Sitzungsmanagements und wirft noch offene Fragen auf, wie ein zukünftiges System es Subagenten ermöglichen könnte, Wissen flüssiger zu teilen, ohne die Isolation zu gefährden, die sie zuverlässig macht.
OpenClaw im Spiegel
Der Vergleich mit OpenClaw ist für diejenigen, die nicht Claude Code an sich, sondern die allgemeinen Prinzipien des Agenten-Designs verstehen wollen, der lehrreichste Teil des Papers. OpenClaw ist ein Open-Source-System, das auf die Unterstützung persönlicher Kommunikation über mehrere Kanäle ausgerichtet ist: Es kann Nachrichten von Slack, Discord und anderen Kanälen empfangen und Agenten-Teams orchestrieren, die über einfache Markdown-Dateien konfiguriert werden. Gleiche Kategorie von Problem, sehr unterschiedliche architektonische Entscheidungen.
Der auffälligste Unterschied betrifft das Vertrauens- und Sicherheitsmodell. Claude Code setzt auf eine Pro-Aktion-Bewertung: Jedes Tool, jede Operation durchläuft die Autorisierungs-Pipeline. OpenClaw verschiebt die Kontrolle an den Rand des Systems: Der Zugriff wird am Eingang, im Gateway, geprüft, und einmal drinnen agieren die Agenten mit größerer Freiheit. Keiner der beiden Ansätze ist absolut falsch: Der erste ist granularer und besser für einen Kontext geeignet, in dem jede Aktion direkte Auswirkungen auf das Dateisystem des Benutzers haben kann; der zweite eignet sich eher für ein Gateway, das viele Agenten parallel verwalten muss, ohne zu einem Autorisierungs-Engpass zu werden.
Beim Kontextmanagement ist der Unterschied ebenso deutlich. Claude Code optimiert das individuelle Kontextfenster mit der oben beschriebenen Compaction-Pipeline. OpenClaw bevorzugt die zentrale Registrierung von Fähigkeiten auf Gateway-Ebene, wo die verfügbaren Tools global bekannt sind und nicht in jeder einzelnen Sitzung neu übergeben werden müssen. Der persistente Speicher von OpenClaw, der in vier Schichten strukturiert ist (Sitzung, täglich, langfristig und geteilt), adressiert das gleiche Problem wie die Compaction von Claude Code, jedoch mit einer entgegengesetzten Philosophie: Anstatt zu komprimieren und zu vergessen, wird archiviert und angesammelt. Beide zahlen einen Preis: Claude Code riskiert den Verlust der Kohärenz bei langen Aufgaben, OpenClaw riskiert die unkontrollierte Wucherung veralteter Speicherinhalte.
Was aus dem Vergleich hervorgeht, ist kein Ranking, sondern eine Lektion im Design: Dieselben grundlegenden architektonischen Fragen (wo die Sicherheit platziert wird, wie der Kontext verwaltet wird, wie die Delegation organisiert wird) führen zu unterschiedlichen Antworten, abhängig vom Deployment-Kontext, den Sicherheitsanforderungen und den Annahmen über die Benutzer. Es gibt keine universell richtige Architektur für KI-Agenten. Es gibt Trade-offs, die benannt werden müssen.
Systems Engineering, nicht Prompting
Im Paper findet sich ein Satz, der das gesamte Werk zusammenfasst: Der wahre Wettbewerbsvorteil von Agenten liegt nicht nur im Modell, sondern in der Infrastruktur, die es umgibt. Anders gesagt: Prompt Engineering, die Kunst, ein LLM durch geschickte Formulierungen dazu zu bringen, Dinge zu tun, wird zu einer immer weniger ausreichenden Kompetenz. Was wirklich zählt für diejenigen, die Agenten bauen, die in der Produktion, bei komplexen Aufgaben, in feindlichen oder einfach unvorhersehbaren Umgebungen funktionieren müssen, ist Systems Engineering: Zugriffskontrolle, Kontextmanagement, sichere Delegation, verifizierbare Persistenz.
Dies verändert das Profil der erforderlichen Kompetenz. Ein Coding-Agent ist kein KI-Produkt im engeren Sinne: Er ist ein Softwaresystem, das eine KI-Komponente als Reasoning-Engine nutzt, dessen Qualität aber von der Qualität der gesamten Architektur abhängt. Er ist näher an einem eingebetteten Betriebssystem als an einem hochentwickelten Chatbot.
Das Paper identifiziert sechs offene Richtungen: die Lücke zwischen Beobachtbarkeit und Bewertung schließen (heute ist es schwer zu verstehen, warum ein Agent stillschweigend gescheitert ist), echte sitzungsübergreifende Persistenz aufbauen, die Grenzen des Harness (des Rahmens, in dem der Agent agiert) weiterentwickeln, den Planungshorizont skalieren, die Governance autonomer Agenten in großem Maßstab angehen und die unbequemste Frage beantworten: Verstärken aktuelle Agenten zwar kurzfristig die menschlichen Fähigkeiten, tragen aber langfristig zum Wachstum menschlicher Kompetenzen bei oder erodieren sie diese?
Diese letzte Frage ist nicht rhetorisch. Ein System, das zu gut automatisiert, riskiert, das tiefe Verständnis, das die Automatisierung erst ermöglicht, überflüssig zu machen. Es ist das Autopiloten-Syndrom angewandt auf Software: Je besser er wird, desto weniger erinnert sich der Pilot daran, wie man fliegt. Das Paper nennt dies „long-term capability preservation“ und lässt es ehrlicherweise als offene Frage stehen.
Das Hauptverdienst dieser Arbeit ist methodischer Natur: der Nachweis, dass man architektonische Archäologie an einem Produktionssystem betreiben kann, indem man den öffentlichen Code liest, und dass diese Archäologie echte Erkenntnisse über die Zukunft des Sektors liefert. Die Grenzen sind die genannten: kein kausaler Benchmark, keine empirische Validierung der Performance und eine Analyse, die an eine präzise Momentaufnahme des Codes gebunden ist (Version v2.1.88), die sich bereits geändert haben könnte. Aber die konzeptionelle Struktur, die zum Vorschein kommt – die Landkarte der Trade-offs zwischen Sicherheit und Autonomie, zwischen Gedächtnis und Kohärenz, zwischen Erweiterbarkeit und Komplexität –, ist stabil genug, um mehr als ein Versionsupdate zu überdauern.