Fünf Ebenen in Claude Code: Memory, Skills, Hooks, Subagenten und Plugins

Viele Ingenieure betrachten Claude Code als einen äußerst leistungsfähigen Programmierassistenten: Man öffnet ein Terminal, überträgt eine Aufgabe, lässt ihn Dateien lesen und Befehle ausführen sowie die Arbeit voranschreiten. Diese Beschreibung ist zwar zutreffend, aber unvollständig. Anthropics Dokumentation präsentiert es hingegen als ein agierendes Programmierwerkzeug, das im Terminal existiert, einen Codebase versteht, routinemäßige Aufgaben ausführt und über Mechanismen wie MCP auf externe Systeme zugreift. Bei genauerem Hinsehen handelt es sich bei dem Produkt weniger um ein in eine Kommandozeilen-Schale eingebettetes Modell als vielmehr um einen strukturierten Agenten-Runtime mit mehreren unterschiedlichen Steuerungsebenen.

Zu diesen Komponenten gehören eine CLAUDE.md-Datei, die als Speicherinhalte erhalten bleibt, wiederverwendbare Fähigkeiten, deterministische Hooks, Unteragenten, an die Aufgaben delegiert werden können, installierbare Plugins sowie MCP-Verbindungen zu externen Systemen. Dadurch ändert sich die relevante Fragestellung: Es ist weniger wichtig zu fragen, was Claude Code erzeugen kann, als vielmehr zu untersuchen, wie sein Verhalten geformt, eingeschränkt, spezialisiert und innerhalb eines Teams geteilt werden kann.

Eine Stack-Struktur in fünf Schichten

Ein Basismodell kann Code schreiben, Dateien erklären und Fragen beantworten. Allein lässt es jedoch mehrere Aspekte ungelöst: das Merken eines Projekts zwischen Sitzungen, die Wiederverwendung von Fachwissen, die Durchsetzung von Sicherheitsregeln auf Infrastrukturebene, die Beschränkung dessen, was delegiert wird, sowie die Gewährleistung eines konsistenten Verhaltens innerhalb eines Teams. Diese Probleme liegen außerhalb des Prompt-Formats, und das Design von Claude Code spiegelt dies zunehmend wider. In den Dokumentationen werden persistente Anweisungsdateien, erweiterbare Fähigkeiten, benutzerdefinierte Unteragenten, Hooks, Einstellungsrahmen, Plugins sowie MCP-Verbindungen als separate Mechanismen beschrieben. Zusammen bilden sie keine willkürliche Ansammlung von Funktionen, sondern Schichten, die das Verhalten der Agenten zuverlässiger, wiederverwendbarer und leichter handhabbar machen:

1. CLAUDE.md ist die Speicherschicht sowie die Schicht für Richtlinien.
2. Fähigkeiten bilden die Wissensschicht und stellen auf Anfrage Fachwissen bereit.

Hooks bilden die Schutzzäunerschicht, die Regeln deterministisch durchsetzt.

Subagenten sind die Delegationsschicht, die begrenzte Nebenaufgaben bewältigt.

Plugins zusammen mit eingeschränkten Einstellungen bilden die Verteilungsschicht.

MCP- und Agent-Team-Muster umschließen den gesamten Stack als Systeme, die ihn mit der Außenwelt verbinden.

Die Darstellung erklärt ein Muster in gescheiterten Agentenprojekten: Das Modell war selten der Schwachpunkt. Es fehlte eine Schicht. Ein Team verlässt sich vollständig auf Anweisungen ohne dauerhafte Projektmerkmale. Ein anderes hat ausführliche Anleitungen, aber keine deterministischen Kontrollen bezüglich des risikoreichen Tool-Verwendens. Ein drittes überlastet einen allgemein einsetzbaren Agenten, obwohl die Arbeit auf Spezialisten verteilt werden sollte. Die meisten Agentenfehler sind architektonischer Natur, nicht Probleme mit den Anweisungen. Jede Schicht wird im Folgenden erläutert, beginnend bei der Basis.

