Für die Claude-Foundations-Prüfung ist „Memory“ kein Feature, sondern eine Architekturentscheidung. Viele scheitern im Exam daran, Memory nur als „Kontext speichern“ zu sehen. Besser ist: Memory als kontrollierten Datenfluss zwischen Turns, Sessions und Systemgrenzen denken. Die Kernfrage lautet immer: Welche Information muss wann, wie lange und mit welchem Risiko verfügbar sein?
Short-Term Memory ist alles, was innerhalb einer laufenden Interaktion relevant bleibt: Nutzerziel, letzte Tool-Outputs, offene Subtasks, aktuelle Constraints. Das lebt typischerweise im Prompt-Kontext oder in einer kurzlebigen Session-State-Struktur. Vorteil: schnell, direkt, ohne zusätzliche Infrastruktur. Nachteil: teuer (Token), fragil bei langen Dialogen und begrenzt durch Context Window. Exam-relevant: Wenn ein Fall hohe Turn-Zahl + viele Zwischenergebnisse hat, musst du Short-Term aktiv komprimieren (Summaries, State-Objects), statt blind den gesamten Verlauf mitzuschleppen.
Long-Term Memory meint persistente, nutzer- oder aufgabenbezogene Informationen über Sessions hinweg: Präferenzen, bekannte Projektfakten, wiederverwendbare Policies. Das darf nie ein unkontrollierter „Datenfriedhof“ sein. Gute Systeme speichern nur stabilen, wertvollen Kontext und versehen Einträge mit Metadaten (Quelle, Zeitstempel, Confidence, Gültigkeit). Wichtig für die Prüfung: Long-Term ist kein Automatismus. Du brauchst Trigger-Regeln wie „nur speichern bei expliziter Präferenz“, „nicht speichern bei sensitiven Einmaldaten“, „verwerfen nach Ablaufdatum“. Sonst leidet sowohl Qualität als auch Datenschutz.
External Memory ist strukturiertes Wissen außerhalb des Modells: Datenbanken, Vektor-Store, Dokumentenspeicher, CRM, Ticket-Systeme. Der Agent „erinnert“ sich dann nicht selbst, sondern ruft gezielt Fakten ab (retrieval statt raten). Das ist in produktiven Setups oft der robusteste Ansatz, weil du Versionierung, Zugriffskontrolle, Audits und Aktualisierung getrennt vom Modell steuern kannst. In Exam-Szenarien ist external memory fast immer die richtige Antwort, wenn Fakten häufig ändern oder mehrere Agents dieselbe Wissensbasis nutzen müssen.
Entscheidend ist das Zusammenspiel: Short-Term für unmittelbare Aufgabensteuerung, Long-Term für personalisierte Kontinuität, External für autoritative Fakten. Ein guter Architekturentwurf definiert klare Übergänge:
1) Was kommt aus dem aktuellen Turn in den Session-State?
2) Was wird nach einem Turn bewusst persistiert?
3) Welche Fragen werden immer via Retrieval validiert?
Dazu kommt Governance: Privacy-by-Design, Least-Privilege-Zugriffe, Löschkonzepte, und observability (wer hat wann welche Memory-Quelle verwendet?). In der Prüfung werden oft Trade-offs abgefragt: Wenn Halluzinationen sinken sollen, erhöhe nicht einfach Kontextgröße, sondern verbessere Retrieval-Qualität und Grounding-Regeln. Wenn Kosten sinken sollen, verschiebe statisches Wissen aus Prompt-Bloat in External Memory und lade nur Top-k relevante Snippets.
Ein praktisches Prüfungs-Heuristik-Set:
Wer diese Trennung sauber begründen kann, punktet bei Architektur-, Security- und Reliability-Fragen gleichzeitig.
Du baust einen Support-Agenten für ein SaaS-Produkt. Produktdokumentation ändert sich wöchentlich, Nutzerpräferenzen sollen zwischen Sessions erhalten bleiben, und laufende Troubleshooting-Schritte müssen innerhalb eines Chats konsistent sein. Wie verteilst du die Informationen auf Short-Term, Long-Term und External Memory?
Troubleshooting-Status und offene Schritte gehören in Short-Term Session-State, damit der aktuelle Dialog konsistent bleibt. Nutzerpräferenzen (z. B. bevorzugte Sprache oder Antwortformat) speicherst du als Long-Term mit klaren Update-Regeln. Die häufig aktualisierte Produktdokumentation liegt in External Memory und wird pro Anfrage via Retrieval eingebunden, statt statisch im Prompt gehalten.