What is agentic memory?
Agentic memory is the mechanism that lets an AI agent keep information across separate runs, instead of treating every invocation as a first meeting. Without it, an agent only knows what fits in its current context window: the prompt, the conversation so far, and whatever documents were pasted in this time. Close the session and all of that is gone. Agentic memory is the layer that survives the reset, a place to write down what happened and read it back on the next run.
The research literature on language-model agents, such as the CoALA framework, splits it into a few working categories:
- Working memory. What the agent is holding for the run it is in right now. Short-lived, gone once the run ends.
- Episodic memory. A record of specific past events: what task ran, what the agent decided, what the outcome was.
- Semantic memory. Facts and preferences distilled out of those events, kept in a form the agent can look up later, such as a user's role, a project's constraints, or a correction that should not be repeated.
- Procedural memory. How the agent goes about things: the patterns baked into the model itself, plus the steps written down in its own code and instructions.
The storage underneath can be almost anything: a vector database for similarity search, a relational table, a key-value store, or plain Markdown and JSON files the agent reads directly. The category names describe what the memory is for, not how it is stored.
In plain words
Think of the difference between a brand-new temp and someone who has worked at the company for three years. Both can read the same handbook on their desk (that is the context window). But the veteran also has a notebook of "we tried that, it didn't work" and "this client always wants X, not Y" that they consult before answering. Agentic memory is that notebook, plus the discipline of actually writing new pages in it and occasionally throwing old ones out.
When it matters
- Work that spans more than one run. An agent that triages support tickets, monitors a project, or works a backlog over days needs to remember what it already decided, or it repeats the same research and the same mistakes on every wake-up.
- Corrections that should stick. If a person tells an agent "don't do X, do Y instead," that instruction is worthless if it evaporates at the end of the session. Memory is what turns a one-off correction into a standing rule.
- Personalization without re-explaining. An agent that remembers a user's stack, role, and preferences skips re-establishing that context on every single call, something in-context learning alone cannot do once the session ends.
- Cost. Re-pasting the same background into every prompt burns tokens on every run. A short, well-curated memory record is usually far cheaper than re-deriving or re-explaining the same context from scratch. It also keeps the window shorter during a long run, and a shorter window is what holds context rot off.
Common mistakes
- Reaching for a vector database by default. Embeddings and a vector store are a specific tool for a specific problem: fuzzy semantic search over a large, unstructured corpus. Some agents only need a small, stable set of durable facts about a project or a person. For that case, structured Markdown or JSON records the agent reads and writes directly are often simpler and cheaper. It is also easier for a human to audit than a similarity search that returns "close enough" matches.
- Treating files and a vector store as an either/or. One of our own internal agents runs both layers, split by job. Facts that have to be exact live in plain Markdown records, with a small index the agent loads at the start of every session. That covers a project's constraints, who decided what, and a correction that must not be repeated. A person can read those records, edit them, and review the change in a pull request. Recall across everything that agent has seen over months runs through a separate memory service of ours, Mozeček, built on PostgreSQL and pgvector with hybrid vector and full-text search. The files carry what has to be exact; the vector store carries what only has to be close enough. Start with the files and add the store when the volume and the fuzziness of the recall justify it, not the other way round.
- Storing conclusions without provenance. A memory record that says "the client prefers weekly reports" is far less useful than one that also says who said that, when, and why. Without a source, a stale or wrong entry cannot be told apart from a correct one, and nobody can safely update it later.
- Never forgetting anything. Memory that only accumulates turns into a pile of outdated and contradictory notes. Useful memory systems supersede or expire old entries when new information contradicts them, instead of keeping every version forever.
- Confusing memory with a bigger context window. A larger window means the agent can hold more at once during a single run; it says nothing about whether any of it survives to the next one. The two solve different problems.
Related articles:
- What is a context window? - The short-lived, in-session memory that agentic memory is built to outlast.
- What is context rot? - Why cramming more into the window is not a substitute for real memory.
- What's an agent? - The system that agentic memory turns from stateless into stateful.
- What is in-context learning? - Picking up a task from examples in the prompt, with nothing kept afterward.
- What is agentic RAG? - A retrieval pattern that often sits on top of an agent's memory store.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.