Open-Source-Plugin für eine Agenten-Erzeugungsarchitektur, das Memory Noise und Decay bei Agenten löst

Die meisten Agenten-Setups gehen schlecht mit Speicher um. Entweder schreiben sie alles direkt in den Langzeitspeicher, der dann mit Noise und Widersprüchen vollläuft, oder sie vergessen alles, sobald eine Session endet, sodass man jedes Mal wieder ganz von vorn beginnen muss. Ich veröffentliche eine Open-Source-Agentenarchitektur, bei der der Speicher von Grund auf sorgfältig entworfen wurde (Apache-2.0). Dasselbe Setup läuft unverändert in Claude Code, Codex und Gemini CLI und ist daher nicht an ein bestimmtes Tool gebunden.
Die Kernidee ist, dass ein Agent kein Prompt, sondern ein Repo sein sollte. Das Ergebnis besteht aus echten Dateien (AGENTS.md, agents/, skills/, .agentlas/), die von allen drei Runtimes gelesen werden können, und man kann das bisher genutzte Modell unverändert weiterverwenden. Nach der Installation mit einer einzigen Zeile genügt es zu sagen, was man möchte, und es wird ein vollständig installierbares Agenten-Team dafür erzeugt.
Es werden 3 Modi erzeugt

Single Agent: ein Worker mit Skills, Speicherregeln, Runtime-Adaptern und Validierungsschritten. Ohne ihn zu einem Team auszubauen, lassen sich sogar Self-Evolution- und Research-Refresh-Loops anhängen.
Multi-Agenten-Team: Orchestrator/HQ, PM Soul, Memory Curator, Policy Gate, Worker, Eval Judge, QA/Evidence Gate sowie die Handoffs dazwischen. Das ist der Modus „Erstelle mir ein ganzes Unternehmen für diesen Workflow“.
Repackaging: Bereits vorhandene Agenten oder Workspaces (Claude/Codex/lokal) werden als portable package aufbereitet. Öffentliche Plugins und eine Ein-Zeilen-Installation kommen dazu, während lokale Pfade, Secrets und private Logs entfernt werden, sodass eine Veröffentlichung sicher bleibt.

So funktioniert der Speicher tatsächlich (es ist keine Rollenliste, sondern Dateien, die in das Ergebnis aufgenommen werden)

Ticket-basierter Speicher: Es wird nicht direkt in den Langzeitspeicher geschrieben. Wenn ein Worker einen Block ## Memory Events ausgibt, werden Tickets in memory-tickets.jsonl gesammelt (id, scope, trust label, evidence, status) und erst danach hochgestuft.
Memory Curator: Vor dem Commit werden Tickets geprüft, und die Entscheidungen werden im Ledger curator-decisions festgehalten. So läuft der Speicher nicht mit Noise oder Widersprüchen voll.
PM Soul: Verantwortlich für Kontinuität auf Projektebene. Hält Intentionen, Entscheidungen und offene Aufgaben fest und erinnert sich dadurch nicht nur daran, „welche Entscheidung getroffen wurde“, sondern auch daran, „warum diese Entscheidung getroffen wurde“.
Policy Gate: Teamweit geteilter Speicher muss vor der Hochstufung eine Freigabestufe durchlaufen. So wird verhindert, dass ein einzelner Agent den gesamten Kontext verunreinigt.
Validierte Self-Evolution: Ein Agent kann neue Skills erstellen und selbst Änderungen vorschlagen, aber neue Skills werden zunächst nur als Kandidaten ausgegeben und erst dann als First-Class-Recall behandelt, wenn sie das Trial-Evidence-Ledger, die Curator-Prüfung und die Policy-Freigabe durchlaufen haben. So verbessert er sich selbst, ohne im Verborgenen zu verfallen. Auch Self-Modification ist proposal-first und kein unautorisiertes Überschreiben.
Öffentlicher Sicherheitsscan: Vor der Veröffentlichung eines Pakets werden Maschinenpfade, Tokens, Service-Account-JSONs und gängige Secret-Formate blockiert.