Warum eine architektonische Sichtweise einer Funktionsliste überlegen ist

Wenn man Claude Code als Liste von Funktionen betrachtet, stellt sich die Frage, was es kann. Wenn man es hingegen als Architektur betrachtet, entsteht eine bessere Frage: Welche Schichten stellt es bereit, um das Verhalten von Agenten zu steuern, einzuschränken, zu delegieren und zu teilen? Sobald sich die Frage ändert, wird es einfacher, über die Architektur nachzudenken – genauso wie bei der Diagnose, wenn im praktischen Einsatz etwas schiefgeht.

Aus der Dokumentation ergeben sich zwei Punkte. Erstens befindet sich keiner dieser Mechanismen innerhalb des Modells. Sie existieren außerhalb davon in Dateien, Ereignishandlern, Konfigurationsbereichen und Verpackungsformaten. Zweitens beantwortet jeder dieser Mechanismus ein anderes Problem: Das Gedächtnis hilft gegen Vergessen, Fähigkeiten regulieren allgemeines Verhalten, Hooks beheben Unzuverlässigkeit, Subagenten bewältigen überladene Kontexte und Plugins vermeiden den Aufwand, eine gute Einrichtung manuell immer wieder zu wiederholen.

Ebene eins: CLAUDE.md als Speicher

Die Grundlage ist CLAUDE.md. In den Dokumentationen wird es als Ort für dauerhafte Anweisungen beschrieben, wie in einem Projekt gearbeitet werden soll, während eine separate Auto-Speicherfunktion Notizen speichert, die Claude nach wiederholten Korrekturen und eigenen Präferenzen für sich selbst erstellt.

Diese Trennung ist wichtig. CLAUDE.md dient nicht als Notizblock für vorübergehende Anfragen. Teams legen hier langfristig gültigen Kontext ab: Coding-Standards, frühere Architekturentscheidungen, bevorzugte Bibliotheken, Überprüfungslisten und Arbeitsablaufbeschränkungen – alles, was vor der ersten Nachricht einer Sitzung sichtbar sein sollte.

Die interessante technische Seite ist die Art und Weise, wie er geladen wird. Es handelt sich dabei nicht um eine einzige Datei, die nur aus dem aktuellen Verzeichnis gelesen wird. Claude durchläuft den Verzeichnisspeicher vom Arbeitsverzeichnis aus und lädt jede CLAUDE.md- sowie CLAUDE.local.md-Datei, die er findet. Die Dateien werden zu einem Kontext zusammengefügt, anstatt sich gegenseitig zu überschreiben, und Anweisungen, die näher am Startverzeichnis liegen, werden später gelesen.

Das macht es zu einem begrenzten Speichersystem und nicht zu einer einzelnen Konfigurationsdatei. Eine Datei auf höchster Ebene kann repositoryweite Regeln wie Namenskonventionen, Erwartungen an Tests oder architektonische Grenzen enthalten, während eine Datei tiefer im Baum das Verhalten für ein bestimmtes Unterystem einschränken kann. Stellen Sie sich ein Monorepo vor: Die Wurzeldatei legt fest, wie Tests benannt werden und wo sich die Servicegrenzen befinden, während eine Datei im Verzeichnis „payments“ die strengeren Regeln hinzufügt, die nur dort gelten. Jeder, der eine Sitzung in diesem Verzeichnis startet, erhält beides, wobei die spezifischeren Anweisungen zuletzt gelesen werden.

Importe fördern die Kompositionsfähigkeit. Die Syntax @path/to/import ermöglicht es Teams, große Anweisungssätze in kleinere, wiederverwendbare Module aufzuteilen, sodass eine Markdown-Datei nicht zu einem Haufen unstrukturierter Inhalte wird. Launch erweitert die importierten Dateien im Kontext, und ein Import kann selbst weitere Importe enthalten – bis zu fünf Ebenen tief. In der Praxis verhält sich CLAUDE.md eher wie ein komponierbares Projektgedächtnis als wie ein statisches Prompt-Muster.

