Memory Layer: Wo Agenten Daten speichern und abrufen

Idee in 30 Sekunden

Memory Layer ist nicht nur ein Faktenspeicher, sondern eine kontrollierte Layer fuer Auswahl, Schreiben und Rueckgabe von Memory.

Der Agent sollte nicht die ganze Historie in jede Anfrage geben. Er liest aus Memory nur, was fuer den naechsten Schritt wirklich hilft. Memory Layer sollte nicht blind alles ansammeln. Ihre Aufgabe ist: wenig, aber treffend zurueckgeben.

Wann noetig: wenn der Agent nicht nur einen Schritt, sondern eine Serie von Schritten oder Sessions bearbeitet, in denen Konsistenz und Personalisierung wichtig sind.

LLM kann nur sehen, was im aktuellen Kontext ist. Memory Layer entscheidet, was aus der Vergangenheit zurueckkommt.

Problem

Ohne separate Memory-Layer arbeitet der Agent fast immer "von null".

Das erzeugt typische Probleme:

• Agent fragt erneut nach, was er schon weiss;
• Antworten werden zwischen Sessions inkonsistent;
• zu viel unnoetige Historie landet im Kontext;
• wichtige Fakten gehen im Rauschen verloren;
• in Memory sammeln sich Duplikate oder konfligierende Versionen desselben Fakts;
• Agent personalisiert Antworten auf Basis veralteter oder schwach bestaetigter Daten.

Ergebnis: Kosten, Latenz und Fehler in Antworten steigen.

Loesung

Memory Layer als separate Layer fuer Memory-Operationen hinzufuegen: was speichern, was in Kontext geben, was loeschen.

Sie trennt die Logik "wie erinnern" von "wie denken", dadurch laeuft der Agent stabiler.

Analogie: wie Notizen eines Managers ueber einen Kunden.

Ein Manager haelt nicht das gesamte Nachrichtenarchiv im Kopf. Er holt kurze relevante Notizen: was fuer dieses Gespraech wichtig ist.

Memory Layer macht dasselbe und liefert dem Agenten nur noetige Memory zum richtigen Zeitpunkt.

Wie Memory Layer Funktioniert

Memory Layer ist eine kontrollierte Layer zwischen Agent Runtime und memory store, die entscheidet, was gelesen, geschrieben und entfernt wird.

Dieser Zyklus wiederholt sich in jedem Schritt und hilft dem Agenten, zwischen Schritten und Sessions konsistent zu bleiben.

Im Code sieht es so aus

class MemoryLayer:
    def __init__(self, store, max_items_per_user=200):
        self.store = store
        self.max_items_per_user = max_items_per_user

    def retrieve(self, user_id: str, query: str, top_k: int = 4):
        # Nur relevante Memory zurueckgeben, nicht die ganze Historie.
        items = self.store.search(
            user_id=user_id,
            query=query,
            limit=top_k,
            min_score=0.7,
            exclude_expired=True,
        )
        return [item["text"] for item in items]

    def write(
        self,
        user_id: str,
        observation: str,
        tags: list[str],
        source: str = "user",
        sensitivity: str = "low",
        ttl_days: int = 30,
    ):
        if not self._worth_storing(
            observation=observation,
            tags=tags,
            source=source,
            sensitivity=sensitivity,
            ttl_days=ttl_days,
        ):
            return

        self.store.insert(
            user_id=user_id,
            text=observation,
            tags=tags,
            source=source,
            sensitivity=sensitivity,
            ttl_days=ttl_days,
        )
        self.store.enforce_limit(user_id=user_id, max_items=self.max_items_per_user)

    def _worth_storing(
        self,
        observation: str,
        tags: list[str],
        source: str,
        sensitivity: str,
        ttl_days: int,
    ) -> bool:
        text = observation.strip()
        if len(text) < 20:
            return False

        # Kurze Service-Phrasen nicht speichern.
        if text.lower() in {"ok", "danke", "erledigt", "fertig"}:
            return False

        # Sensible Daten nicht in Standard-Memory schreiben.
        if sensitivity == "high":
            return False

        # Nur definierten Quellen vertrauen.
        if source not in {"user", "tool", "policy"}:
            return False

        # Memory muss stabil und nuetzlich sein, nicht zufaelliges Rauschen.
        stable_tags = {"preference", "constraint", "profile", "goal"}
        if not any(tag in stable_tags for tag in tags):
            return False

        if ttl_days < 1 or ttl_days > 365:
            return False

        return True

