Memory Systems for AI Agents

Memory Systems for AI Agents

• ID: 90d82a04
• 原文链接: https://stevekinney.com/writing/agent-memory-systems
• 作者 / 日期: Steve Kinney | 2026-03-01
• 分类: agents
• 来源类型: article
• 标签: agent-memory, retrieval, context-engineering, long-running-agents
• 质量评分: 4/5
• 抓取时间: 2026-08-05T15:45:26.663004+00:00

中文导读

Steve Kinney 讨论 AI Agent 记忆系统的工程设计：不要把完整对话历史当成记忆，而要区分短期工作上下文长期事实/经验检索与写入策略文章强调 hybrid retrieval过滤和裁剪比简单向量 top-k 更重要；记忆写入要考虑重要性过期合并和安全，避免把低质量或过时信息永久注入每次上下文它与今日 Agent 实践笔记中的宽写窄读热记忆小而准冷记忆可检索形成直接呼应

为什么值得关注

Agent 记忆的难点不是存进去，而是只在需要时取出少量正确不过期的内容

English Summary

Steve Kinney outlines practical memory design for AI agents: separating working context from durable memory, using hybrid retrieval and aggressive filtering, and treating write policies, forgetting, and safety as first-class concerns.

Obsidian Evidence

候选来自 OpenClaw定时任务/Agent实践探索/2026-08-05-Agent实践探索.md 的 Agent 记忆专题。

Source Extract / Metadata

Memory Systems for AI Agents: What the Research Says and What You Can Actually Build

作者: Steve Kinney

发布时间: 2026-03-25T00:00:00.000Z

原文链接: https://stevekinney.com/writing/agent-memory-systems

March 25, 2026

Memory Systems for AI Agents: What the Research Says and What You Can Actually Build

The old short-term/long-term taxonomy doesn't capture what modern agent memory systems actually do. A new three-axis framework—Forms, Functions, and Dynamics—maps the design space from flat vector stores to RL-driven memory management. Here's what the research says and what you can build today.

I’ve been building an agent memory system for the last few days, and it sent me down one of those rabbit holes where you start reading one paper on arXiv and re-surface three hours later with forty browser tabs and a completely different understanding of the problem. The thing that triggered it was a simple frustration: every agent I use—Claude Code, Cursor, custom stuff I’ve built with the Vercel AI SDK—forgets everything between sessions. They treat every conversation like their first. I’ve explained my project structure, my preferences, my constraints, and then the context window fills up or the session ends and all of that knowledge evaporates.

Yes, I know this is increasingly _less_ true as Claude Code and others have rolled out their own, built-in memory systems over the last few weeks. But, this was _always_ meant to be more of an intellectual exercise than anything else.

Apparently, I was not the only person engaged in this intellectual exercise. The Research Community™ has been remarkably productive on this problem over the last year. In December 2025, Hu et al. published “Memory in the Age of AI Agents”—a 107-page survey that attempts to unify a fragmented field. (They also maintain a companion paper list on GitHub that’s actively updated—if that’s your jam.) Dozens of other papers have landed since: A-Mem bringing Zettelkasten\-style linked notes to agent memory with 85–93% token reduction, StructMemEval showing that simple retrieval can outperform complex memory hierarchies, Memori achieving 81.95% accuracy at 5% of full context cost using semantic triples, and a bunch more I’ll reference as we go along on this journey. (And yes, that was just an excuse to use “Zettelkasten” in a sentence unironically.)

The old taxonomy—short-term memory versus long-term memory—isn’t really a thing anymore. It doesn’t capture what modern agent memory systems actually do. The survey proposes a three-axis framework that I’ve found genuinely useful for thinking about this kind of stuff: Forms (Where does memory live?), Functions (Why does the agent need memory?), and Dynamics (How does memory operate over time?). Let’s walk through what the research says at each axis, what’s practical today versus what’s still on the research frontier, and the design decisions you’ll face if you’re building a memory system for your own agents—not that I can advise that.

