Are We Ready For An Agent-Native Memory System?
- Authors: Wei Zhou, Xuanhe Zhou, Shaokun Han, Hongming Xu, Guoliang Li, Zhiyu Li, Feiyu Xiong, Fan Wu
- Affiliation: Shanghai Jiao Tong University; Tsinghua University; MemTensor Technology
- Paper: https://arxiv.org/abs/2606.24775
- Code: https://github.com/OpenDataBox/MemoryData
- Paper list: https://github.com/OpenDataBox/awesome-agent-memory
- Published: June 23, 2026 (arXiv preprint)

TL; DR
agent memory를 data management system 관점에서 representation and storage / extraction / retrieval and routing / maintenance 4모듈로 분해, 12개 memory system + 2개 reference baseline(Long Context, Embedding RAG)을 5개 workload / 11개 dataset에서 평가
Review Video

Background
- agent memory는 단순 RAG 기반에서부터 저장+검색+갱신+consolidation+lifecycle governance 등을 수행하는 data management system으로 진화
- LLM의 parametric weight와 휘발성 context window에서 분리된, 단일 inference step을 넘어 정보를 유지하는 외부 인프라 (Mem0, MemGPT/Letta, Zep, A-MEM)로 동작
- 잘못 설계된 memory는 factual contradiction, catastrophic forgetting, 과도한 latency를 유발
- RAG/context engineering과의 구분
- RAG: 정적 corpus에서 단발 retrieval하는 stateless read-only primitive
- context engineering: 매 turn마다 유한한 context window를 큐레이션하는 더 넓은 실천
- agent memory: 상기 개념들과 달리 write/update/routing을 가진 지속되는 상태 관리 시스템
- 기존 agent memory 아키텍처 구분
Fig 1- Stream-and-Reflection (MemoryBank): timestamp memory stream을 주기적으로 reflection으로 요약해 다시 stream에 write-back
- Hierarchical Tiered (MemGPT): core memory와 archival storage를 분리하고 eviction/promotion으로 tier 간 이동
- Knowledge Graph (Mem0_g, Zep): entity/relation/temporal evolution을 구조화, entity disambiguation과 conflict resolution 포함
- Composite Hybrid (A-MEM): schema-aware memory object를 다중 storage substrate로 routing, runtime state(KV cache)와 long-term store(vector/graph/keyword) 분리
- agent memory를 data management system으로 간주할 때 기존 평가의 공백
- 대표 아키텍처 누락: MemoChat, MemTree, LightMem 등이 통합 workload에서 비교되지 않음
- 단면적 e2e metric(F1, BLEU)에 의존
- index 구축 시간, query latency 같은 operational cost를 거의 측정 안 함
- memory를 monolithic black box로 취급, data management 모듈로 분해하지 않음
- DB 진영의 선행 시도(Wu et al., 2026, VLDB)도 chatbot 중심 dataset(LoCoMo, LongMemEval)으로 범위 한정, 복잡한 agentic 실행 시나리오 배제
- data systems 관점에서 agent memory를 다루려는 흐름 자체는 가속 (Data Agents, SIGMOD 2026 Tutorial)
Problem States
agent memory를 data management system으로 볼 때, 무엇을 어떤 축으로 측정해야 하는가
- 아키텍처가 파편화되어 공정한 cross-system 비교가 불가 → 통합 testbed와 unified workload 필요
- e2e 성공률만으로는 어느 모듈이 병목인지 알 수 없음 → representation/extraction/retrieval/maintenance 분리한 fine-grained 측정 필요
- production 배치는 정확도뿐 아니라 비용이 관건 → index 구축 시간, query latency를 동일 trace로 측정 필요
- 지식이 갱신/충돌하는 동적 환경 → temporal update robustness와 long-horizon stability를 별도 축으로 평가 필요
Suggestions
Definition
- agent memory $\mathcal{M}$: 단일 inference step을 넘어 누적 상태를 유지하고 이후 추론/행동이 접근 가능하게 하는 persistent data management object
- memory system을 lifecycle을 분담하는 네 모듈의 tuple로 형식화 (
Tab 1)- $\mathcal{R}$ (Representation & Storage): 논리적 memory format & 물리적 저장/인덱싱
- $\mathcal{S}$ (Extraction): 이질적 입력 stream을 논리적 memory primitive로 변환
- $\mathcal{Q}$ (Retrieval & Routing): query context로 관련 memory 부분집합을 식별
- $\mathcal{U}$ (Maintenance): memory entry의 동적 lifecycle 정책
- memory type 두 축
- temporal(short-term volatile / long-term persistent)
- functional(episodic / semantic / procedural / user preference)
R: Memory Representation & Storage Fig 2,3
- logical representation: 어떤 형태로
- Token-Level Sequence: 구조 추상화 없는 1차원 sequence
- explicit discrete text token(Mem0의 fact, MemoChat의 JSON memo)
- implicit continuous vector token(fact embedding, KV-cache; MemoRAG)
- Graph & Tree Topology
- temporal KG(Zep, Mem0_g의 LIVES_IN 같은 triplet)
- hierarchical tree(MemTree)
- Heterogeneous Composite: memory 한 단위를 단일 포맷이 아니라 여러 종류를 묶은 컨테이너로 취급. 한 단위 안에 표현형이 여러개이거나 메타데이터를 포함(MemOS의 MemCube = plaintext + activation + parametric)
- Token-Level Sequence: 구조 추상화 없는 1차원 sequence
- physical storage: 어디에 쌓는가
- transient in-context register(MemoChat, MemAgent): 외부 DB 없이 모델 활성 상태(context window/KV-cache) 안에 그냥 두는 방식 (context 날아가면 사라지는 휘발성)
- specialized single-engine(vector/graph/SQL/file): 전용 backend 하나에 저장
- heterogeneous multi-engine(SimpleMem, MemOS): backend 여러로 분산 저장, e.g. dense embedding + BM25 + SQL predicate
S: Memory Extraction Fig 4
- Raw Sequence Concatenation: 추출 prompt 없이 raw token을 그대로 이어붙임 (MEM1, MemAgent)
- Schema-Free Semantic Extraction: 자유형 fact나 연속 벡터로 distill (Mem0의 “User is vegetarian and dairy-free”)
- Schema-Constrained Structured Extraction: 사전 정의 schema로 typed 출력 생성
- Zep/Mem0_g: typed triplet (Zep: reflection 검증으로 hallucinated triplet 억제)
- MemoChat: JSON
Q: Memory Retrieval & Routing Fig 5
- Native Attention-Based: 외부 DB I/O 없이(별도 검색 없이) KV cache 내 self-attention으로 암묵적인 retrieval (MEM1, MemAgent)
- Semantic-Based Dense (KNN): vector 유사도 검색 (Mem0, LightMem, MemTree의 collapsed-tree)
- Topological Subgraph Traversal: graph edge를 따라 인접 노드 수집 (Mem0_g, A-MEM)
- Autonomous Agentic Routing: LLM이 query planner 역할
- function call invocation(Letta)
- generative query expansion(SimpleMem에서 intent-aware planning)
- Multi-Stage Hybrid
- sequential(predicate 필터 후 semantic; MemoryOS)
- parallel ensemble(BM25 + dense + BFS 후 RRF/MMR/cross-encoder rerank; Zep)
U: Memory Maintenance Fig 6
- Timestamp-Based Multi-Versioning: 물리 삭제 대신 validity flag로 논리 무효화
- Zep, Mem0_g;
- LightMem에서 append-only
- MemOS의 differential write
- Capacity-Driven Physical Eviction: (실제로 버리는 경우)
- constraint-based hard eviction(FIFO/token limit; MEM1, MemAgent, Letta)
- score-based priority eviction(heat/temporal decay; MemoryOS)
- LLM-Driven Semantic Consolidation: LLM으로 병합/압축 등
- inline compaction(SimpleMem, MemTree의 recursive summary)
- tool-driven CRUD(Mem0의 UPDATE/DELETE)
- Continuous Parametric Optimization: 온라인 inference와 분리해 offline로 parameter 자체를 갱신 (MemoRAG의 RLGF); 비동기 재학습
Effects
- Experimental setup
- 12개 대표 메모리 시스템 & 2개 baseline(Long Context, Embedding RAG)
- Sequential Context (token-level, 3개)
- MemAgent: RL로 고정 길이 텍스트 요약을 갱신하며 KV-cache에 얹는 long-context agent
- Mem0: 대화에서 discrete fact를 뽑아 vector DB에 넣고 tool-calling CRUD로 관리하는 production 메모리
- MemoChat: 대화를 topic/summary/raw JSON memo로 정리해 context 안에 유지
- Structural Topological (graph/tree, 3개)
- Zep: temporal KG(Neo4j) + triplet 추출(reflection 검증) + dense/BM25/BFS 병렬 검색의 대표주자
- Cognee: entity-relation triplet 기반, graph+vector+relational 다중 엔진
- MemTree: leaf=세부 사실, ancestor=요약인 계층 트리 메모리
- Multi-Paradigm Hybrid (composite, 6개)
- MemGPT: core/archival tier를 함수 호출로 self-edit하는 OS식 메모리
- LightMem: entropy-gated 추출 + append-only의 경량·효율 지향
- SimpleMem: intent-aware query planning + 다중 엔진(vector+BM25+SQL)의 lifelong 메모리
- MemOS: MemCube(plaintext+activation+parametric)로 memory를 OS처럼 운영 (MemTensor, 이 논문 저자)
- MemoryOS: segment-page 구조 + heat 기반 eviction
- A-MEM: atomic note를 링크로 엮는 Zettelkasten식 agentic 메모리
- Sequential Context (token-level, 3개)
- Research Question
RQ1effectiveness: 메모리 시스템이 task 성능을 실제로 올리나? 무엇이 1등인가?- LoCoMo, LongMemEval, DB-Bench(LifelongAgentBench)
RQ2retrieval fidelity: 최종 답 말고, query에 필요한 근거 자체를 제대로 꺼내나? (생성과 분리해서 retrieval만 평가)- LoCoMo의 source-level gold evidence로 Recall@K와 evidence-distance gap별 Recall@10
RQ3update robustness: 사실이 갱신·충돌할 때 최신의 맞는 상태를 유지하나? backbone 바뀌어도 견고한가?- LongMemEval(Knowledge Update, Temporal Reasoning) + LoCoMo Temporal, + 4개 LLM backbone ablation
RQ4long-horizon stability: history가 길어질수록(긴 context / 먼 증거) 성능이 유지되나?- LongBench(context length), LongMemEval(session 수), LoCoMo(evidence distance)
RQ5cost: utility 대비 latency, workload별 latency?- 통일된 time-overhead trace 기반 utility-latency frontier
- metric: EM, Answer F1, Substring EM, ROUGE-L F1/Recall, GPT-5.4 LLM Judge, Recall@K, latency
- 12개 대표 메모리 시스템 & 2개 baseline(Long Context, Embedding RAG)
- Results
RQ1전 task에서 특출난 SOTA 아키텍처는 없고, 각 task과의 정렬에 따라 상이한 결과Fig 7- LongMemEval: structure-aware가 우세 (Zep)
- LoCoMo의 exact: hybrid filtering (MemOS)
- DB-Bench: trace-preserving 강세 (Long Context, MemoChat, MemGPT)
- (EM은 짧고 canonical한 답에는 유효한 지표더라도 의미 동치/실행 성공을 못 잡아 LLM Judge/TSR로 보완)
RQ2retrieval은 top-1 ranking이 아니라 evidence-completion 문제Fig 8- SimpleMem: Recall@1 최고 성능이나, A-MEM/MemTree가 Recall@5/@10에서 역전 (69.5/85.9, 59.7/80.5)
- evidence-distance gap이 커질수록 Embedding RAG 성능 급락, 상대적으로 구조화 memory는 안정적
RQ3갱신 후 정확성은 model capacity가 아니라 pipeline 설계 문제Tab 2Fig 9- Knowledge Update는 Zep, Temporal Reasoning은 Cognee, 최신 상태 grounding은 MemOS 우세
- backbone 바꿔도 순위는 거의 불변 == grounding은 generation 이전에 결정
- lifecycle 없는 store는 stale fact를 반환하는 “hallucinations of the past”라 주장
RQ4horizon이 길어질수록 volume이 아니라 abstraction 선택이 관건Fig 10- LongBench: Long Context는 Short→Medium 급락, SimpleMem은 거의 유지
- LoCoMo evidence gap: Embedding RAG는 급락, graph/consolidated memory(Cognee/MemOS/MemoryOS)는 유지
RQ5비용은 구조 유무가 아니라 maintenance scope가 좌우Fig 11- LightMem(48.3 utility @ 3.67s)/MemTree(63.5 @ 15.9s)가 효율 frontier; MemoryOS는 82.0을 28.6s에, Cognee/Zep은 84 이상을 116.5s/155.1s에서야 달성
- 구조화 시스템은 latency가 orders-of-magnitude 비싸지만 정확도 이득은 비례하지 않음 → localized maintenance가 global reorganization보다 cost-efficient
- 모듈별 fine-grained ablation (한 번에 한 모듈만 변형)
- M1 Representation
Tab 3: raw retention > abstraction- LightMem User-Only Raw가 전 지표 최고, summary는 급락, deeper tree 개선 미미
- M2 Extraction
Tab 4: coverage-preserving이 가장 안정적- coarse segmentation, light memorize, user+assistant turn 동시 저장이 유리 (late filtering 원칙)
- M3 Retrieval
Tab 5: moderate hybrid fusion(A-MEM Hybrid-Balanced) + lightweight planning(SimpleMem Planning Only 90.6 Recall)이 최적- reflection 추가는 이득 없음
- M4 Maintenance
Fig 12: conservative consolidation이 delayed flush/과한 요약보다 우수 (MemoryOS Conservative-Merge 23.5 Ans. F1)
- M1 Representation
Personal note. DB 쪽에서 agent memory를 data management로 들고 가는 줄기를 제대로 정리하겠다는 서베이 페이퍼에 가깝다고 느꼈습니다. 다만 개인적으로는 다른 메모리 서베이 페이퍼가 그렇듯 구분간 중첩되거나 하는 경우가 잦아서 구분 자체에 의의를 두기 보다는, 대표 메모리 베이스라인을 모두 가져와서 평가해본 것이 더 유익하다고 생각합니다. raw context가 abstraction 대비 정확도 측면 결과는 좋다는 결과는 지난 KATE 연구에서 본 instance-level > intent-level이랑 같은 주장을 하고 있어, stable한 관측으로 받아들일 수 있어보여요. 다만 이미 말씀드렸던 바와 같이 저자들이 주장하는 agentic memory에서 다루는 task가 결국 저장된 fact를 꺼내는 recall(QA)라, 저희 이전 연구의 “관측되지 않은 선호를 추론하는” 문제랑은 결이 다르다는 것은 감안해야 할 것으로 보입니다. 결과적으로 봐도 잘 만들었다는 메모리들도 단순 raw context를 넣는 것만 못하다는 결과가 종종 이어지는 것도 눈여겨볼만 합니다. 그래서 agent memory는 어떻게 정의하고, 어떠해야하는지를 제시하지는 않습니다만,, 이전에 언급드렸던 향후 연구로 하고자 하는 cross-attribute propagation은 이 논문의 cost 결론(global reorganization이 제일 비싸더라!)에 딱 걸리는 부분이라, 이미 말씀 나눴기도 했는데, graph-wide로 돌리기보다 local하게 가야겠다는 생각이 들긴 합니다. conservative consolidation이 이긴다는 결과도 belief update를 보수적으로 가져갈 근거로 둘 수는 있어보이는 결과로 이해했습니다.