So sieht es waehrend der Ausfuehrung aus

Anfrage: "Erstelle mir einen Ernaehrungsplan fuer die Woche"

Step 1
Agent Runtime: ruft Memory Layer.retrieve(...) auf
Memory Layer: gibt relevante Fakten zurueck -> ["Erdnussallergie", "vegetarische Ernaehrung"]
Agent Runtime: fuegt diese Fakten in Context ein
Agent Runtime: ruft LLM.decide(...) auf

Step 2
LLM: gibt zurueck -> final_answer (Plan ohne Erdnuesse und Fleisch)
Agent Runtime: uebergibt neue Beobachtung an Memory Layer.write(...)
Memory Layer: speichert Fakt -> "Nutzer will Budget bis $80/Woche"

Memory Layer hilft dem Agenten, Wichtiges nicht zu vergessen und Kontext nicht mit unnoetigen Details zu ueberladen.

Wann es passt - und wann nicht

Memory Layer ist nuetzlich, wenn der Agent Fakten zwischen Schritten oder Sessions erinnern muss. Fuer einmalige Anfragen ist sie oft unnoetig.

Passt

Passt nicht

In solchen Faellen reicht oft ein Modellaufruf:

response = llm(prompt)

Typische Probleme und Ausfaelle

Die meisten Memory-Layer-Probleme werden ueber klare Write-Regeln, gutes Ranking und Zugriffskontrolle geloest.

Wie es mit anderen Mustern zusammenspielt

Memory Layer steuert nicht den ganzen Agenten. Sie ist nur fuer qualitativ gute Memory-Arbeit in jedem Schritt zustaendig.

• Agent Runtime — Runtime entscheidet wann Memory abgefragt wird, und Memory Layer entscheidet was gelesen, geschrieben oder geloescht wird.
• Tool Execution Layer — Tool-Calls koennen Memory ueber die kontrollierte Execution-Layer lesen oder aktualisieren.
• Memory-Augmented Agent — dieses Muster basiert direkt auf Memory Layer.
• RAG Agent — RAG holt externes Wissen, waehrend Memory Layer interne Erfahrung des konkreten Agenten/Nutzers haelt.

Anders gesagt:

• Agent Runtime definiert wann der Agent auf Memory zugreift
• Memory Layer definiert was gespeichert und was zurueckgegeben wird

Wie sich das von Agent Runtime unterscheidet

Agent Runtime ist der "Dirigent" des gesamten Prozesses.

Memory Layer ist das "Gedaechtnis des Systems", das Antwortkonsistenz stuetzt.

Kurz gesagt

FAQ

Q: Reicht es nicht, die ganze Historie in den Prompt zu geben?
A: Fuer kurze Szenarien manchmal ja. In langen Dialogen ist das aber teuer, langsam und verrauscht. Memory Layer liefert kurze relevante Memory statt vollem Log.

Q: Worin unterscheidet sich short-term von long-term Memory?
A: Short-term wird fuer den aktuellen Run oder die Session gebraucht. Long-term speichert wichtige Fakten zwischen Sessions und wird spaeter wiederverwendet.

Q: Kann man jeden Agentenschritt in Memory schreiben?
A: Technisch ja, aber schlechte Praxis. Besser nur nuetzliche Fakten nach Write-Regeln speichern, sonst wird Memory schnell zu Rauschen.

Q: Ersetzt Memory Layer RAG oder Tool-Calls?
A: Nein. Memory Layer speichert interne Fakten und Erfahrung des Agenten/Nutzers. Fuer frische externe Daten sind meist retrieval oder Tool-Calls noetig.

Was als Naechstes

Memory ist nur dann nuetzlich, wenn sie kontrolliert bleibt. Als Naechstes sieh dir an, wo Memory mit Ausfuehrung und Policy verbunden wird:

• Agent Runtime - wie runtime Memory in jede Iteration einbindet.
• Multi-Tenant - wie Kontext und Daten zwischen Kunden nicht vermischt werden.
• Policy Boundaries - wie Zugriff auf sensible Memory begrenzt wird.
• Production Stack - wie Memory-Qualitaet, Audit und operativer Kontrollrahmen zusammenkommen.