Die automatische Erinnerung und CLAUDE.md haben unterschiedliche Funktionen. Beide werden zu Beginn jeder Konversation geladen, doch CLAUDE.md enthält das, was Menschen absichtlich geschrieben haben, während die automatische Erinnerung Claudes eigene gesammelten Notizen in einem lokal auf dem Gerät befindlichen Verzeichnis speichert, das über MEMORY.md indiziert wird. Beim Start einer Sitzung werden nur die ersten 200 Zeilen oder 25 KB dieses Indexes geladen. Im Gegensatz dazu werden CLAUDE.md-Dateien unabhängig von ihrer Länge vollständig geladen, obwohl Anthropic feststellt, dass kürzere Dateien besser verfolgt werden können. Die eine Art der Erinnerung ist steuerbar und deklarativ; die andere ist anpassungsfähig und emergent.

Ein besseres mentales Modell als „Kontext einmal eingefügt, damit Claude einen Stil merkt“ ist eine Arbeitscharta für den Agenten. Anthropic legt sogar organisationsweite Orte für zentral verwaltete CLAUDE.md-Dateien auf den wichtigsten Desktop-Betriebssystemen fest, was darauf hindeutet, dass diese Ebene für dauerhafte Betriebsrichtlinien und nicht nur für persönlichen Geschmack gedacht ist. Dadurch müssen Teams bei jeder Sitzung nicht immer wieder dieselben Einschränkungen festlegen, und der Agent erhält eine stabile Ausgangsbasis, bevor mit arbeitsbezogenen Aufgaben begonnen wird.

Eine praktische Folge der Laderegeln ist, dass CLAUDE.md einer redaktionellen Pflege bedarf. Da jede entdeckte Datei vollständig geladen wird, entsteht in jeder Sitzung Überlastung, und die Empfehlung von Anthropic, kürzere Dateien zu bevorzugen, ist ein Grund für regelmäßiges Aussortieren. Verfahren, die die Dateigröße überschritten haben, sind die ersten Kandidaten für den Entfernung, was direkt zum nächsten Layer führt.

Zweiter Layer: Fähigkeiten als auf Anfrage verfügbares Wissen

Während CLAUDE.md als persistente Speicherung und Richtlinie dient, bieten Skills modulare Expertise, die genau dann zur Verfügung steht, wenn sie benötigt wird. Laut der Dokumentation erlangt Claude durch das Schreiben von Anweisungen in eine SKILL.md-Datei neue Fähigkeiten. Ein Slash-Befehl ruft eine Fähigkeit explizit auf, oder Claude kann sie von selbst heranziehen, wenn es entscheidet, dass die Aufgabe dazu passt.

Der architektonische Schlüsselpunkt ist die Zeitgestaltung. Der „Körper“ einer Fähigkeit stellt kein dauerhaftes Projektgedächtnis dar. Er wird nur dann in den Kontext eingebunden, wenn er benötigt wird, sodass wiederverwendbare Verfahren, Checklisten und fachliche Anleitungen hinzugefügt werden können, ohne jede Sitzung zu überlasten.

Viele Ingenieure betrachten die Anpassung als einen einzigen langen Prompt: Alles wird in den persistenten Kontext eingefügt, in der Hoffnung, dass das Modell herausfindet, was wichtig ist. Fähigkeiten bieten eine strukturiertere Lösung. Anthropic empfiehlt, solche Fähigkeiten zu erstellen, wenn dieselben Anweisungen immer wieder eingefügt werden oder wenn ein Abschnitt in CLAUDE.md von einer einfachen Tatsache zu einem Verfahren geworden ist. CLAUDE.md sollte dauerhafte Projektregeln enthalten, während Fähigkeiten wiederverwendbares operatives Wissen beinhalten sollten. Dadurch bleibt der ständig geladene Kontext übersichtlich und komplexe Arbeitsabläufe lassen sich in Module umwandeln, die Claude bei Bedarf heranziehen kann.

