Brain-AI Memory – une architecture ouverte pour diagnostiquer les échecs de mémoire des agents LLM à longue exécution

Si l’on considère comme de simples « problèmes de retrieval » le fait qu’un agent utilise de vieux souvenirs, redemande ce qu’il a déjà enregistré, ignore des règles ou abandonne en cours de route une procédure de fallback, il devient difficile d’en identifier la cause.
Brain-AI Memory n’est pas un projet qui se contente de renommer RAG, hook, guard, harness et loop. Il les distingue en mémoire épisodique et sémantique, règles procédurales et exécution, état numérique, routage et filtre d’entrée, puis relie pour chacun les conditions d’échec et le cycle de vie.
Cette architecture, utilisée pendant plusieurs mois dans un véritable système d’agents multi-projets, a été publiée sous forme clean-room. Elle inclut un exemple d’exécution en 60 secondes, des hook réutilisables et des modèles de mémoire, des justifications opérationnelles, ainsi que les résultats de retrieval sur les 500 questions de LongMemEval-S.
Les résultats négatifs du benchmark sont également publiés tels quels. Le pointeur à 96 mots-clés a réduit de 93 % le texte indexé, mais le recall@3 est tombé de 86,1 % avec le BM25 complet à 71,0 %.
Je souhaite en particulier recueillir des retours sur la façon dont les échecs réels des agents s’inscrivent — ou non — dans ce mapping des composants.

[gkgusdl4]

README en coréen :
https://github.com/Hahyun-Lee/brain-ai-memory/blob/main/README.ko.md

Exécution en 60 secondes :
git clone https://github.com/Hahyun-Lee/brain-ai-memory.git
cd brain-ai-memory
python3 examples/01_guard_in_action.py
python3 examples/02_lifecycle_decision.py

Je serais particulièrement curieux d’avoir vos retours sur deux points.

1. Les échecs d’un agent réellement exécuté sur le long terme peuvent-ils être suffisamment distingués avec ce component mapping ?
2. Pour une adoption réelle, qu’est-ce qui manque le plus : une reference implementation installable, ou un benchmark QA de bout en bout ?