Agent mit Memory bauen

Kostenlose Spec für einen Agent mit Memory – vier explizite Memory-Ebenen (working, episodic, semantic, procedural), ein Write-Tool, bei dem der Agent selbst entscheidet, wann er es aufruft, Retrieval, das Aktualität und Relevanz kombiniert, Konsolidierung beim Schreiben und eine Primitive zum Vergessen. Framework-unabhängig: Das Substrat wählst du in STACK.md (Postgres+pgvector, SQLite+sqlite-vss, Qdrant oder spezialisierte Stores wie Mem0, Letta oder Zep). Mit typisierten Contracts, Eval über mehrere Sessions und Datenschutz-Compliance.

In meinem Repo bauen →

AWM-1

Leg das Fundament für deinen Agent mit Memory

AWM-2

Definiere die vier Memory-Ebenen und die typisierten Datensätze, die sie tragen

AWM-3

Baue das Memory-Write-Tool, das der Agent aufruft, wenn er etwas Behaltenswertes lernt

AWM-4

Baue Memory-Retrieval, das nach Relevanz UND Aktualität rankt, nicht nur nach Ähnlichkeit

AWM-5

Baue das Context Window des Agents aus Working Memory plus abgerufenem Langzeit-Memory

AWM-6

Konsolidiere altes episodisches Memory in einem Durchlauf beim Schreiben zu dauerhaftem semantischem Memory

AWM-7

Löse Konflikte auf, wenn neueres Memory älterem widerspricht

AWM-8

Baue einen Eval-Harness, der Recall über Sessions hinweg und den Umgang mit Widersprüchen bewertet

AWM-9

Ergänze Datenschutz-Primitives: eine Person vergessen, einen Fakt schwärzen, Aufbewahrungsfristen durchsetzen

AWM-10

Bring den Agent mit Memory in Produktion: Traces, Speichergrenzen, Einblick in das, was abgerufen wurde

Nothing in flight

Nothing shipped yet

5 Minuten Planung, ~22 Stunden gespart. Registrier dich, und diese Spec mit 10 Tasks landet auf deinem Tekk-Board – dein Coding-Agent baut sie über MCP.

Jetzt bauen →

So nutzt du diese Spec

Klick auf eine Zeile oben, um die ganze Task zu öffnen – Titel, Beschreibung, Subtasks, KI-Anweisungen, alles drin. Dasselbe Layout, das das Produkt intern nutzt.
Klick auf Copy as Prompt in der rechten Seitenleiste einer Task. Du bekommst den in XML verpackten Prompt, den Tekk intern verwendet – füg ihn in Cursor, Claude Code, Codex, ChatGPT oder sonst wo ein, und der Agent hat den vollen Kontext der Task.
Open in schickt denselben Prompt mit einem Klick direkt nach v0, Lovable, Bolt, Magic Patterns, Replit oder Cursor.

Was du baust

Goal 1: Einen funktionierenden Agent mit Memory ausliefern: vier explizite Memory-Ebenen (working, episodic, semantic, procedural), ein Write-Tool, das das Modell bewusst aufruft, Retrieval, das nach Aktualität UND Relevanz rankt, Konsolidierung beim Schreiben, die alte Episoden zu dauerhaften Fakten verdichtet, typisierte Konfliktauflösung, Eval über mehrere Sessions, Recht auf Vergessenwerden und Traces in Produktion.
Ein Pattern für Agents mit Memory als framework-unabhängiges Starter-Kanban. Du triffst fünf Tooling-Entscheidungen in STACK.md (language / memory_substrate / embedder / model / consolidation_cadence); jede spätere Karte liest deine Wahl und führt die passende Variante aus. Abnahmekriterium: Der Eval-Harness besteht auf 12 Fixtures mit Recall über Sessions hinweg >= 90 %, korrektem Umgang mit Widersprüchen in 6/6 Fällen, Retrieval-p50 < 50 ms in-memory oder < 200 ms mit Postgres, Top-K-Precision >= 85 %, forget(user) entfernt jeden direkten und abgeleiteten Datensatz mit einem Aufruf, und die Regressionsschwelle von +/-5 % hält nach der Production-Härtung.

Architektur

flowchart TB
  User[User Turn] --> Assemble[assemble_context]
  Procedural[(Procedural<br/>skills + system)] --> Assemble
  Working[(Working<br/>last N turns)] --> Assemble
  Semantic[(Semantic<br/>durable facts)] -->|retrieve top-K| Assemble
  Episodic[(Episodic<br/>past events)] -->|retrieve top-K| Assemble
  Assemble --> Model[Model]
  Model -->|remember tool call| Resolver[Conflict Resolver]
  Resolver -->|append| Episodic
  Resolver -->|overwrite or preserve| Semantic
  Episodic -.write-time consolidation.-> Consolidator[Consolidation Job]
  Consolidator -.derived facts.-> Semantic
  Forget[forget user] -.cascade via derived_from.-> Episodic
  Forget -.cascade.-> Semantic