One thing I want to be super upfront about: I’m synthesizing a lot of material here. What follows is basically me selfishly synthesizing my notes in an attempt to better understand. I’ve read the papers and I’ve been building against some of these ideas, but I’m not a memory systems researcher. If I’ve mischaracterized someone’s work, call me out in the comments section that doesn’t exist.

The three forms: where does memory live?

The first axis asks a deceptively simple question: where does the memory physically reside? The answer splits into three categories, and the split matters because it determines what you can actually _build_ with hosted models versus what requires running your own infrastructure.

Token-level memory

Let’s start with the one we’re all familiar with—and the one you’ll _actually_ use.

Token-level memory is memory stored as explicit, discrete, human-readable units—text chunks, facts, user profiles, conversation logs. You write it to a database or the filesystem, you read it back, you stuff it into the prompt. It’s the form that works with any model, hosted or self-hosted, because it operates entirely outside the model’s internals. You can inspect it, debug it, edit it, and swap the underlying model without touching your memory layer.

This is what Mem0, Letta (née MemGPT), Zep, and most production memory frameworks implement. And for good reason: it’s the only form that’s actually tractable if you’re using a hosted frontier model through an API.

But “token-level” isn’t a single design. There’s a spectrum of topological complexity within it, and where you land on that spectrum matters:

• Flat (1D): A bag of entries with vector search over them. You store facts, you embed them, you retrieve the most similar ones at query time. Mem0 and MemGPT both started here. It’s the simplest approach, and it works surprisingly well when paired with a good retrieval pipeline. Most systems should start here.
• Planar (2D): Entries connected via explicit relationships—graphs, trees, linked notes. A-Mem’s Zettelkasten-style links, Zep’s temporal knowledge graph, RAPTOR’s recursive abstractive tree. These structures enable multi-hop reasoning—following chains of connections to answer questions that no single entry can answer alone. The trade-off is maintenance complexity. Graphs need to be pruned, updated, and kept consistent as new information arrives.
• Hierarchical (3D): Multiple abstraction layers with cross-layer links. Raw entries at the bottom, cluster summaries in the middle, global abstractions at the top. HippoRAG implements a dual-layer approach inspired by how the hippocampus indexes memories. Most powerful for complex reasoning, most complex to build and maintain.

Here’s the practical guidance: flat is probably right for your system. I know that sounds anticlimactic after describing the full spectrum, but the StructMemEval benchmark showed that simple retrieval can outperform complex memory hierarchies on standard benchmarks like LoCoMo and LongMemEval. Move to planar or hierarchical only when you observe specific retrieval failures that flat retrieval can’t solve—like multi-hop questions where the answer requires chaining through multiple entries.

Latent memory

Next up: The one you should probably understand but you probably won’t build.

Latent memory is memory stored as the model’s own internal representations—hidden states, KV cache entries, compressed vectors. It lives inside the model’s computation, not in an external database.

A Word on Terminology

Before we go further, I need to address the naming collision that trips up every engineer I’ve talked to about this. When memory researchers say “KV cache,” they do _not_ mean Redis. They do not mean a key-value database. The “Key” and “Value” in a transformer’s KV cache are linear projections of each token’s hidden state that serve specific roles in the attention mechanism. The Query vector multiplied by the Key vector produces a relevance score, which is then used to weight-blend the Value vectors. It’s an internal data structure of the transformer architecture, not a caching layer in the infrastructure sense. (I’ve seen experienced engineers spend twenty minutes confused about this in paper discussions, so if that was you, you’re in good company.)

With that cleared up, latent memory has three subtypes:

• Reuse: Save the KV cache from a forward pass, reload it later. The model picks up where it left off. Memorizing Transformers (Wu et al., 2022), LONGMEM, and FOT all explore this approach.
• Transform: Prune or compress the KV cache to keep only what matters. SnapKV uses head-wise voting to decide what to keep. H2O evicts “heavy hitter” entries. PyramidKV allocates different budgets per layer. The idea is the same across all of them: the model was paying attention to certain tokens more than others, so keep those and drop the rest.
• Generate: Train a separate module to compress input into a handful of “memory tokens.” Gist tokens (Mu et al., 2023), [AutoCompressor](https://arxi

...[truncated by AAIF intake]...