Agenten-Speicher

Die KI liest Code und Gespräche gut, aber sobald eine Sitzung endet, vergisst sie, „was in dieser Workbench möglich ist”. Deshalb urteilt sie in der nächsten Sitzung oft erneut falsch und behauptet bei einer bereits erfolgreich erledigten Aufgabe (Deployment, Build, DB-Zugriff), sie könne es „mangels Zugangsdaten nicht”.

Der Agenten-Speicher lässt die KI verifizierte Fakten in einer Schublade mit exakter Übereinstimmung ablegen und in der nächsten Sitzung automatisch wieder hervorholen. Er konkurriert nicht mit RAG (semantischer Näherungssuche), sondern teilt sich die Rollen — die Faktenbeurteilung übernimmt die Schublade, die Näherungssuche die Bibliothek.

Warum das nötig ist — ausgehend von einem realen Vorfall

Das Blyck-Deployment war von diesem PC aus direkt möglich (aws CLI eingerichtet, Verlauf direkter Deployments vorhanden) und die Prozedur war dokumentiert. Dennoch urteilte der Agent in jeder Sitzung wiederholt falsch und behauptete, „mangels Zugangsdaten kein Deployment möglich”. Die Ursache: Er sah nur die Code-Kommentare und schloss daraus „separater Schritt = ich kann es nicht”.

Die Diagnose ergab: Das schwache Glied war nicht die Erinnerung, sondern die Speicherung.

Schritt	Status	Begründung
Erinnerung (recall)	normal	Wäre es nur gespeichert worden, wäre es sicher gelesen worden
Speicherung (capture)	fehlgeschlagen	„Deployment von diesem PC möglich” wurde nie dauerhaft gespeichert

Es war also nicht so, dass die Erinnerung versagte, sondern der zu erinnernde Eintrag wurde gar nicht erst erstellt. Die Handlung (einmal s3 cp) wirkt flüchtig, aber die Fähigkeit, die sie beweist („Deployment möglich”), ist ein dauerhafter, wiederverwendbarer Fakt. Das Versäumnis dieser Unterscheidung war der blinde Fleck.

Grundprinzipien

Speicher wird nicht in die RAG-Suppe geworfen. Fakten-/Fähigkeitserinnerungen werden nicht über semantische Näherungssuche, sondern über exakte Übereinstimmung hervorgeholt.
Speicherung hängt nicht von Selbstwahrnehmung ab. Erfolgreiche Handlungen werden automatisch zu Fähigkeitskandidaten befördert (jedoch mit Freigabe-Gate).
Erinnerung wird automatisch injiziert. Relevante Erinnerungen gelangen ohne Aufruf in den Kontext.
Vor der Behauptung der Unmöglichkeit verifizieren. Bevor die KI „kann ich nicht” sagt, prüft sie per Speicherabfrage und billiger Probe.

Analogie — Bibliothek und Schreibtischschublade

📚 Bibliothekssuche (RAG): Code, Gespräche und Logs werden alle angehäuft und „etwas Ähnliches gesucht”. Die Menge ist groß und weil es Näherung ist, mischt sich Müll hinein. → Für „Wo war noch mal früher ähnlicher Code?”.
🗂️ Notizschublade auf dem Schreibtisch (Speicher): Nur einige wenige verifizierte Kernfakten, sauber abgelegt. Exakt und immer sichtbar. → Für „Deployment von diesem PC möglich”, „PROD DB nicht anfassen”.

RAG und Speicher konkurrieren nicht, sondern teilen sich die Arbeit. Faktenbeurteilung über die Schublade (erste Priorität), Näherungssuche über die Bibliothek (unterstützend).

Typisierte Exakt-Schublade

Erinnerungen werden als typisierte Datensätze in einer dedizierten Tabelle von workspace.sqlite gespeichert.

