Brain-AI Memory – Eine offene Architektur zur Diagnose von Memory-Fehlern bei lang laufenden LLM-Agenten

Wenn man Probleme wie Agenten, die veraltete Erinnerungen verwenden, bereits Dokumentiertes erneut abfragen, Regeln ignorieren oder Fallback-Prozeduren auf halbem Weg abbrechen, pauschal als „Retrieval-Problem“ betrachtet, ist die Ursache schwer zu finden.
Brain-AI Memory ist kein Projekt, das RAG, Hooks, Guards, Harnesses und Loops nur mit neuen Namen versieht. Es trennt sie in episodisches und semantisches Memory, prozedurale Regeln und Ausführung, numerischen Zustand, Routing und Input-Gate und verknüpft jeweils Fehlerbedingungen und Lifecycle.
Die Struktur, die über mehrere Monate in einem realen Multi-Project-Agent-System genutzt wurde, wurde im Clean-Room-Ansatz veröffentlicht. Enthalten sind ein 60-Sekunden-Ausführungsbeispiel, wiederverwendbare Hooks und Memory-Templates, betriebliche Begründungen sowie Retrieval-Ergebnisse aus LongMemEval-S mit 500 Fragen.
Auch die negativen Benchmark-Ergebnisse wurden unverändert veröffentlicht. Der 96-Keyword-Pointer reduzierte den indexierten Text um 93 %, senkte recall@3 jedoch von 86,1 % bei vollständigem BM25 auf 71,0 %.
Besonders erwünscht ist Feedback dazu, ob reale Agent-Failures gut in dieses Component Mapping passen – und wo nicht.

[gkgusdl4]

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

Ausführung in 60 Sekunden:
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

Mich interessieren besonders zwei Arten von Feedback.

1. Lassen sich die Fehler realer langlaufender Agents mit diesem Component Mapping ausreichend voneinander abgrenzen?
2. Was wird für eine tatsächliche Übernahme eher noch benötigt: eine installierbare Reference Implementation oder ein End-to-End-QA-Benchmark?