Fähigkeiten sind auch nicht einfach nur umbenannte benutzerdefinierte Befehle. Ältere .claude/commands/.md-Dateien und neuere .claude/skills//SKILL.md-Definitionen verhalten sich beim Aufruf ähnlich, doch Fähigkeiten bieten zusätzliche Steuerungsmöglichkeiten. Sie ermöglichen ein Verzeichnis mit unterstützenden Dateien, legen fest, ob der Benutzer, Claude oder beide sie auslösen dürfen, unterstützen die dynamische Einbindung von Kontexten und können sogar innerhalb eines Subagents ausgeführt werden. Deshalb passt der Begriff „Wissensschicht“: Eine Fähigkeit ist die Einheit, durch die Expertise, Verfahren und Aufgabekontexte innerhalb des Laufzeitumfelds kombinierbar werden.

Betrachten Sie eine Fähigkeit als ein versiegeltes Wissenspaket für eine bestimmte Art von Aufgabe. Ihre Beschreibung gibt den Zweck an, die Abgleichfunktion entscheidet bei der Ausführung, ob sie zur aktuellen Anfrage passt, und die darin enthaltenen Anweisungen werden nur dann geladen, wenn sie hilfreich sind. In der Dokumentation wird darauf hingewiesen, dass zusammengefasste Fähigkeiten wie /debug, /loop und /simplify promptbasiert sind und keine feste Logik folgen – was einen Aufschluss über das Design gibt. Dadurch wird das Verhalten modular, ohne dass alles in das Kernprodukt harteingekodet werden muss; dies ist ein weitaus skalierbareres Muster als die Erwartung, dass ein einziger großer Basisprompt alle Arbeitsabläufe abdeckt.

Betrachten wir ein Team mit einer Standardmethode zum Fehlersuchen bei unzuverlässigen Tests, zur Überprüfung von SQL-Migrationen oder zur Erstellung von Veröffentlichungshinweisen. Persistente Speicherlösungen sind für diese Aufgaben zu allgemein, und einmalige Anfragen wiederum zu repetitiv. Das Team packt den Ablauf einmal zusammen, legt Referenzmaterial daneben und lässt Claude es nur dann laden, wenn die Aufgabe dies erfordert. Langer Referenzinhalt innerhalb einer Fähigkeit kostet fast nichts, bis er verwendet wird – dadurch ist das Vorgehen übersichtlicher und auch günstiger in der Umsetzung.

Fähigkeiten belohnen daher die Gewohnheit, Wiederholungen zu erkennen. Immer dann, wenn dieselbe Erklärung zum dritten Mal eingegeben wird oder ein Absatz in CLAUDE.md anfängt, wie eine nummerierte Anleitung zu wirken, handelt es sich vermutlich um eine Fähigkeit, die extrahiert werden kann. Die Umsetzung kostet nur wenige Minuten und sichert sich jede Zeit, in der die Aufgabe erneut anfällt.

Insgesamt bieten CLAUDE.md dem Agenten stabile Grundregeln, während Skills ihm gezielte, wiederverwendbare Expertise liefern, ohne das Hauptkontextfenster zu überlasten. Die nächste Schicht sorgt dafür, dass dieses Verhalten sicherer wird.

Schicht drei: Hooks als Schutzmechanismen

Hooks verwandeln das Verhalten des Agents in etwas, das durchsetzbar ist. Die offiziellen Dokumentationen beschreiben sie als ereignisgesteuerte Automatisierung: Ein Befehl wird vor oder nach einer bestimmten Aktion in Claude Code ausgeführt, ausgelöst durch das jeweilige Ereignis. Die Hooks leiten und katalogisieren die typischen Anwendungsfälle: Automatische Formatierung von Code nach Änderungen, Ablehnung von Änderungen an geschützten Dateien, Wiederherstellung des Kontexts nach Komprimierung einer Konversation, Prüfung von Konfigurationsänderungen, Aktualisierung des Umgebungszustands bei Dateiänderungen sowie vorherige Genehmigung bestimmter Berechtigungsanfragen.

