Agentic memory
Memory is not one thing.
There's a lot of talk about agentic memory, but not all of it refers to the same thing. This page explores memory from two different axes:what kind of memory it is, and who it is for.
Three kinds of memory
Cognitive science splits memory into different categories: sensory, short-term/working, and long-term memory. Agentic memory can be split along similar lines:
Working memory
This is also often referred to as the context, and it is what the agent actively holds while it is doing the work during a session. The working memory is short-lived, scoped to a single session and vanishes once the session terminates.
Episodic memory
This is the entire recording of an agentic session. It doesn't summarize but is the exact recollection of what happened during the session, including what was tried and what got rejected. This memory persists after the session terminates and is usually stored in local files on the computer the agent ran on.
Semantic memory
This is the collection of facts, PRDs and design docs, and it is the distilled version of the episodic memory. Semantic memory is a summary and thus much more concise. But it also tends to be lossy and can be detrimental if not frequently updated.
Most tools that talk about "memory" mean the semantic kind, usually because a list of facts is the easiest thing to store and show.
The second axis: who is the memory for?
The three types are one dimension. The other dimension is less about how memory is stored but rather "who is it about?".
- Personalized memory
- This is the memory about what you want, how you like to work and which tools you reach for. It can be episodic or semantic, but most tools implement it as semantic: a stored profile of preferences.
- Institutional memory
- This is the memory about how your team works. It is far harder to build, not for technical reasons but for human ones. Personal preferences are easy to capture because there is only one person to agree with. Team preferences require agreement, and teams rarely agree cleanly on how things "should" be done. The document that claims to speak for the team is usually a negotiated fiction.
- Code
- This is the memory about how the code itself was produced, independent of you or your team. Not "Victor likes tabs" but "this retry logic exists because the payment API times out under load, and here is the session where that was discovered and handled." It too can be episodic or semantic.
At the core is the agent session
The core primitive each memory emerges from is the agent session. It is what encodes the original intent, the deviations and the tradeoffs that were discussed along the way. The idea is to take this short-lived working memory and turn it into episodic memory.
Capture the session
Episodic memory is not summarized after the fact but it is rather captured as it happens. Each session is kept entirely as its own record. Nothing is thrown away because you cannot anticipate which detail turns out to matter.
While the working memory vanishes the moment the agent session terminates, the session itself is persisted to the local file system, where it might get purged at some point. A meta-harness can close this gap. By wrapping the underlying agent harness it can gather the session logs and store them centrally so they can be processed at a later point.
Then distill it
Individual session recordings precisely represent what happened, but they are also heavy to process. That's why often this episodic memory is consolidated into shorter fragments that can be connected in a pool of general knowledge and facts. Future sessions can connect to this pool rather than starting from a cold context.
This process, often also referred to as dreaming, needs to happen in the background. It is not a one-time operation but an ongoing task, otherwise the pool fills up with stale and wrong knowledge.
Why memory matters
Your source code and Git encode different things. Version control gives you the WHAT and WHEN, and your code has the final result. What is lost is the reasoning that went into producing it. Right now that reasoning lives in the developers' heads, and it is completely lost when agents produce the code.
The agent session encodes the WHY.
Memory is the base context to start from
Agents can only produce quality answers based on the knowledge and context they have. They will look at your code, commit history and docs and produce a plan.
By giving your agent knowledge about past sessions, that confident and urgent P0 issue (that made a lot of sense at the time) can turn out to be a deliberate tradeoff and become obsolete.
It is not that the model got smarter, we just gave it more context to reason about.
What you can do with memory
Giving agents access to past sessions and a central memory store opens a series of interesting capabilities.
Interactive review sessions
Reviewing large PRs that have been created by agents is hard. Being able to instantiate the implementing agent session helps to better understand the decisions that went into the final implementation. This is helpful both for human-led reviews as well as for adversarial reviews by another agent.
Like Git blame but for agent sessions
Git blame only shows you who implemented the line of code. Episodic memory gives you the ability to load the agent session from any part of the codebase, which gives you a much deeper and more complete view into the decisions that went into the code change.
Resume anyone's work
You can resume any team member's agentic session to collaborate on it, whether that's for picking it up and implementing it or just for giving feedback on an implementation plan.
Build on what the team already did
Someone has almost certainly worked through the area you are about to touch. Shared, resumable sessions allow you to load related sessions into your own context to give your agent a complete picture of the situation.
Where this fits
Memory is one capability of a meta-harness
A meta-harness is the layer above agent harnesses like Claude Code and Codex. Capturing and retrieving sessions is one of the things it does, alongside cross-repo coordination, routing, sandboxing, and policy.