Feld	Beschreibung
`type`	`capability` · `decision` · `rule` · `procedure` · `fact`
`scope`	`workspace` (Standard) · `global`
`key`	Kennung für exakte Übereinstimmung (z. B. `deploy:blyck`)
`body`	Für Menschen lesbarer Faktentext
`confidence`	0–1 (verifiziert = 1.0)
`proof`	Beleg (z. B. „aws sts bestanden; s3 cp erfolgreich”)
`status`	`active` · `stale` · `retired`

Speicherung (capture) — das schwache Glied dreifach absichern

Methode	Auslöser	Müllabwehr
explizit	MCP-Tool `memory_write(key, body, type, scope)`	nur bewusster Aufruf
automatische Beförderung	Erfolgsereignisse (Deployment, Build, Authentifizierung, DB-Zugriff) werden im Aktivitätslog erkannt → Kandidat erstellt	Freigabe-Gate
Reflexions-Pass	Bei Chat-Ende/Meilenstein Sitzungszusammenfassung → Kandidatenextraktion „gelernter dauerhafter Fakt?”	Freigabe-Gate

Alle drei Pfade gelangen erst nach Freigabe in die Schublade, sodass es kein RAG-artiges Rauschen durch automatisches Ansaugen gibt.

Beispiele für Erfolgsereignisse, die der Klassifikator der automatischen Beförderung zu Fähigkeitskandidaten erhebt:

Erfolgreiche externe Authentifizierung/Deployment (aws … erfolgreich, gh auth, deploy/publish) → capability
Erfolgreicher Build/Packaging (npm run dist, bestandene Tests) → capability/procedure
Erfolgreicher DB-/SSH-Zugriff (Verifizierung der Zugangsdaten) → capability
Vom Nutzer imperativ erteilte Regel („PROD nicht anfassen”) → rule
Zu Triviales oder Einmaliges (etwa simples Dateilesen) wird ausgeschlossen — zur Vermeidung von Freigabe-Müdigkeit

Erinnerung (recall) — automatische Injektion

Beim Zusammenstellen des Kontexts in jedem Turn schaltet sich eine Speicher-Abrufstufe dazwischen.

Exakte key-Übereinstimmung + leichte semantische Übereinstimmung anhand der aktuellen Abfrage, der aktiven Panels und des Projekts.
Die obersten k active-Erinnerungen werden automatisch in den System-Prompt injiziert (kein separater Aufruf nötig).
Gewichtung nach recency und importance + decay → lange ungenutzte Erinnerungen werden stale → retired.

KI-Tools (MCP)

Tool	Berechtigung	Rolle
`memory_write(key, body, type, scope)`	Bestätigung	Fakt explizit in der Schublade speichern (gleichen key überschreiben)
`memory_read(key?/query?)`	Lesen (auto)	Erinnerung per exakter key-Übereinstimmung oder leichter semantischer Übereinstimmung abrufen

Da die meisten Erinnerungen über automatische Injektion abgewickelt werden, muss memory_read nicht einzeln aufgerufen werden. Es dient der Nachabfrage für Einträge, die die automatische Injektion verpasst hat.

decay und Aufräumen

Damit die Schublade nicht aufbläht, werden lange ungenutzte Erinnerungen auf Basis von last_seen aufgeräumt.

capability · rule · procedure sind vom automatischen Verfall ausgenommen — Zweck ist die oben genannte Verhinderung eines erneuten Vorfalls. Eine einmal verifizierte Fähigkeit verschwindet nicht, selbst wenn sie ungenutzt bleibt.
Nur decision · fact werden nach 90 Tagen → stale, nach 180 Tagen → retired.
Bei expliziter Abfrage Wiederbelebung stale → active.

Gesamtablauf — der heutige Fall

