Memory Layer : Comment les agents stockent et récupèrent la mémoire

Idee en 30 secondes

Memory Layer n est pas juste un stockage de faits, mais une couche controlee de selection, ecriture et restitution de memoire.

L agent ne doit pas envoyer tout l historique a chaque requete. Il lit dans la memoire seulement ce qui aide vraiment au pas suivant. Memory Layer ne doit pas accumuler tout sans filtre. Sa mission est de renvoyer peu, mais juste.

Quand c est utile : quand l agent travaille en serie d etapes ou de sessions, ou coherence et personnalisation comptent.

LLM ne peut voir que ce qui est dans le contexte courant. Memory Layer decide ce qu il faut ramener du passe.

Probleme

Sans couche memoire separee, l agent travaille presque toujours "de zero".

Cela cree des problemes typiques :

• l agent redemande ce qu il sait deja ;
• les reponses deviennent incoherentes entre sessions ;
• trop d historique inutile entre dans le contexte ;
• les faits importants se perdent dans le bruit ;
• des doublons ou versions conflictuelles du meme fait s accumulent en memoire ;
• l agent personnalise les reponses sur des donnees obsoletes ou faiblement confirmees.

Resultat : les couts, la latence et les erreurs de reponse augmentent.

Solution

Ajouter Memory Layer comme couche separee de gestion memoire : quoi stocker, quoi renvoyer au contexte, quoi supprimer.

Elle separe la logique "comment se souvenir" de la logique "comment penser", donc l agent est plus stable.

Analogie : comme des notes de manager sur un client.

Le manager ne garde pas tout l archive des echanges en tete. Il ressort des notes courtes pertinentes : ce qui compte pour cette conversation.

Memory Layer fait pareil et renvoie a l agent seulement la memoire utile au bon moment.

Comment Fonctionne Memory Layer

Memory Layer est une couche controlee entre Agent Runtime et memory store qui decide quoi lire, ecrire et nettoyer.

Ce cycle se repete a chaque etape et aide l agent a garder la coherence entre etapes et sessions.

Dans le Code, Cela Ressemble a Ceci

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):
        # Renvoyer seulement la memoire pertinente, pas tout l historique.
        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

        # Ne pas stocker les courtes phrases de service.
        if text.lower() in {"ok", "merci", "fait", "pret"}:
            return False

        # Ne pas ecrire de donnees sensibles dans la memoire standard.
        if sensitivity == "high":
            return False

        # Faire confiance seulement aux sources definies.
        if source not in {"user", "tool", "policy"}:
            return False

        # La memoire doit etre stable et utile, pas du bruit aleatoire.
        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

Comment Cela se Voit Pendant l Execution

Requete : "Prepare-moi un plan alimentaire pour la semaine"

Step 1
Agent Runtime : appelle Memory Layer.retrieve(...)
Memory Layer : renvoie faits pertinents -> ["allergie aux cacahuetes", "regime vegetarien"]
Agent Runtime : ajoute ces faits au Context
Agent Runtime : appelle LLM.decide(...)

Step 2
LLM : renvoie -> final_answer (plan sans cacahuetes ni viande)
Agent Runtime : transmet nouvelle observation a Memory Layer.write(...)
Memory Layer : stocke le fait -> "utilisateur veut budget jusqu a $80/semaine"

Memory Layer aide l agent a ne pas oublier l important et a ne pas surcharger le contexte de details inutiles.

Quand c est Adapte - et Quand Ce Ne l est Pas

Memory Layer est utile quand l agent doit memoriser des faits entre etapes ou sessions. Pour des requetes one-shot, elle est souvent inutile.

Adapte

Non adaptee

Dans ces cas, un appel modele suffit souvent :

response = llm(prompt)

Problemes et Echecs Typiques

La plupart des problemes Memory Layer se resolvent via regles d ecriture claires, bon ranking et controle d acces.

Comment Cela se Combine avec les Autres Patterns

Memory Layer ne pilote pas tout l agent. Elle repond seulement du travail memoire de qualite a chaque etape.

• Agent Runtime — Runtime decide quand interroger la memoire, et Memory Layer decide quoi lire, ecrire ou supprimer.
• Tool Execution Layer — les tool calls peuvent lire ou mettre a jour la memoire via la couche d execution controlee.
• Memory-Augmented Agent — ce pattern repose directement sur Memory Layer.
• RAG Agent — RAG recupere du savoir externe, et Memory Layer garde l experience interne d un agent/utilisateur specifique.

Autrement dit :

• Agent Runtime definit quand l agent consulte la memoire
• Memory Layer definit ce qui est stocke et ce qui est renvoye

En Quoi c est Different de Agent Runtime

Agent Runtime est le "chef d orchestre" de tout le processus.

Memory Layer est la "memoire du systeme" qui maintient la coherence des reponses.

En Bref

FAQ

Q : Ne suffit-il pas de passer tout l historique dans le prompt ?
A : Pour des scenarios courts, parfois oui. Mais sur de longs dialogues c est cher, lent et bruyant. Memory Layer donne une memoire courte et pertinente au lieu du log complet.

Q : Quelle difference entre memoire short-term et long-term ?
A : Short-term sert au run ou a la session courante. Long-term conserve des faits importants entre sessions et est reutilisee.

Q : Peut-on ecrire chaque etape agent en memoire ?
A : Techniquement oui, mais c est une mauvaise pratique. Mieux vaut stocker seulement les faits utiles via regles d ecriture, sinon la memoire devient vite du bruit.

Q : Memory Layer remplace-t-elle RAG ou les tool calls ?
A : Non. Memory Layer stocke les faits internes et l experience agent/utilisateur. Pour des donnees externes fraiches, retrieval ou tool calls sont en general necessaires.

Et Ensuite

La memoire est utile seulement si elle reste sous controle. Ensuite, voyez ou la memoire se connecte a l execution et aux policies:

• Agent Runtime - comment runtime injecte la memoire a chaque iteration.
• Multi-Tenant - comment eviter de melanger contexte et donnees entre clients.
• Policy Boundaries - comment limiter l acces a la memoire sensible.
• Production Stack - comment combiner qualite memoire, audit et controle operationnel.