01 / REPRESENT
Представление и storage
Текстовые факты, embeddings, graphs, trees, composite objects; хранение в context, vector DB, graph DB, SQL или hybrid backend.
arXiv:2606.24775v1 · cs.CL / cs.DB / cs.IR
Память агента — это уже не RAG. Это data system.
Paper “Are We Ready For An Agent-Native Memory System?” спрашивает: готовы ли мы проектировать память AI-агентов как полноценную систему хранения, поиска, обновления и обслуживания знаний — а не как “положили куски текста в vector DB и молимся”.
Главная мысль
Авторы смотрят на память агента глазами database / data management инженера.
Они говорят: существующие benchmark’и слишком часто меряют только итоговый F1/BLEU и относятся к memory как к чёрному ящику. А в продакшене важно другое: как память представлена, где хранится, как извлекается, как обновляется, сколько стоит и ломается ли на длинном горизонте.
12 memory systems2 baselines5 workloads11 datasetscost / latency
Framework
Память разложили на четыре модуля.
Вместо “какая библиотека памяти лучше?” paper предлагает смотреть на сборку: что именно хранится, как оно вытащено из опыта агента, как ищется и как чистится/обновляется.
02 / EXTRACT
Извлечение памяти
Сырые логи, schema-free facts или schema-constrained records/triplets. Это решает, сколько evidence переживёт запись.
03 / RETRIEVE
Retrieval / routing
Attention, dense search, graph traversal, LLM tool calls, hybrid BM25+vector+graph. Важно не только top‑1, а собрать весь evidence.
04 / MAINTAIN
Maintenance
Версионирование, eviction, semantic consolidation, CRUD updates. Здесь решается, будет ли агент помнить актуальное, а не старое.
Architecture map
Agent memory — это pipeline, а не одна vector search кнопка.
Если упростить, каждый запрос проходит через четыре data-операции. Ошибка на любом шаге потом выглядит как “LLM галлюцинирует”, хотя корень часто в memory layer.
Findings
Что реально нашли.
Paper проводит end-to-end сравнение и ablations. Ниже — выводы без академического тумана.
01 / no silver bullet
Нет универсально лучшей памяти
Архитектура должна совпасть с bottleneck workload’а.
Hybrid systems лучше на conversational QA; graph/relations помогают в factual recall и updates; trace-preserving / long context бывает сильнее для процедурных stateful задач.
02 / evidence first
Важно собрать весь evidence, не только top‑1
Retrieval quality = evidence completion.
Simple dense search часто норм для близких фактов, но проседает, когда нужные куски старые, разбросаны по сессиям или требуют temporal связи.
03 / updates are hard
Старые факты возвращаются
Без lifecycle management получаются “hallucinations of the past”.
Графы и relation-aware подходы лучше связывают новую версию факта с той же entity/event. Append-only и простая extraction‑память хуже переживают overwrite.
04 / summary is lossy
Слишком умная compression убивает детали
Сохраняй usable evidence.
Raw / high-retention формы лучше для точного recall. Лёгкая compression ещё терпима; aggressive summaries и coarse consolidation теряют даты, имена и sparse cues.
Operational angle
Cost зависит не от “есть структура?”, а от scope maintenance.
Самый data-engineering вывод: богатая структура полезна только если её не надо постоянно перестраивать целиком.
LOCAL MAINTENANCE
Лучший cost / utility баланс
LightMem и MemTree в paper занимают сильную efficiency frontier: локальные updates/search дешевле, чем global reorg.
GLOBAL REWRITE
Дорого и медленно
Graph-wide consolidation, multi-store sync и whole-memory rewriting дают структуру, но latency растёт резко с объёмом памяти.
LONG HORIZON
Хранить больше ≠ помнить лучше
На длинном горизонте задача меняется: надо выбрать правильную абстракцию и сохранить temporal/entity связи, а не просто насыпать больше текста.
Practical takeaways
Как это читать для наших AI-agent систем.
Если коротко: agent memory надо проектировать как витрину/хранилище с lineage, update policy и SLA, а не как prompt helper.
Минимальный дизайн-чек
Перед выбором Mem0/Zep/Letta/самописного слоя спроси не “что популярнее?”, а какой failure mode страшнее: stale facts, missing evidence, latency, long-horizon drift или cost.
preserve evidenceavoid stale facts
1
Define workload
Факты пользователя, tool traces, multi-session reasoning, procedural DB actions — это разные памяти.
2
Pick representation by failure mode
Temporal updates → graph/versioning; exact recall → high-retention text; broad QA → hybrid retrieval.
3
Keep write path conservative
Не пережимать summary на записи. Лучше late filtering, чем потерять evidence навсегда.
4
Measure retrieval separately
Итоговый F1 не объяснит, почему агент ошибся. Мерить evidence recall, update correctness, latency.
5
Bound maintenance scope
Локальные updates и bounded search масштабируются лучше, чем глобальная пересборка памяти.
ИсточникPaper: Wei Zhou et al., “Are We Ready For An Agent-Native Memory System?”, arXiv:
2606.24775v1, submitted 2026-06-23T16:34:55Z, categories cs.CL, cs.DB, cs.IR.PDF metadata: 14 pages, created/modified 2026-06-24 01:16:16 UTC. Downloaded and parsed locally 2026-06-25T12:25:54Z.Artifacts/code referenced by authors: github.com/OpenDataBox/awesome-agent-memory and github.com/OpenDataBox/MemoryData.