[Speicherung] erstes erfolgreiches Deployment → Aktivitätslog "s3 cp blyck-releases erfolgreich"
   → Beförderungs-Klassifikator erkennt → Kandidat {capability, key:"deploy:blyck",
      body:"Dieser PC kann direkt deployen: npm run dist → s3 cp → cloudfront invalidate",
      proof:"aws sts bestanden; s3 cp erfolgreich"} → [Freigabe] → in der Schublade fixiert

[Erinnerung] nächste Sitzung "deploy es" → Kontextzusammenstellung injiziert "deploy:blyck" automatisch
   → Schluss "keine Zugangsdaten" selbst unmöglich → 0 Rückfälle

Verhältnis zum Datei-Speicher von Claude

Diese Funktion übernimmt die Exaktheit und automatische Erinnerung des Datei-Speichers von Claude Code (MEMORY.md + *.md, in jeder Sitzung automatisch geladen) unverändert, gleicht aber dessen Schwäche aus.

Aspekt	Datei-Speicher von Claude	Blyck-Sediment-Schublade
Speicherort	Markdown-Datei	workspace.sqlite-Tabelle
Speicherauslöser	Entscheidung des Agenten (manuell)	manuell + automatische Beförderung von Handlungen + Reflexions-Pass
Automatische Speicherung	✗	✓ (Beförderung von Erfolgsereignissen)
Müll	gering	nahezu 0 (UNIQUE key + Freigabe)
Duplikatschutz	Mensch pflegt Index	`UNIQUE(scope, key)` automatisch
decay/Aufräumen	manuell	stale/retire auf Basis von `last_seen`
Domänenbewusstsein	universell	spezialisiert auf Blyck-Aktivitäten (Deployment, DB, SSH)

Der entscheidende Unterschied ist die automatische Speicherung. Der obige Vorfall trat bei eingeschaltetem Claude-Datei-Speicher auf — die Erinnerung funktionierte einwandfrei, das schwache Glied war, dass „die Speicherung von einer Entscheidung abhängt”. Blyck verfügt mit dem Aktivitätslog als Handlungsaufzeichnung über die Möglichkeit, Erfolgsereignisse automatisch zu Fähigkeitskandidaten zu befördern — und genau das ist mit Datei-Speicher allein strukturell unmöglich.

Sicherheit

Chat-übergreifende Erinnerungen haben standardmäßig scope=workspace + Filter für sensible Informationen und kollidieren so nicht mit dem Prinzip der Nicht-Übertragung globaler Sitzungen und des Nur-Lesens.
Secrets werden nicht im Speicher-Body abgelegt (OS-Verschlüsselungsspeicher + automatische Maskierung laufen über einen separaten Pfad).

FAQ

F. Wozu braucht es zusätzlich Speicher, wo es doch RAG gibt? → RAG ist semantische Näherung, daher mischt sich bei der Faktenbeurteilung Müll hinein. Ein verifizierter Fakt wie „Deployment von diesem PC möglich” muss zur Sicherheit 1:1 aus der Schublade mit exakter Übereinstimmung geholt werden. Beide teilen sich die Arbeit.

F. Muss ich jedes Mal selbst „merke dir das” sagen? → Nein. Explizites Speichern per memory_write ist möglich, aber Erfolgsereignisse tauchen als Kandidaten der automatischen Beförderung auf, die du nur freizugeben brauchst. Bei Chat-Ende extrahiert der Reflexions-Pass auch Regeln automatisch.

F. Verfolgt mich eine falsch gespeicherte Erinnerung nicht dauerhaft? → Derselbe key wird überschrieben, und decision/fact werden per decay aufgeräumt. Eine falsche Fähigkeitserinnerung lässt sich per memory_write aktualisieren oder in den Ruhestand versetzen.

F. Verschwindet eine verifizierte Fähigkeit nicht wieder, wenn sie ungenutzt bleibt, und es kommt erneut zum Vorfall? → Genau deshalb sind capability · rule · procedure vom automatischen Verfall ausgenommen. Eine einmal verifizierte Fähigkeit bleibt auch ungenutzt in der Schublade.