Das ist eine andere Aufgabe als das Erstellen von Prompten. Ein Prompt kann Verhalten vorschlagen; ein Hook kann dieses deterministisch abfangen oder umwandeln. Aus diesem Grund sollten Hooks eher als Schutzschicht betrachtet werden und nicht lediglich als praktisches Hilfsmittel für die Automatisierung.

Ein konkreter Fall stammt aus dem Kostenleitfaden: Ein PreToolUse-Hook fängt Bash-Befehle ab, erkennt Testläufe und überschreibt sie, sodass Claude nur Fehlermeldungen erhält und nicht den gesamten Ausgabestrom. Mechanisch erhält der Hook eine JSON-Datei mit Informationen zum ausstehenden Aufruf, prüft den Befehl und antwortet mit einer JSON-Datei, die die Eingabe für das Tool ändert. Dabei entscheidet die KI nicht selbst, was besser ist – es handelt sich vielmehr um Infrastruktur, die bestimmt, was das Modell zu diesem Zeitpunkt im Workflow sehen oder tun darf.

Der Kontrast zu den Regeln auf Prompt-Ebene verdient besondere Betonung. Sanfte Schutzmechanismen sind oft zu schwach für die Produktion. Angenommen, generierter Code muss stets neu formatiert werden, sensible Dateien dürfen sich niemals ändern oder zerstörerische Toolaufrufe erfordern eine strengere Überprüfung. Die alleinige Abhängigkeit von schriftlichen Anweisungen ist anfällig, während Hooks die Kontrolle außerhalb der Disposition des Modells verlagern und Workflow-Regeln auf Ereignisebene durchsetzen.

Hooks befinden sich außerdem neben der Kontextverwaltung und nicht darin. In den Fehlerbehebungsunterlagen wird „Hooks feuern nicht“ als eigenständiges Konfigurationsproblem aufgeführt, und es wird /doctor empfohlen, um Probleme mit Hooks, MCP-Servern und der Kontextnutzung zu diagnostizieren. Beide Aspekte zeigen, dass Hooks zum Ausführungsumfeld gehören: verhaltensbestimmende Konfigurationen, die korrekt in den Sitzungs-Runtime integriert werden müssen – und nicht einfach nur Texte, die Claude liest.

Auch aus Kostengründen ist dies von Bedeutung. Anthropics Kostenleitfaden empfiehlt, die Verarbeitung in Hooks und Skills zu verlagern, da Hooks große Eingaben vorab vorverarbeiten können, bevor das Modell sie überhaupt sieht. Als Beispiel wird das Filtern eines riesigen Testprotokolls auf nur die Fehlerrückmeldungen genannt, wodurch aus möglicherweise Zehntausenden von Tokens eine deutlich kleinere Datenmenge entsteht. Somit tragen Hooks nicht nur zur Sicherheit bei, sondern auch zur Effizienz: Sie reduzieren den Tokenverbrauch, halten den Kontext sauberer und ersparen dem Modell die vorhersehbare Filterarbeit, die durch deterministische Shell-Logik kostengünstiger und zuverlässiger erledigt werden kann.

Es hilft, sich ein Vorher-Nachher-Szenario vorzustellen. Vor den Hooks schreibt ein Team in die Anweisungen „führen Sie immer den Formatierer aus“ und hofft darauf. Mit den Hooks wird der Formatierer bei jeder Änderung ausgeführt – unabhängig davon, ob das Modell sich daran erinnert – und eine geschützte Datei kann einfach nicht geändert werden. Der Agent kann weiterhin frei entscheiden, was gebaut werden soll; die Hooks bestimmen jedoch, was in Bezug auf diese Entscheidungen erlaubt ist.

Die meisten Teams unterschätzen zunächst diese Ebene. Das Gedächtnis hilft dem Agenten, sich zu erinnern, und Fähigkeiten helfen ihm, sich zu spezialisieren, doch die Hooks wandeln wiederholte operative Erwartungen in Richtlinien um. Sie befinden sich genau dort, wo modellgesteuertes Denken auf systemseitig vorgeschriebenes Verhalten trifft – und genau dort treten viele Produktionsfehler auf. Ohne sie hängt die Qualität zu stark vom Prompt ab.

