J'ai déchiré la mémoire markdown par défaut d'OpenClaw et construit une couche API Node.js/Postgres à la place

Un développeur créant un analyseur de productivité cognitive avec OpenClaw s'est heurté à un mur avec le fichier MEMORY.md par défaut après des semaines d'utilisation. Le fichier texte plat s'est transformé en moteur d'hallucination — l'agent se rappelait des conceptions d'API obsolètes comme vérité et oubliait les compromis système convenus. La solution : désactiver le plugin memory-core et construire une couche d'application déterministe.

Détails de l'architecture

• Base de données : PostgreSQL avec des schémas stricts pour system_architecture_rules, api_design_decisions et feature_roadmaps.
• Middleware : Backend Node.js/Express exposé à OpenClaw via des appels d'outils personnalisés.
• Contrats typés : L'agent doit exécuter POST /memory/architecture avec un payload JSON validé par TypeScript pour enregistrer les compromis de conception ou les routes API.
• Injection de contexte immuable : Lors d'une requête, la couche d'outils récupère les lignes exactes de Postgres et les injecte dans la fenêtre de contexte avant que l'agent ne raisonne.

Résultats

La dérive contextuelle est tombée à zéro absolu. L'agent ne peut pas halluciner un schéma de base de données car il est contraint par les données relationnelles. La mise à jour d'une règle architecturale écrase l'ancienne ligne — aucune note conflictuelle. Compromis : ~150 ms de latence par appel d'outil et un week-end de codage backend.

Conclusion

Le développeur soutient que la mémoire d'un agent n'est pas un problème de stockage mais un problème de conception d'API. Forcer le LLM à catégoriser les pensées via des limites d'outils strictes empêche la corruption de l'état sur des centaines d'itérations. Il envisage d'ouvrir le dépôt Node en open source.