# Memory-Best-Practices
SUMMARY: Wie du Memories für effektives Recall strukturierst — Kategorien, Keys, Tags, Prioritäten.

Memory-Best-Practices
Wie du Memories strukturierst, bestimmt ihren Nutzen. Dieser Guide behandelt
Patterns zum Kategorisieren, Taggen und Prioritisieren, damit das LLM zur
richtigen Zeit die richtigen Informationen abrufen kann.
Kategorien: Wähle die spezifischste
| Kategorie | Verwende für | Beispiel |
|-----------|--------------|----------|
|  | Nutzername, Rolle, Kontaktinfo |  |
|  | Vorlieben, Abneigungen, Arbeitsstil |  |
|  | Überprüfbare Fakten |  |
|  | Projektstatus, Entscheidungen |  |
|  | Fähigkeiten des Nutzers |  |
|  | Frühere Fehler, die es zu vermeiden gilt |  |
|  | Session-relevanter Kontext |  |
|  | Sonstige Notizen |  |
> [!TIP]
> Im Zweifel:  für überprüfbare Infos und  für alles andere.
> Nicht überkategorisieren — besser ein klarer  als ein verwirrender
> .
Keys: Aussagekräftige Bezeichner
Das Feld  ist der Bezeichner des Memories. Verwende aussagekräftige,
stabile Keys:
Gute Keys:
- 
- 
- 
- 
Schlechte Keys:
-  (nicht aussagekräftig)
-  (nicht beschreibend)
-  (Datum hilft beim Recall nicht)
Key-Namenskonventionen
-  (Kleinschreibung mit Unterstrichen)
- Präfix mit Kategorie: , , 
- Beschreibende Substantive, keine Verben
- Unter 50 Zeichen halten
Tags: Für Suche und Filterung
Tags ermöglichen schnelle Filterung und Suche. 2-5 Tags pro Memory hinzufügen:
[CODE BLOCK]
Tag-Patterns
- Projektnamen: , , 
- Themen: , , , 
- Status: , , 
- Prioritäts-Indikatoren: , 
> [!NOTE]
> Tags sind Case-insensitive. Verwende für Konsistenz Kleinschreibung.
Prioritäten: Sei realistisch
| Priorität | Verwende für | % der Memories |
|-----------|--------------|----------------|
|  | Nutzeridentität, rechtliche Infos, unumkehrbare Entscheidungen | 5% |
|  | Aktive Projekte, wichtige Präferenzen | 20% |
|  | Die meisten Fakten, Notizen, Kontext | 65% |
|  | Flüchtig, nett zu wissen | 10% |
> [!WARNING]
> Markiere nicht alles als . Wenn alles critical ist, ist nichts
> critical. Reserviere  für Dinge, die echten Schaden anrichten, wenn
> sie vergessen werden.
Wann speichern, wann nicht?
Immer speichern
- Nutzeridentität (Name, E-Mail, Rolle)
- Langfristige Präferenzen
- Projektentscheidungen und Begründungen
- Frühere Fehler und gelernte Lektionen
- Zugesagte Zusagen an den Nutzer
Nicht speichern
- Flüchtigen Status (verwende stattdessen Variablen)
- Wörtlichen Konversationsverlauf (Chat-System übernimmt das)
- Sensible Daten (Passwörter, API-Keys)
- Leicht ableitbare Fakten (aktuelles Datum, Dateiinhalte)
- Flüchtigen Kontext (verwende -Kategorie mit niedriger Priorität)
Memories aktualisieren
POST  mit derselben  +  aktualisiert den bestehenden
Memory:
[CODE BLOCK]
> [!TIP]
> Verwende stabile Keys, damit du aktualisieren kannst, ohne Duplikate zu
> erzeugen. Das LLM sollte denselben Key erneut posten, wenn sich Infos ändern,
> nicht neue Memories anlegen.
Memory-Lebenszyklus
[CODE BLOCK]
- Create: POST /memory mit vollem Kontext
- Active: Häufig abrufen, bei Bedarf aktualisieren
- Stale: Noch relevant, aber nicht aktiv genutzt (niedrigere Priorität?)
- Archive: Priorität auf  setzen, für historische Referenz behalten
- Delete: DELETE /memory/:id, wenn nicht mehr relevant
Periodische Bereinigung
[CODE BLOCK]
Pattern: Memory-Vererbung
Für hierarchischen Kontext (Projekt → Subprojekt → Task):
[CODE BLOCK]
Das LLM kann dann  suchen, um alle verwandten Memories zu
finden.
Pattern: Entscheidungs-Log
Entscheidungen mit Begründung speichern, damit das LLM sie nicht neu verhandelt:
[CODE BLOCK]
Pattern: Fehler-Vermeidung
Fehler mit spezifischen Vermeidungs-Anweisungen speichern:
[CODE BLOCK]
Anti-Patterns, die du vermeiden solltest
> [!WARNING]
> - Konversations-Logs speichern — Chat-System übernimmt das
> - Ganze Dateien speichern — Script-Speicher oder externen Speicher verwenden
> - Flüchtigen Status speichern — Variablen verwenden
> - Secrets speichern — Environment-Variablen verwenden
> - Memories duplizieren — stabile Keys verwenden
> - Übertrieben taggen — 2-5 Tags pro Memory sind ideal
> - Alles ist critical — sei realistisch mit Prioritäten
Nächste Schritte
- Memory-API
- Persistenter LLM-Agent
- Memory-Tagging-Strategie