Ebene vier: Subagenten zur Delegation

Während Hooks die Steuerung bewältigen, kümmern sich Subagenten um die Delegation. In den Dokumentationen werden sie als spezialisierte KI-Assistenten beschrieben, die bestimmte Arten von Aufgaben in ihrem eigenen Kontextfenster bearbeiten und nur das Ergebnis zurückgeben.

Die Logik dahinter ist einfach. Eine der schnellsten Möglichkeiten, eine Sitzung zu beeinträchtigen, besteht darin, Nebenaufgaben zuzulassen, die das Hauptgespräch mit Protokollen, Suchergebnissen oder explorativen Überlegungen verunreinigen, die niemals wieder verwendet werden. Anstatt einen Allrounder durch alles in einem einzigen Thread zu zwingen, überträgt der Hauptagent eine Nebenaufgabe auf einen spezialisierten Worker, der unabhängig arbeitet und anschließend eine Zusammenfassung zurückgibt. Zu den Vorteilen gehören:

• Exploration und Umsetzung bleiben außerhalb des Hauptgesprächs und schützen so den Kontext.
• Eingeschränkter Tool-Zugriff sorgt für Konstruktionszwänge.
• Konfigurationen können in verschiedenen Projekten wiederverwendet werden.
• Fokussierte Anfragen spezialisieren das Verhalten.

Passende Aufgaben können an günstigere Modelle wie Haiku weitergeleitet werden, wodurch Kosten eingespart werden.

Ein Subagent als benannten Prompt zu bezeichnen, unterschätzt dessen Bedeutung. Tatsächlich handelt es sich um eine eigenständige Arbeitseinheit mit Beschreibung, Systemprompt, ausgewähltem Modell, einer Liste erlaubter Tools, Speichereinstellungen sowie einer Laufzeitgrenze.

Die integrierten Beispiele veranschaulichen die Funktionsweise. Explore ist für Lesezugriffssuche und Analyse von Codebasen optimiert, Plan dient zur Steuerung von Planungsaufgaben, und der allgemeine Agent übernimmt komplexe, mehrschrittige Aufgaben, die Überlegungen und Handlungen kombinieren. In den Dokumenten heißt es weiter, dass integrierte Subagenten die Berechtigungen der übergeordneten Konversation sowie zusätzliche Tool-Einschränkungen erben, wodurch die Delegation von vornherein begrenzt ist.

Noch eine Beschränkung: Subagenten rekursieren nicht. Laut Anthropic kann ein Subagent keine weiteren Subagenten erzeugen, und genau dadurch vermeidet Claude ein unendliches Nesting, während er dennoch den benötigten Kontext sammelt. Ohne eine klare Grenze kann die Delegation zu unkontrollierten Agentenstrukturen führen, die aufwändig in der Überwachung und im Verständnis sind. Das Modell bleibt einfach: Der Hauptagent weist die Aufgaben nach unten weiter, der Subagent erledigt sie isoliert und das Ergebnis kehrt wieder nach oben zurück.

Praktisch gesehen können Sub-Agenten in verschiedenen Ebenen konfiguriert werden. Sie können interaktiv mit dem Befehl /agents erstellt werden, pro Benutzer in ~/.claude/agents/ gespeichert werden, pro Projekt in .claude/agents/ gespeichert werden, für eine Sitzung über die Kommandozeile übergeben werden oder in Plugins enthalten sein. Jeder Sub-Agent ist eine Markdown-Datei mit YAML-Frontmatter, doch das von ihm definierte Verhalten ist umfangreich: Die Auswahl des Modells, der Zugriff auf Tools, das Speicherverhalten sowie Hooks und Fähigkeiten können alle auf diesen delegierten Worker beschränkt werden. Es handelt sich dabei um verpackte Ausführungsprofile, nicht um Rollenbezeichnungen.

