Warum ich „Agents Record, Optimizer Thinks" gewählt habe
Als 18 Agenten jeweils ihre eigenen Memory-Dateien pflegten, wurde das System unwartbar. Die Lösung war eine klare Trennung: Daten sammeln ist eine Aufgabe, Wissen destillieren eine andere.
Als die Memory-Datei meines TypeScript-Implementierers auf 95 KB angewachsen war — die ganze Geschichte dazu — war die eigentliche Frage nicht, wie ich sie kürze. Sondern warum die Architektur das überhaupt zugelassen hat.
Das Problem war nicht der Speicherplatz. 95 KB ist nichts. Das Problem war das fehlende Curation. Eine Datei, die alles aufzeichnet, enthält nichts Nützliches — sie ist einfach ein Log, und Logs sind kein Wissen.
Die Erkenntnis
Ich hab über dieses Problem nachgedacht und dabei eine Parallele bemerkt, die ich aus der Softwareentwicklung kannte:
Monitoring und Alerting sind nicht dasselbe. Du sammelst alles. Alerts kommen nur auf das, was wirklich zählt.
Logging und Analyse sind nicht dasselbe. Du loggst Events. Du analysierst sie separat, um Muster zu finden.
Event Sourcing und Read Models sind nicht dasselbe. Du speicherst jeden Event. Du baust projizierte Views, die fürs Lesen optimiert sind.
In all diesen Mustern gibt es einen Producer und einen Consumer — und sie sind bewusst getrennt, weil die Anforderungen ans Produzieren und Konsumieren verschieden sind. Produzieren soll günstig und vollständig sein. Konsumieren soll schnell und relevant sein.
Meine Agenten hatten diese Trennung nicht. Sie haben aus derselben undifferenzierten Datei produziert und konsumiert.
Die neue Architektur
Ich hab alles nach einem Prinzip neu gebaut: Agenten zeichnen auf. Ein separater Optimizer denkt nach.
Die operativen Logs. Sechs themenbasierte Logs, in die alle 18 Agenten schreiben:
build-systems.log— Build-Tool-Verhalten, Abhängigkeitsprobleme, Kompilierungsmustergit-operations.log— Git-Workflow-Muster, Merge-Strategien, Branch-Konventioneninfrastructure.log— Deployment-Muster, Docker-Verhalten, Umgebungsproblemeplanning.log— Zerlegungsmuster, Schätzungs-Erkenntnisse, Planungsergebnissecode-quality.log— Refactoring-Muster, Review-Ergebnisse, Qualitätsbeobachtungenmeta.log— Agenten-Koordinationsmuster, Tooling-Verhalten, Systembeobachtungen
Agenten schreiben in diese Logs nur append. Kein Lesen. Kein Curation. Nur aufzeichnen.
Der Optimizer-Agent. Ein separater Agent — kein Teil eines Workflow-Teams — der periodisch läuft. Er liest die operativen Logs, erkennt Muster, die drei oder mehr Mal vorkommen, und übersetzt diese Muster in konkrete Agenten-Anweisungen.
Der Schwellenwert ist wichtig. Ein Vorkommen kann Zufall sein. Zwei auch noch. Drei ist ein Muster, das es verdient, festgehalten zu werden.
Die Agenten-Anweisungen. Das Einzige, was Agenten über vergangene Erkenntnisse lesen. Keine rohen Logs — kuratierte Anweisungen. Der Optimizer produziert Zeilen wie: „Beim Bauen von Docker-Images immer die Node-Version im Dockerfile mit der lokalen Version abgleichen; Unterschiede verursachen ES-Modul-Auflösungsfehler.” Das ist das destillierte Ergebnis mehrerer Build-Failure-Logs, reduziert auf eine handlungsrelevante Regel.
Log-Archivierung. Logs werden monatlich archiviert. Alte operative Daten hören auf, sich anzuhäufen. Die Agenten-Anweisungen tragen alles weiter, was es wert war, weitergetragen zu werden.
Die Parallelen sind kein Zufall
Ich möchte explizit machen, warum ich diese Architektur für richtig halte — nicht nur weil sie besser funktioniert.
Das Muster, Beobachtung von Erkenntnis zu trennen, taucht in jeder reifen Engineering-Praxis auf, und das hat einen Grund. Wer beides vermischt, baut Systeme, die auf eine bestimmte Weise brüchig werden: Sie werden schwerer zu benutzen, je mehr Informationen sie ansammeln. Das ist falsch herum. Systeme sollten mit mehr Informationen nützlicher werden — nicht weniger.
Mein Anfangsfehler war zu denken, mehr Information im Kontext des Agenten = fähigerer Agent. Das stimmt nur, wenn die Information relevant ist. Irrelevante Information im Kontext hilft nicht nur nicht — sie schadet aktiv, weil sie das Signal verwässert. (Das dreistufige Memory-System, das ich früher gebaut hatte, hat das auf Projektebene richtig gemacht — das Problem war, auf Agent-Ebene ein anderes, schlechteres Modell zu verwenden.)
Curation ist die eigentliche Arbeit. Beobachten ist billig.
Microservices trennen Zuständigkeiten nicht, weil Verteilung an sich gut ist, sondern weil manche Zuständigkeiten unterschiedlich skalieren. Build-Prozesse häufen Fehler in einem Tempo an; die Verarbeitung von Beobachtungen produziert Erkenntnisse in einem anderen Tempo. Wer beides trennt, lässt beides unabhängig wachsen.
Read Models in CQRS sind nicht die Quelle der Wahrheit — sie sind optimierte Projektionen. Agenten-Anweisungen sind nicht die rohe Historie; sie sind optimierte Projektionen von dem, was aus dieser Historie zählt.
Was sich verändert hat
Die praktischen Auswirkungen:
Agenten sind leichter. Anweisungen sind durch Design knapp — kuratiert, nicht angehäuft. Der Kontext-Verbrauch beim Session-Start ist deutlich gesunken.
Wissen wird kuratiert. Nur Muster, die wiederholt auftauchen, landen in den Agenten-Anweisungen. Einmalige Erkenntnisse, die sich nicht verallgemeinern lassen, verschwinden still bei der Archivierung.
Wissen wird geteilt. Wenn der Kotlin-Agent und der TypeScript-Agent unabhängig voneinander ähnliche Docker-Build-Fehler loggen, sieht der Optimizer das Muster über beide Logs hinweg und kodiert es als allgemeine Regel für alle Agenten. In der ursprünglichen Architektur wäre diese Erkenntnis im Silo geblieben.
Das System ist wartbar. Ich kann die Agenten-Anweisungen lesen und verstehen. Ich sehe, was der Optimizer aus den Logs destilliert hat. Ich kann eingreifen, wenn ein Muster falsch kodiert wurde. All das war mit den 95-KB-MEMORY.md-Dateien nicht möglich.
Das Prinzip
Separation of Concerns gilt nicht nur für Code. Sie gilt auch für Wissenssysteme.
Wenn du Multi-Agenten-Systeme mit persistentem Gedächtnis baust, lautet die Frage nicht „wo speichern Agenten, was sie lernen?” Die Frage ist: „Wer ist für das Curation zuständig?” Wenn die Antwort lautet „jeder Agent kuratiert sein eigenes Gedächtnis”, landest du genau da, wo ich gelandet bin: 18 MEMORY.md-Dateien, die grenzenlos wachsen und irgendwann von Rauschen nicht mehr zu unterscheiden sind.
Gib den Agenten die Beobachtung. Gib einem dedizierten Optimizer das Curation. Lass jeden das machen, was er gut kann.