Die Qualität eines Programmieragenten nimmt häufig nicht deshalb ab, weil das Modell weniger leistungsfähig geworden ist, sondern weil dem Projekt ein klares Betriebssystem fehlt, das steuert, was der Agent liest, was er tut und wie seine Änderungen überprüft werden. Wenn sich die Arbeit über Wochen und Tausende von Änderungen erstreckt, kann der Agent dieselben Dateien erneut untersuchen, einer früheren Entscheidung widersprechen, den Testbefehl erraten oder aufhören, Tests zu schreiben, wenn diese Schritte nicht verbindlich vorgegeben werden.
Im sechsten Teil der Reihe „Betrieb von LLM-Systemen in der Produktion“ schlägt der Stack Overflow Blog vor, eine organisatorische Schicht um das Modell herum aufzubauen. Dazu gehören eine kurze Projektverfassung, Grenzen der Autonomie, ein mehrstufiger Kontext, dauerhafter Speicher, ein Überprüfungsgremium und ein Hook, der nach jeder Änderung ausgeführt wird. Wenn mehrere Agenten am selben Repository arbeiten, kommen eine Eigentümerkarte für Dateien sowie Protokolle gemeinsamer Prompts und Entscheidungen hinzu.
Das Problem liegt im Betriebsgürtel, nicht nur im Modell
Der Artikel definiert den Agenten als das Modell plus Anweisungen, Werkzeuge, Kontext-Richtlinien, Hooks, Isolation, Unteragenten und Überwachungsmechanismen. Er verweist auf ein allgemeines Ergebnis des Benchmarks Terminal-Bench 2.0: LangChain brachte einen Agenten allein durch eine Änderung des Betriebsgürtels von außerhalb der Top 30 in die Top 5. Die Punktzahl stieg dabei von 52,8 % auf 66,5 %, also um 13,7 Punkte, während dasselbe Modell beibehalten wurde.
Die praktische Schlussfolgerung lautet, dass unvollständige Werkzeuge, unklare Regeln oder ein überfüllter Kontext die am leichtesten behebbaren Fehlerursachen sein können. Anders als das Modell kann das Entwicklungsteam diese Schicht anpassen und auf sein Repository abstimmen.
Sechs Elemente für einen disziplinierten einzelnen Agenten
- Projektverfassung: Eine Datei wie CLAUDE.md oder AGENTS.md legt den Arbeitsablauf fest: Planung, Dokumentation, Implementierung, Tests, Überprüfung und anschließend der Commit. Sie sollte Qualitätsstandards und Grenzen für die Nutzung von Anbieterpaketen enthalten und kurz bleiben, da sie in jeder Sitzung gelesen wird.
- Grenzen der Autonomie: Der Agent darf umkehrbare Vorgänge wie Lesen, Bearbeiten, Testen und das Erstellen von Commits ausführen, während Push, Deployment und das Anwenden von Infrastrukturänderungen eine Genehmigung erfordern. Die Semantik der Befehlsübereinstimmung muss überprüft werden, damit weit gefasste Regeln wie npm:* nicht versehentlich eine Veröffentlichung erlauben.
- Mehrstufiger Kontext: Die Datei CONTEXT.md im Stammverzeichnis enthält eine Karte des Projekts sowie Informationen dazu, wie es ausgeführt und getestet wird. Die Datei jeder Einheit erläutert deren Zuständigkeit, Dateien und Abhängigkeiten. DECISIONS.md hält Entscheidungen, ihre Gründe und abgelehnte Alternativen fest. Veralteter Kontext gilt als Fehler, der in derselben Änderung korrigiert werden muss.
- Dauerhafter Speicher: Der Beitrag schlägt separate Speicherdateien für jede Tatsache, einen kurzen Index und eine Datei graph.jsonl vor, die Einheiten und Entscheidungen über Beziehungen wie „hängt ab von“ oder „ersetzt“ miteinander verknüpft.
- Überprüfungsgremium mit mehreren Perspektiven: Unteragenten überprüfen die Änderung aus den Perspektiven von Produkt, Engineering, Infrastruktur, Sicherheit und Tests. Eine Änderung wird nur wegen eines Blockers oder eines schwerwiegenden Problems mit hoher Zuverlässigkeit verhindert.
- Hook nach der Änderung: PostToolUse wird nach jedem Edit, Write oder MultiEdit ausgeführt und gibt eine Checkliste aus, die daran erinnert, Kontext, Speicher und Entscheidungsprotokoll in derselben Änderung zu aktualisieren, anstatt Dateien stillschweigend neu zu schreiben.
Beim Betrieb einer Flotte von Agenten
Ein neues Problem entsteht, wenn mehrere Agenten am selben Repository arbeiten: Sie ändern dieselben Dateien oder machen die Entscheidungen der anderen rückgängig. Der Artikel empfiehlt nicht, sich auf direkte Gespräche zwischen ihnen zu verlassen, sondern auf einen gemeinsam genutzten, schriftlichen und prüfbaren Zustand. Dazu gehören eine Eigentümerkarte für Pfade, CLAIM- und RELEASE-Protokolle, ein Fortschrittsprotokoll sowie ein eigener Branch für jede Aufgabe mit menschlicher Zusammenführung.
Diese Ansprüche stellen keine echte Sperre dar: Zwei Agenten können denselben Zustand lesen und gleichzeitig denselben Pfad beanspruchen. Wenn eine tatsächliche Isolation erforderlich ist, empfiehlt der Artikel einen atomaren Mechanismus wie einen Git-Branch mit eindeutigem Namen oder ein bedingtes Schreiben in einen Koordinationsspeicher.
Warum ist dieser Ansatz wichtig?
Die eigentliche Veränderung besteht darin, den Fokus von der Fähigkeit des Agenten, eine Funktion zu schreiben, auf die Fähigkeit des ihn umgebenden Systems zu verlagern, ihn über die Zeit hinweg ausgerichtet und überprüfbar zu halten. Das Entscheidungsprotokoll erfüllt dabei nicht nur eine dokumentarische, sondern auch eine vertragliche Funktion: Alte Entscheidungen werden nicht geändert, sondern durch neue Entscheidungen ersetzt, wobei der Grund und die abgelehnten Alternativen erläutert werden. So bleibt die Entwurfsgeschichte sichtbar und kann mit automatisierten Prüfungen verknüpft werden, etwa mit dem Verbot bestimmter Importe.
Dieser Ansatz bleibt eine organisatorische Anleitung und keine Garantie für die Richtigkeit der Ausgaben. Der Artikel räumt außerdem ein, dass dateibasierte Ansprüche bei gleichzeitigen Kollisionen nur beratenden Charakter haben und dass die menschliche Überprüfung beim Zusammenführen, Pushen und Deployment weiterhin der Kontrollpunkt bleibt. Die Quintessenz des Beitrags lautet, dass die Eindämmung des Modells und der Aufbau prüfbarer Spuren die Zuverlässigkeit langfristiger Arbeit stärker beeinflussen können als das Warten auf ein intelligenteres Modell.