Deshalb gehören Subagenten zu den wichtigsten Komponenten. CLAUDE.md verankert den Hauptagenten in Projektregeln, die Fähigkeitsbibliothek stellt modulare Expertise bereit und Hooks sorgen zur Laufzeit für die Einhaltung von Richtlinien – doch Subagenten verhindern, dass alles in ein überlastetes Gespräch mit zu vielen Verantwortlichkeiten mündet. Die Isolation ist der stillen Vorteil dabei: Ein Subagent kann Dutzende von Dateien lesen, Suchanfragen durchführen und Sackgassen verfolgen, ohne dass all diese Aktivitäten im Hauptthread landen, der nur das Ergebnis erhält. Sie ziehen klare Grenzen um die Nebenarbeiten, ermöglichen es Teams, sich auf bestimmte Arbeitsabläufe zu spezialisieren, und halten den Hauptkontext sauberer und länger erhalten. Mit der Delegation bleibt nur noch das organisatorische Problem: Wie all dies für ein Team strukturiert werden kann.

Auswahl des passenden Ortes für jede Regel

Durch die fünf verfügbaren Ebenen wird die Platzierung zu einer Gestaltungsentscheidung. Ein nützlicher Test besteht darin, zu prüfen, wie sich die Regel verhalten sollte. Muss sie stets bekannt sein, wird sie in CLAUDE.md platziert. Handelt es sich um einen nur gelegentlich benötigten Ablauf, wird er zu einer Fähigkeit. Muss sie unabhängig von der Entscheidung des Modells durchgesetzt werden, handelt es sich um einen Hook. Ist die Aufgabe unzuverlässig, selbstständig zu erledigen oder für ein günstigeres Modell geeignet, wird sie einem Subagenten übertragen. Muss die gesamte Anordnung übertragen werden, wird sie als Plugin verpackt. Regeln, die auf der falschen Ebene platziert werden, neigen dazu, auf bekannte Weise zu versagen: Eine in Prosa verfasste Richtlinie wird ignoriert, ein langer Ablauf im Speicher verdrängt alles andere, und eine raffinierte Einrichtung auf einem einzigen Laptop erreicht niemals das Team.

Ebene fünf: Plugins für die Verteilung

Nehmen wir an, ein Team verfügt bereits über seine Speicherdatei, seine Fähigkeiten, seine „Hooks“ sowie seine Unteragenten. Das Problem liegt dann nicht mehr im lokalen Verhalten, sondern in der Verteilung. Wie kann diese Konfiguration über Repositorien, Maschinen und Teammitglieder transportiert werden, ohne jedes Mal von Hand neu erstellt zu werden?

Anthropic bietet mehrere Mechanismen zum Verpacken und Wiederverwenden von Verhaltensweisen in verschiedenen Kontexten: Unteragenten auf Benutzer- und Projektebene, gemeinsam genutzte Fähigkeiten, Plugin-Einstellungen, eine im gesamten Unternehmen einheitliche CLAUDE.md-Implementierung sowie Plugins, die Code-Intelligenz oder andere Funktionen bereitstellen. Claude Code ist nicht nur für eine Person konfigurierbar; er dient zunehmend dazu, dass Teams das Verhalten des Agenten standardisieren und verteilen können.

Das klarste offizielle Signal ist das Plugin- und Einstellungsmodell. Die Dokumentation zu den Einstellungen beschreibt spezielle Abschnitte für die Konfiguration von Plugins, Allowlists sowie Berechtigungen wie codeIntelligence.*, sowie projektbezogene Einstellungen und von Benutzern übernommene Einstellungen. Zudem wird darauf hingewiesen, dass CLI-Argumente wie die Flags append-system-prompt und allowed-tools nicht auf Plugins übertragen werden, was bestätigt, dass Plugins als eigenständige Verteilungseinheiten mit eigener Verhaltensoberfläche fungieren und keine passiven Erweiterungen der übergeordneten Sitzung sind. Somit geht es bei Plugins weniger darum, Tools hinzuzufügen, sondern vielmehr darum, das Verhalten von Agenten zu verpacken, damit es in großem Umfang installiert, wiederverwendet und gesteuert werden kann.

