Aufteilung des Agentenkontexts in drei Ebenen zur Lösung des 700-Zeilen-Monolithen-Problems

Beim Aufbau persistenter autonomer Agenten tritt ein häufiges Problem auf: Der Agentenkontext beginnt in einer Datei, wächst aber auf 700+ Zeilen an und vermischt Identitätsregeln, aktuelle Strategie, Werkzeugreferenzen, Preisaktualisierungen und Veröffentlichungsverfahren. Dieser Monolith wird unhandlich – die Bearbeitung dessen, worauf diese Woche der Fokus liegen soll, befindet sich in derselben Datei wie „niemals das tun“-Regeln, was zu Zögern und Fehlern führt. Ein Team, das ein 6-Agenten-System aufbaut, das sich selbst von Null aus startet, stieß genau auf dieses Problem: In der zweiten Woche stieß der Launcher bereits an Argumentgrenzen und Sitzungen schlugen still fehl.

Die Drei-Ebenen-Aufteilung

Die Lösung bestand darin, den Agentenkontext nach Art der Anforderung und Änderungshäufigkeit in drei separate Dateien aufzuteilen:

• CLAUDE.md - Identität: wer der Agent ist, feste Regeln, Persönlichkeit. Ändert sich fast nie. Kann zwischengespeichert werden.
• BRIEFING.md - Mission: worauf jetzt der Fokus liegt, aktuelle Strategie, Preise, Ziele. Ändert sich wöchentlich.
• PLAYBOOK.md - Betrieb: wie man Dinge mechanisch erledigt: Verfahren, CLI-Befehle, Werkzeugreferenzen. Ändert sich, wenn sich Werkzeuge ändern.

Eine Information lebt genau in einer Ebene. Wenn eine Werkzeugreferenz im PLAYBOOK steht, steht sie nicht im BRIEFING. Dopplungen führen zu stillen Widersprüchen.

Warum diese Architektur funktioniert

Praktische Bearbeitung: Jeder weiß, welche Datei zu bearbeiten ist. Worauf soll der Fokus liegen? BRIEFING. Wie veröffentlichen? PLAYBOOK. Niemals das tun? CLAUDE.md. Kein Raten oder Durchsuchen von 700 Zeilen.

Technische Effizienz: Wenn ein Agent neu startet (was häufig vorkommt), bleibt die Identität stabil. Dasselbe CLAUDE.md wird für jede Sitzung verwendet, sodass Caching-Ebenen einen identischen Prompt-Präfix für nahezu kostenlose Cache-Treffer sehen. BRIEFING und PLAYBOOK kommen über Werkzeugaufrufe beim ersten Start – der Agent liest sie, bevor er substantielle Arbeit leistet, sodass sie nicht redundant sind. Das Startargument bleibt für immer klein, selbst wenn PLAYBOOK auf 2000+ Zeilen anwächst.

Disziplin: Ein Monolith akzeptiert beliebige Inhalte überall. Diese Spezifikation zwingt Sie zu fragen: Geht es um Charakter, Mission oder Mechanik? Diese Frage zu beantworten, verändert, wie Sie über das System denken.

Einfügemuster

Muster A (Einfach): Alle drei Dateien beim Start lesen, zusammenfügen und einfügen. Funktioniert, wenn die Gesamtgröße in das Argumentlimit Ihres Starters passt.

Muster B (Persistente Agenten): Nur CLAUDE.md beim Start einfügen. CLAUDE.md enthält eine Anweisung: Erste Aktion, lese BRIEFING.md und PLAYBOOK.md. Der Agent ruft zuerst Werkzeuge auf, um die Missions- und Betriebsdokumente zu laden, bevor die Arbeit beginnt. Der Start-Prompt bleibt klein, selbst wenn Playbooks wachsen. Dies ist die Standardeinstellung für Agenten, die neu starten.

Das Team verwendet Muster B. In jeder Sitzung wacht der Agent auf, liest BRIEFING, liest PLAYBOOK und führt dann aus. Frischer Kontext jedes Mal, zwischengespeicherte Identität, keine Angst vor Argumentgrenzen.

Ergebnisse nach der Implementierung

• Die Bearbeitung dauerte Sekunden statt Minuten – keine Angst, Unverwandtes zu beschädigen.
• BRIEFING-Bearbeitungen zwischen Sitzungen funktionieren einfach – der Agent liest beim nächsten Neustart das frische BRIEFING.
• PLAYBOOK wuchs auf 2000+ Zeilen ohne Startangst.
• Die Einarbeitung neuer Agenten war schneller – es gibt ein klares Skelett zum Ausfüllen.

Dieser Ansatz ist nicht revolutionär – es ist die Trennung der Anliegen, angewendet auf den Agentenkontext. Aber wenn man einmal auf das Monolith-Problem gestoßen ist, behebt dies es strukturell. Für Teams, die autonome Agenten aufbauen, die neu starten, ist diese Architektur es wert, bekannt zu sein.