Die drei tragenden Entscheidungen: explizite Memory-Typen statt eines einzigen Blobs (working / episodic / semantic / procedural haben jeweils eigenen Namespace, eigene Schreibregeln und eigenes Retrieval-Profil – das ist der Unterschied zwischen einer Memory-Architektur und „wir speichern den Chatverlauf“), Konsolidierung beim Schreiben statt beim Lesen (die teure Verdichtung von episodisch zu semantisch läuft auf dem Schreibpfad oder in einem Hintergrundjob, nie innerhalb von retrieve, damit der heiße Lesepfad schnell bleibt) und Retrieval nach Aktualität UND Relevanz (Score-Mischung = α · semantische Ähnlichkeit + β · Aktualität + γ · BM25, mit einem harten is_valid-Filter, der abgelöste Datensätze verwirft – reine Cosine Similarity liefert in Produktion veraltete, aber ähnliche Treffer).

Wann Agent-Memory sinnvoll ist (und wann nicht)

Agent-Memory gibt es nicht umsonst. Die eigenen Benchmarks von Letta zeigen, dass ein schlichtes Dateisystem bei Memory-Aufgaben 74 % erreicht und damit spezialisierte Memory-Libraries schlägt. Greif zu einer bewusst gebauten Memory-Architektur, wenn die Aufteilung die Kosten wert ist – sonst lieferst du einen zustandslosen Agent aus und ergänzt Memory erst, wenn dir Evals sagen, dass es sich lohnt.

✓ Wann sich Agent-Memory lohnt

