What Is Agent Memory Made Of? Anthropic Breaks It Into Components

What is agent memory actually made of? Anthropic just published a research post titled “The Components of Agent Memory,” and the plural in that title is the point.

Here is the claim in the framing: memory is not a feature you switch on. It is several parts that have to work together.

That contradicts how most of us ship it. Memory gets treated as one box on the architecture diagram, usually a vector store with a retrieval call bolted to the prompt. Call it done. Move on.

I am working from the title and framing of the post. Read it for Anthropic’s exact breakdown. The breakdown below is my own reading of the engineering, not a summary of their list.

What you can measure today

The source gives no benchmark figure. No recall score, no cost per session, no percentage. So I will not invent one.

That absence is the gap. There is no shared number for “this agent remembers well.” You can compare models on coding tasks. You cannot compare memory setups on anything comparable. Each team grades its own homework, usually by feel.

Why the gap exists

It is a constraint, not negligence. A model does not carry anything from one call to the next. Every turn starts from the text you hand it, and that text has a hard size limit.

So “memory” has to be built around the model. Something decides what gets written down. Something decides where it is stored. Something decides what comes back, and when. Something has to decide what gets dropped.

Each of those is a separate decision, and each can fail separately. Write too much and retrieval fills with noise. Retrieve badly and the right fact sits unread in storage. Never expire anything and the agent confidently acts on a fact that stopped being true.

A single vector database answers only the storage and lookup part. The write policy and the forgetting policy are still your code.

What would close it

Two things.

First, tests that span sessions. Plant a fact in one session. Change it in another. Ask in a third. Score whether the agent used the current version.

Second, component-level ablation. Swap out one part, such as the write rule, and see whether the score moves. If you cannot say which part caused a failure, you do not have components. You have a blob.

Evidence the gap has closed: teams publish memory results that name which part they changed. Until then, treat any “our agent remembers” claim as unmeasured.

My read

The next memory failure in your agent logs will be a write or retrieval decision, not a model error. If you trace one and it turns out to be the model, I am wrong.

That matches a pattern in agent work generally: the harness around the model decides outcomes. This Show HN on guardrails lifting a small model on agentic tasks makes the same case from another angle. For where memory sits among the other layers of an agent system, see the full agentic SDLC breakdown.

If you want one of these a day, subscribe. One AI signal a day. 90 seconds. No fluff.