# Das Memory-Modell
SUMMARY: Wie Memories strukturiert sind — Kategorien, Keys, Tags, Prioritäten, Quellen, Verifikation.

Das Memory-Modell
Synapses Memory-Modell ist für LLM-Agenten gestaltet — strukturiert genug für
zuverlässiges Abrufen, flexibel genug für jede Domäne.
Anatomie eines Memories
[CODE BLOCK]
Felder
| Feld | Typ | Pflicht | Beschreibung |
|-------|------|---------|--------------|
|  | string | auto | Eindeutige ID (memxxx) |
|  | enum | ✅ | Eine von 8 Kategorien |
|  | string | ✅ | Stabiler Bezeichner (für Updates genutzt) |
|  | string | ✅ | Der Memory-Inhalt (beliebiger Text) |
|  | string[] | – | Für Suche und Filterung |
|  | enum | – | low, normal, high, critical (Standard: normal) |
|  | enum | auto | user, agent (wer hat es gespeichert) |
|  | bool | auto | Wurde das von einem Menschen verifiziert? |
|  | float | – | 0.0 bis 1.0 (Standard: 1.0 für user, 0.7 für agent) |
|  | timestamp | – | Wann dieser Memory vergessen werden soll |
|  | string | auto | Welcher Mind ihn besitzt |
|  | timestamp | auto | Erstmalig gespeichert |
|  | timestamp | auto | Zuletzt geändert |
Kategorien
Acht Kategorien decken die gängigen LLM-Agent-Anwendungsfälle ab:
| Kategorie | Zweck | Beispielinhalt |
|-----------|-------|----------------|
|  | Wer der Nutzer ist | „Nutzer ist Michael Schäfer, Software Engineer in Berlin" |
|  | Nutzerpräferenzen | „Bevorzugt prägnante technische Antworten" |
|  | Überprüfbare Fakten | „Büro in Berlin, Zeitzone Europe/Berlin" |
|  | Projektstatus | „Synapse v1.5.0 deployed, arbeite an v1.6.0-Docs" |
|  | Fähigkeiten des Nutzers | „Fortgeschrittenes Python, 10+ Jahre" |
|  | Frühere Fehler | „NPM-Version nicht gebumpt — CI fehlgeschlagen" |
|  | Session-Kontext | „Prüfe gerade PR #42" |
|  | Sonstige Notizen | „Nächstes Sprint Redis fürs Caching testen" |
Keys: Stabile Bezeichner
Das Feld  ist entscheidend — so aktualisierst du Memories, ohne Duplikate
zu erzeugen.
[CODE BLOCK]
Key-Regeln:
- Muss innerhalb (Kategorie, Mind) eindeutig sein
- Verwende 
- Präfix mit Kategorie für Klarheit: , 
- Stabil halten — Keys nach Anlage nicht ändern
Tags: Für die Suche
Tags ermöglichen schnelle Filterung und Suche:
[CODE BLOCK]
Tag-Best-Practices:
- 2-5 Tags pro Memory (nicht übertrieben)
- Kleinschreibung für Konsistenz
- Projektnamen, Themen, Technologien verwenden
- Tags sind Case-insensitive
Prioritätsstufen
| Priorität | Wann verwenden | Recall-Verhalten |
|-----------|----------------|-------------------|
|  | Identität, rechtlich, unumkehrbar | Immer oben im Recall |
|  | Aktive Projekte, zentrale Präferenzen | Prominent im Recall |
|  | Die meisten Memories (Standard) | Standard-Reihenfolge |
|  | Flüchtig, nett zu wissen | Kann zusammengefasst werden |
 sortiert nach Priorität (critical zuerst), dann nach Aktualität.
Quelle: User vs Agent
Memories werden mit  markiert:
-  — von einem Menschen gespeichert (via JWT oder Human-UI)
-  — von einem LLM-Agenten gespeichert (via Mind Key)
Das beeinflusst:
- Verifikation: -Memories sind auto-verifiziert, -Memories nicht
- Confidence:  defaults auf 1.0,  auf 0.7
- Recall:  markiert unverified Memories mit „(unverified)"
> [!NOTE]
> Behandle -Memories mit angemessenem Skepsis. Sie könnten gefolgert
> oder angenommen statt direkt vom Nutzer geäußert sein.
Verifikation
Das Flag  zeigt an, dass ein Mensch den Memory bestätigt hat:
- -Memories: auto-verifiziert ()
- -Memories: standardmäßig unverified ()
Memories verifizieren via:
[CODE BLOCK]
> [!NOTE]
> Verifikation erfordert JWT (Human-Auth), nicht Mind Key (Agent-Auth). So wird
> sichergestellt, dass nur Menschen Memories als verifiziert markieren können.
Confidence
Das Feld  (0.0 bis 1.0) zeigt, wie zuverlässig der Memory ist:
- 1.0 — direkt vom Nutzer geäußert
- 0.7 — vom Agenten gefolgert
- 0.5 — unsicher, needs Verifikation
- 0.0 — explizit angezweifelt
Beim Speichern Confidence setzen:
[CODE BLOCK]
Ablauf
Für zeitkritische Memories  setzen:
[CODE BLOCK]
Abgelaufene Memories werden von  nicht zurückgegeben (bleiben
aber in der DB). Verwende , um bald ablaufende
Memories zu sehen.
Memory-Lebenszyklus
[CODE BLOCK]
Recall-Verhalten
 liefert eine Klartext-Zusammenfassung, optimiert für
LLM-Kontext:
[CODE BLOCK]
- Sortiert nach Priorität (critical → low), dann nach Aktualität
- Unverified Memories markiert mit 
- Tags für Kontext enthalten
- Klartext (kein JSON-Parsing nötig)
Nächste Schritte
- Memory-API
- Memory-Best-Practices
- FTS5-Suche