Brain-AI Memory – uma arquitetura aberta para diagnosticar falhas de memória em agentes LLM de longa execução

Fica difícil encontrar a causa quando problemas como um agente usar memórias antigas, perguntar de novo algo que já registrou, ignorar regras ou abandonar no meio um procedimento de fallback são todos vistos como “problemas de retrieval”.
O Brain-AI Memory não é um projeto que dá novos nomes a RAG, hooks, guards, harnesses e loops. Ele os separa em memória episódica e semântica, regra e execução procedurais, estado numérico, roteamento e gate de entrada, conectando as condições de falha e o ciclo de vida de cada um.
A estrutura usada por alguns meses em um sistema real de agentes multiprojeto foi publicada em formato clean-room. Inclui um exemplo de execução de 60 segundos, hooks e templates de memória reutilizáveis, justificativas operacionais e resultados de retrieval do LongMemEval-S com 500 perguntas.
Também foram publicados, sem alterações, os resultados negativos do benchmark. O pointer de 96 keywords reduziu o texto indexado em 93%, mas o recall@3 caiu de 86,1% no BM25 completo para 71,0%.
Gostaria especialmente de receber feedback sobre até que ponto falhas reais de agentes se encaixam bem nesse mapeamento de componentes, e onde não se encaixam.

[gkgusdl4]

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

Execução em 60 segundos:
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

Estou especialmente curioso sobre dois pontos de feedback.

1. As falhas de agentes reais de longa execução são suficientemente distinguíveis com esse mapeamento de componentes?
2. Para adoção real, o que é mais necessário: uma implementação de referência instalável ou um benchmark de QA end-to-end?