Wie man einen AI-Agenten zu seinem eigenen macht
(monet.team-monet.com)Wer als Entwickler jeden Tag mit einem AI-Coding-Agenten arbeitet, kennt dieses Gefühl.
Gestern haben wir diese Konvention doch ganz sicher gemeinsam festgelegt, aber sobald eine neue Session startet, ist alles wieder blank. Dass ich in TypeScript immer type statt interface verwende, dass ich in einem PR-Review gesagt habe, dieses Pattern sei nicht besonders gut, die eigentliche Ursache des Bugs, den wir letzte Woche endlich gefunden haben — bei all dem muss ich so tun, als wäre es eine Geschichte, die der Agent zum ersten Mal hört.
Wenn sich das wiederholt, landet man irgendwann bei: „Dann mache ich es eben selbst.“
Um dieses Problem zu lösen, habe ich Monet gebaut. Ein System, das einen generischen AI-Agenten so arbeiten lässt, als wäre es mein Agent. Er lernt meine Konventionen, merkt sich meine bevorzugten Vorgehensweisen und behält die Geschichte des Projekts im Blick.
Wie funktioniert es?
Der Kern ist einfach.
Schreiben — der Agent entscheidet selbst. Ohne dass man „Merk dir das“ sagen muss, protokolliert er von selbst Entscheidungen aus der Arbeit, entdeckte Patterns und aufgetretene Probleme. Er filtert Rauschen heraus und behält nur das Signal.
Lesen — das Nützliche kommt zuerst. Es ist keine einfache Keyword-Suche. Erinnerungen, auf die tatsächlich oft Bezug genommen wurde und die beim Lösen von Problemen geholfen haben, werden priorisiert angezeigt. Zombie-Notizen, die niemand sucht, rutschen ganz natürlich nach hinten.
Wachstum — je mehr sich ansammelt, desto schlauer wird es. Die erste Aufgabe ist langsamer. Der Agent kennt die Codebasis nicht, die Konventionen nicht und auch nicht die Bugs, die regelmäßig auftreten. Aber sobald sich Speicher ansammelt, geht die nächste Aufgabe schneller. Das gestern gefundene Pattern, die letzte Woche getroffene Entscheidung, die eigentliche Ursache dieses Bugs — man muss nichts mehr erneut suchen. Nach etwa einem Monat ist dieser Agent kein generisches Tool mehr, sondern arbeitet wie mein dedizierter Engineer, der dieses Projekt in- und auswendig kennt.
Wie es so weit kam
Am Anfang habe ich einfach Notizen in einer Datei gesammelt. Dinge, die der Agent während der Arbeit gelernt hatte, schrieb ich in Markdown auf und band sie beim Start einer neuen Session ein. Das war simpel, aber je mehr sich ansammelte, desto mehr Rauschen entstand.
Also habe ich vor vier Monaten ein richtiges Memory-System gebaut. Das alte Monet. Es war auf MCP-Basis so entworfen, dass Agenten daraus lesen und hineinschreiben konnten, und Team-Sharing war gleich mitgedacht. Aber weil ich mich auf Team-Sharing konzentriert hatte, wurde die Erfahrung für die Solo-Nutzung irgendwie unklar. Es funktionierte zwar irgendwie, fühlte sich aber nicht passend für meinen Workflow an.
Also habe ich es komplett neu aufgebaut. Vor ein paar Wochen habe ich das Ziel Team-Sharing vorerst beiseitegelegt und Monet von Grund auf neu gebaut — mit Fokus auf genau eine Frage: „Kann ich das wirklich jeden Tag benutzen?“ Während ich diesen Text schreibe, lesen und schreiben 12 Agenten auf dem neuen Monet. Exakte Zahlen kann ich noch nicht liefern, weil es noch kein Monitoring gibt, aber die Suchanfragen sind deutlich zurückgegangen, während Lesen und Schreiben stark zugenommen haben. Das heißt: Die Agenten wählen wichtige Dinge selbst aus und sammeln sie an.
Ganz ehrlich
In der Vibe-Coding-Phase ist Memory nicht besonders wichtig. Meistens baut man neue Features, und Bugs sind einfach. Wenn man dem Agenten sagt: „Beheb das mal“, ist die Sache innerhalb des Context Window erledigt.
Aber je komplexer die App wird, desto mehr ändert sich das Bild. Um eine einzige Zeile Code zu ändern, muss man zehn zusammenhängende Logiken prüfen, und der Agent kriecht auf der Suche nach Side Effects durch Datei um Datei. Fehler nehmen ebenfalls zu. Selbst mit 1M Tokens steht man nach dreimaliger Kontextkomprimierung wieder am Anfang.
Zu Hause baue ich mit Agenten neue interessante Dinge, und im Unternehmen ringe ich täglich mit mehr als 20 Jahre altem Code. Dort ist Agenten-Memory unverzichtbar. Ohne geht die Arbeit nicht voran.
Deshalb habe ich begonnen, ein dateibasiertes Index-Memory selbst zu bauen und zu verwenden. Das war der Anfang von Monet. In letzter Zeit lasse ich die Agenten im Unternehmen absichtlich im Kreis laufen — damit sie Kontext sammeln. Die meisten Tickets lassen sich innerhalb von 20 % des Kontexts erledigen. Von der Zeitersparnis ganz zu schweigen, und auch der Stress ist geringer geworden.
Vor allem aber: Früher habe ich mühsam überlegt: „Wie haben wir diesen Bug noch mal behoben?“ Heute frage ich einfach Kiro (den Coding-Agenten im Unternehmen). Meistens weiß er es.
Sobald es Dutzende Agenten und Codebasen mit Millionen von Zeilen gibt, ist Kontext kein Byte-Problem mehr, sondern ein Infrastrukturproblem. Und ab diesem Punkt ist Memory kein nice-to-have mehr, sondern etwas, das überhaupt erst bestimmt, ob Arbeit möglich ist.
Wenn du es ausprobieren möchtest
- Homepage: monet.team-monet.com
- GitHub: github.com/team-monet/with-monet — Installations-Harness (Apache-2.0)
- 100 % lokal: Der Code verlässt dein Gerät nicht. On-Device-Embeddings, kein Netzwerk, keine Telemetrie. Das Memory ist nur eine SQLite-Datei in
~/.monet— du kannst sie selbst öffnen sowie sichern und exportieren. - Kostenlos nutzbar. Die Engine ist ein privates kompiliertes Binary, aber die Integrationsschnittstelle ist standardisiertes MCP. Direkte Integration mit MCP-fähigen Agenten wie Claude Code, Cursor und Codex.
Ich würde mich besonders freuen, wenn diese Leute es einmal ausprobieren:
- Entwickler, die ernsthaft jeden Tag mit AI-Agenten arbeiten
- Menschen, die die Ermüdung kennen: „Muss ich das von gestern jetzt schon wieder erklären …“
- Menschen, die denken: „Agenten-Memory? Warum braucht man das?“ (Wirklich — ich möchte auch Gegenargumente hören)
Alle in diesem Text verwendeten Beispiele und Szenarien beruhen auf realen Erfahrungen.
Noch keine Kommentare.