Das gleiche Muster zeigt sich an anderen Stellen. Unteragenten unterstützen Installation auf Benutzer-Ebene, Projekt-Ebene, nur für die aktuelle Sitzung sowie durch Plugins definiert. Die Fähigkeiten folgen einem modularen Design, das es ermöglicht, wiederverwendbares Wissen außerhalb der stets geladenen Speicherschicht zu speichern. Die Architektur beschränkt sich nicht darauf, ob der Agent etwas tun kann; vielmehr fragt sie zunehmend danach, wie diese Fähigkeit verpackt und geteilt werden kann – ein Merkmal einer Plattform statt eines Einzelnutzer-Assistenten.

Auch die Governance gehört dazu. Ein gemeinsames Paket kann überprüfte Subagenten, streng begrenzte Tool-Rechte, Standard-Hooks oder für eine Organisation spezifische Workflows enthalten, sodass Teams Richtlinien verteilen und nicht nur Bequemlichkeit. Die Unternehmensweiten Pfade für zentral verwaltete CLAUDE.md-Dateien zeigen, dass die Standardisierung von Anfang an geplant war. Derselbe schichtweise Aufbau, der es einem Ingenieur erleichtert, kann zu einem für das gesamte Team geltenden Betriebsmodell werden, in dem Erinnerungen, Expertise, Kontrollmechanismen und Delegationen geteilt statt neu entwickelt werden.

Was passiert, wenn eine Schicht fehlt

Insgesamt bietet der Stack eine praktische Checkliste zur Diagnose einer unzuverlässigen Agenteneinrichtung. Das Symptom weist in der Regel auf die fehlende Schicht hin.

• Der Agent stellt immer wieder dieselben Fragen oder ignoriert den Stil des Hauses. Es fehlt an Gedächtnisfähigkeit. Nachhaltige Regeln sollten in CLAUDE.md gespeichert werden, nach Verzeichnissen strukturiert und in Importe aufgeteilt werden, damit die Dateien nicht zu groß werden.
• Jede Sitzung beginnt mit einem langen, eingefügten Verfahren. Das Wissen bleibt in den Anfragen gefangen. Die wiederholbaren Teile sollten in Fähigkeiten verschoben werden, damit sie nur dann geladen werden, wenn die Aufgabe es erfordert.
• Risikoreiche Aktionen hängen davon ab, ob das Modell daran denkt, vorsichtig zu sein. Schutzmaßnahmen sind nur Vorschläge. Hooks sorgen dafür, dass Formatierung, Dateischutz und Kommandoumbenennungen unabhängig von der Entscheidung des Modells stattfinden.
• Das Hauptgespräch ist voller Protokolle und Sackgassen. Es fehlt die Delegation. Unteragenten mit begrenzten Werkzeugen übernehmen die lästigen Nebenaufgaben und liefern anschließend eine Zusammenfassung.

Eine Konfiguration, die für eine Person funktioniert, versagt bei der nächsten. Es fehlt die Verteilung. Plugins, gemeinsam genutzte Einstellungen sowie zentral verwaltete Anleitungsdokumente sorgen dafür, dass sich das Verhalten in jedem Repository und bei jedem Teammitglied gleich verhält.

Der gemeinsame Nenner ist, dass keiner dieser Lösungsansätze einfach nur ein besseres Satzschema in einer Anweisung darstellt. Es handelt sich um strukturelle Änderungen, weshalb sie unter echten Arbeitslasten Bestand haben. Wenn man Claude Code als ein Agent-Entwicklungstool betrachtet, das zufällig in einer Terminalumgebung bereitgestellt wird, werden diese Änderungen leichter sichtbar, lassen sich besser mit dem Team besprechen und können gezielt, Schritt für Schritt, eingeführt werden.