Die Leute erwarten Kontinuität über Sessions hinweg. Ein Coaching-Agent, ein persönlicher Assistent, ein lang laufender Coding-Agent – das ganze Produktversprechen bricht, wenn sich Turn 1 von Session 5 nicht an Turn 12 von Session 1 erinnert. Memory IST das Feature.
Personalisierung ist ein Produkt-Feature, kein Nice-to-have. Vorlieben einzelner Personen („bevorzugt metrische Einheiten“, „hat letzte Woche PR #842 reviewt“) machen den Agent von generisch zu nützlich. Ohne Memory-Architektur stopfst du in jedem Turn die komplette Historie neu hinein – teuer und fragil.
Token-Kosten wiegen schwerer als die Kosten des Substrats. Die komplette Historie in jedem Turn neu abzuspielen skaliert mit O(turns²). Eine Memory-Schicht mit Retrieval in den Kontext skaliert mit O(retrieved_k). Bei Personen mit vielen Turns verschwinden die Kosten des Substrats neben den eingesparten Tokens.
Compliance verlangt explizite Semantik fürs Vergessen. DSGVO-Recht auf Vergessenwerden, HIPAA-Aufbewahrungsfristen, SOC-2-Datenklassifizierung – all das braucht forget(user) als vollwertige Operation mit kaskadierendem Löschen abgeleiteter Datensätze. Chatverlauf in den Kontext zu stopfen, besteht dieses Audit nicht.
Du hast eine zustandslose Version ausgeliefert und eine Eval-Baseline. Fehlerbilder von Memory (veraltete Fakten, Widersprüche, verfehltes Retrieval) sind still – ohne Eval-Harness kannst du nicht sagen, ob deine Memory-Schicht geholfen oder nur Latenz hinzugefügt hat. Zuerst der zustandslose Agent, dann der Eval-Harness, dann Memory.

⚠ Wann du ohne Memory auslieferst

Die Aufgaben sind von vornherein auf eine Session ausgelegt. Ein Code-Review-Agent, der einmal pro PR läuft, braucht kein Memory über frühere PRs, außer du hast ihn ausdrücklich dafür entworfen. Schraub kein Memory dran, weil es „nützlich sein könnte“ – ergänze einen escalate-Pfad, wenn der seltene Fall auftritt.
Das Context Window fasst die ganze Interaktion. Konversationen unter 50 Turns passen bei einem Modell mit 200.000 Tokens unverändert hinein. Die Kurve, mit der die Retrieval-Genauigkeit bei langem Kontext abnimmt, ist real, aber bei 50 Turns bist du weit davon entfernt. Bau keine zusätzliche Architekturschicht, um Tokens zu sparen, die du ohnehin nicht ausgegeben hättest.
Du hast noch keinen Eval-Harness. Memory-Bugs sind stille Killer – ein veralteter Fakt wird abgerufen, das Modell vertraut ihm, die Person verliert das Vertrauen in den Agent, und du hast keine Möglichkeit, den Bug in Produktion zu erkennen. Eval-Harness vor Memory-Architektur, jedes Mal.
Die Rechnung aus Personen × Turns × Tokens rechtfertigt das Substrat nicht. Postgres+pgvector und Qdrant kosten im Betrieb Geld. Wenn dein Produkt 100 wöchentlich aktive Personen mit je 5 Turns hat, übersteigen die Kosten des Memory-Substrats die eingesparten Tokens. Rechne nach, bevor du dich festlegst.
Du hast noch keine zustandslose Version ausgeliefert. Zustandslos → mit Memory ist die richtige Migrationsreihenfolge, nie umgekehrt. Memory bringt tragende Komplexität mit (Konsolidierung, Konfliktauflösung, Vergessen) – wer es einbaut, bevor die echten Gesprächsmuster klar sind, bekommt eine Architektur, die gegen die eigene Last arbeitet.

Was die Community sagt

"The goal of this work is to investigate the extent to which an LLM can manage memory and different memory hierarchies, applying lessons from operating systems to extend effective context lengths."

Charles Packer (pacjam) · Federführend bei MemGPT, HN-Diskussion zum Original-Paper · 2023-10-15 · news.ycombinator.com

"Mem0 = memory storage + retrieval. Doesn't learn patterns. We built an internal solution capturing structured events (agent output, user corrections, accepted changes) to extract evolving preference profiles, enabling agents to improve without explicit instruction."

Ask-HN-Beitrag (YC W23) · Ask HN: Mem0 stores memories, but doesn't learn user patterns · 2026-02-18 · news.ycombinator.com

"Relevant data is moved into the context the llm needs to answer chat questions. When it runs out of memory it moves a condensed, searchable version of the content to another data store."

u/tayo42 · HN – MemGPT: Towards LLMs as Operating Systems · 2023-10-15 · news.ycombinator.com

Woran du erkennst, dass es funktioniert

Setz die Spec um und miss sie dann an diesen Kriterien (die Task mit dem Eval-Harness bewertet sie):

Recall über Sessions hinweg >= 90 % auf 4 Fixtures mit Vorlieben (Session 1 legt eine Vorliebe fest, Session N fragt danach; die Ausgabe des Modells enthält die Vorliebe)
Umgang mit Widersprüchen korrekt in 6/6 Fixtures – Fakten werden überschrieben (neu gewinnt, alt wird als superseded_by markiert), Meinungen bleiben erhalten (beide bleiben mit Zeitstempeln aktiv), Events werden immer angehängt
Retrieval-p50-Latenz < 50 ms in-memory oder < 200 ms mit Postgres bei 1.000 Datensätzen pro Namespace einer Person
Top-K-Precision des Retrievals >= 85 % – der relevante Datensatz steht in den Top 3 der retrieve-Ergebnisse über die 3 Precision-Fixtures
forget(user_id, scope=ALL) entfernt mit einem Aufruf jeden direkten und abgeleiteten Datensatz (belegt durch ein retrieve nach dem Aufruf, das 0 Ergebnisse liefert, einschließlich konsolidierter semantischer Fakten aus den Episoden der Person)
Der Namespace pro Person bleibt unter MAX_NAMESPACE_BYTES (Standard 50 MB), nachdem die Durchsetzung der Speichergrenze gelaufen ist – die Eviction-Reihenfolge ist importance ASC, last_accessed_at ASC
Der Circuit Breaker für das Substrat öffnet nach 3 aufeinanderfolgenden Retrieval-Fehlern in einer run_id; assemble_context fällt auf prozedurales + Working Memory zurück und gibt ein memory_degraded-Trace-Event aus

Quellen

Jede Aussage, jedes Pattern und jede Abnahmeschwelle auf dieser Seite geht auf eine dieser Quellen zurück. Lies sie, bevor du von der Spec abweichst.

Bau das noch heute Abend in deine Codebase

Wähl deinen Stack anhand der fünf Entscheidungen in STACK.md und registrier dich: Diese Spec mit 10 Tasks landet auf deinem Board, dein Coding-Agent (Claude Code, Codex, Cursor) baut sie über den Tekk-MCP-Server, und der gemergte PR schließt sie. Nach dem Launch behält Tekks AI-Engineering-Loop den Agent weiter im Blick – Harness, Prompts, Tools, Kontext, Memory, Retrieval, Evals und Kosten – und bringt dir ein Proposal, sobald sich etwas ändern sollte. Lieber selbst machen? Öffne oben eine beliebige Task und klick auf Copy as Prompt – und füg den Prompt in Cursor, Claude Code oder Codex ein.

In meinem Repo bauen →

Agent mit Memory bauen

So nutzt du diese Spec

Was du baust

Architektur

Wann Agent-Memory sinnvoll ist (und wann nicht)

✓ Wann sich Agent-Memory lohnt

⚠ Wann du ohne Memory auslieferst

Was die Community sagt

Woran du erkennst, dass es funktioniert

Quellen

Bau das noch heute Abend in deine Codebase

Verwandte Specs

Deep Research Agent

AI Coding Agent

AI Sales Agent

RAG Agent