Mon agent IA a tourné 3 semaines — il a toujours l’amnésie

La semaine dernière, j’ai confié un client existant à un agent Telegram. Journals complets, contexte énorme, Memory ChatGPT activée — je croyais être prêt.

Trois semaines plus tard, avant l’e-mail de relance :

« Vous êtes de quelle entreprise déjà ? Pouvez-vous rappeler le contexte du projet ? »

Le client a posté une capture dans notre canal. Là j’ai compris : l’agent se souvenait du chat, pas de la relation. En pilote, tout le monde a acquiescé — ce n’était pas le « modèle bête », c’était confondre historique de chat et Agent Memory.

Voici comment on a corrigé OpenClaw : scénarios réels, pas un cours de vocabulaire, et la frontière entre AI Memory (stockage système) et l’historique dans l’UI. Stack : OpenHuman vs ChatGPT Memory ; IDE : Karpathy et couches de contexte.

Scénario 1 : le chat est archivé, la règle a disparu

Une équipe support B2B nous a raconté la même galère.

Semaine 3 : « Devis en PDF uniquement, pas Excel. » L’agent : « C’est noté. » Côté admin : chaque mot est là, « PDF » trouvable.

Trois mois après : devis Excel. Le client explose : « Vous suivez vraiment ? »

La règle n’est jamais entrée en Memory récupérable et exécutable — noyée dans des milliers de lignes de bavardage. Nouvelle session : « Client A = PDF seulement » ne remonte pas en tête de prompt.

L’historique = preuve d’audit. Agent Memory = état pour la prochaine décision — un flag CRM « pas d’Excel », pas réécouter trois heures d’appel avant chaque deal.

Scénario 2 : un million de tokens n’a pas évité le travail en double dans Claude Code

Autre échec dans Claude Code.

Cartographie d’un monorepo, docs d’archi — deux jours. « La fenêtre suffit, je reprendrai. »

Deux semaines après : « Continue la doc sur ce repo. » Re-scan, re-plan, brouillon similaire. Du chat reste — pas l’état de la tâche : sous-module, ce qui est dans docs/, ce qui attend ma validation — c’est dans les outils et le disque.

Karpathy : « Ne traite pas le contexte infini comme un disque dur. » En AI Memory : une ligne de checkpoint modifiable, pas 20 000 lignes de stdout.

LangGraph : mémoire vs état de thread. Liste de messages ≠ store mémoire.

Trois choses qu’un agent doit vraiment retenir

• Qui et règles dures — client A PDF only ; le patron déteste les vocaux ; l’équipe en UTC.
• Où on en était — ticket #482 chez le juridique ; alerte ack, root cause ouverte ; doc chapitre 3.
• Comment la prochaine fois — checklist release, chaîne d’approbation, astreinte.

En doc d’archi : Semantic, Episodic, Procedural — couche manquante = gêne dans ce scénario précis.

Piège qu’on a vraiment pris : tout embedder

Début OpenClaw : vectoriser chaque tour de chat. Un mois après : playbook de déploiement obsolète ressorti comme SOP ; bribes contradictoires → mauvais choix assuré.

Le dur : pas l’insertion — supprimer, modifier, borner. Chaque entrée Agent Memory : source, date, expiration/version. Filtre client/projet, puis décroissance temporelle — moins de « politiques » inventées. C’est ce qu’on met au contrat, pas « pensez vector DB ».

MCP : conclusions en Memory, pas stdout dans l’index. Model Context Protocol.

ChatGPT Memory suffit ?

ChatGPT Memory convient au ton dans une app. Agent sur Slack, Telegram, cron, IDE : Memory reste chez OpenAI. Stack complet : ChatGPT = voix, OpenHuman = faits métier, OpenClaw+MCP = exécution. Chat seul : Memory OK. Agent qui bosse : couche AI Memory dédiée.

Longue durée : la mémoire n’est que l’étape 1

Memory réparée → l’agent ne survit pas à la nuit — capot fermé, Wi-Fi, MCP tué, cron mort. Données en store, agent comme s’il n’avait jamais existé.

Trois couches : mémoire, exécution (OpenClaw Gateway sur VPS), outils (MCP lourd, xcodebuild hors du portable qui dort). Memory sur Mac/NAS, passerelle sur VPS Linux, builds sur Mac cloud — un Archive a déjà gelé notre sync vault. Gateway sur VPS.

Questions rapides