AI agent memory, the 4 types and what each one costs

AI agent memory is the store an agent writes to during one session and reads back at the start of the next, so what it learned about you survives after the conversation window is thrown away. The model itself learns nothing between calls, so every request arrives with an empty head unless your own code hands it something to read first.

That distinction decides everything else on this page. A bigger context window is a bigger desk rather than a better memory, and a saved transcript is a recording rather than a memory. Working AI agent memory is a small edited store that sits outside the model, written on purpose and read on purpose.

Almost every explainer on this subject stops after naming the 4 types of memory, so here are the 2 things they leave out. Memory is measurable in money, and on published prices a long conversation that keeps a memory file costs roughly a quarter of the same conversation replaying its history. It is also attackable, and a false memory somebody else planted keeps working after every restart.

Why does an AI agent forget everything between sessions?

An agent forgets because the API call behind it is stateless, so nothing from the last session exists in the next one unless your own code puts it back on the wire. Anthropic says it outright in the instruction its API adds to the system prompt when the memory tool is enabled, which tells the model to assume interruption because its context window might be reset at any moment.

3 things get confused here, and separating them makes the rest of the subject easy. The context window is the working desk, the space a model can see during a single call. The transcript is the recording of what was said, which your code can replay by sending it again. Memory is the edited store that outlives both, holding what is still true after the desk has been cleared.

A bigger desk does not fix it. The newest Claude models carry a 1M token context window at standard pricing, which sounds like enough room to never forget anything, and inside one long session it genuinely is. The session still ends at some point, and the next call after that starts from nothing all over again. Sending a full history back costs real money too, even when you have kept every line of it.

Replaying the transcript is the naive fix, and it works for a while. Cost grows with the square of the conversation length, because every turn resends everything that came before it. The ceiling arrives later, when the history outgrows the window and something has to be dropped. There is a quieter failure too, since a model reading a whole afternoon of small talk to find one stated preference will sometimes read straight past it.

This is also why the frameworks people compare when they start building, the ones we put head to head in CrewAI vs LangGraph, spend so much of their surface on state rather than on prompting. Prompting is the easy half of the job, and deciding what the agent still knows tomorrow morning is the design problem underneath every agent that runs longer than an afternoon.

What are the 4 types of AI agent memory?

The 4 types are working memory for the task in hand, semantic memory for facts, episodic memory for what happened before, and procedural memory for how a job gets done. Mem0's own guide, Kore.ai's explainer and LangChain's post all describe the same 4 buckets under slightly different labels, which is why the vocabulary looks unstable when you read 3 of them in a row.

Working memory is the current session, scoped to one conversation. LangGraph calls this a checkpointer and ties it to a thread id, so a run can be paused and resumed without touching anything a different user did last week. It disappears when the thread ends, and that is the intended behaviour rather than a limitation.

Semantic memory holds facts that stay true. The client bills in euros and the deploy branch is called main. A fact like that is small, worth keeping for a long time, and cheap enough to reread at the start of every single session without thinking about the cost.

Episodic memory holds what actually happened on earlier runs. The agent tried to refund an order last Tuesday, the API refused the request, and a human sorted it out by hand. This is the type that lets an agent stop repeating the same mistake, and it is the most expensive to keep, because events pile up far faster than facts do.

Procedural memory holds the method rather than the fact. It is the checklist an agent rewrote for itself after learning that this client's invoices need a purchase order number before they go out. Anthropic's documented pattern for software work across several sessions is procedural in spirit, with a progress log and a feature checklist written at the end of one session so the next one opens by reading them.

The 4 labels matter less than the write policy behind them. Vendors sell storage, and storage is the easy half of this. Deciding what deserves to be written down, and what should quietly expire, is the decision that separates an agent which gets better over a month from one that fills up with stale facts nobody trusts any more.

How does an agent actually write and read a memory?

An agent writes a memory by calling a tool, and your own code performs the write. On the Claude API the memory tool is one entry in the request, and the model then sends file commands that your application runs against storage you control, which Anthropic's documentation describes as client side.

The entry below is the entire configuration for the tool, and there is no input schema for you to write.

{
  "tools": [
    { "type": "memory_20250818", "name": "memory" }
  ]
}

With that present, the API adds a memory protocol to the system prompt for you, and Claude opens every task by listing its memory directory before it does anything else. The tool works on all Claude 4 and later models.

The commands are the ones you would expect from a file system, view, create, str_replace, insert, delete and rename, all restricted to paths under /memories. A first call looks like the one below, and the reply your handler returns is a directory listing with file sizes.

{
  "type": "tool_use",
  "name": "memory",
  "input": { "command": "view", "path": "/memories" }
}

The path /memories is a prefix rather than a folder on your disk. Anthropic's docs are explicit that your handler maps it onto whatever real storage you have, a directory for each user or rows in a database. The model never touches the storage itself, so a memory that leaks from one customer to another is your bug and never the model's.

The second shape skips files entirely. Mem0 reads the conversation, pulls out the facts worth keeping, stores them as searchable memories and hands back the relevant ones at query time. Its README publishes recall scores the project measured on itself, which are worth reading as the vendor's own numbers rather than as an independent test.

Zep takes a third route, describing its store as a temporal knowledge graph, so a fact can be true for one period and superseded later. That matters for the question every naive store gets wrong, which is what to do when a saved fact stops being true. A flat file will happily tell your agent the client bills in euros a year after they moved to dollars.

In LangGraph the split is visible in the API itself. A checkpointer holds the thread, and a store holds anything that must outlive it, filed under a namespace the way a document sits inside a folder. LangGraph is open source, so there is no memory invoice, only whatever your database already costs you.

What does AI agent memory cost to run?

Memory is cheaper than replay, and the gap is arithmetic you can redo with published prices. At the $2 per million input tokens Anthropic charges for Claude Sonnet 5, a 50 turn conversation that resends its whole history each turn costs about $1.28 in input, while the same conversation carrying a small memory file and only the recent turns costs about $0.35.

The table below has the totals, assuming each turn of the conversation adds about 500 tokens. The first row grows with the square of the conversation length, because every turn resends everything before it, and that is the shape of the bill people are surprised by at the end of the month.

Prompt caching changes the numbers without changing the conclusion, as the last row shows. A cache hit costs a tenth of the base input price, so a replayed history gets genuinely cheap. The window still fills up, the cache still expires within the hour, and none of it is there when the user comes back the next day.

Anthropic published its own figures when it shipped the tool in September 2025. On an internal evaluation set for agentic search, combining the memory tool with context editing improved performance by 39% over the baseline, and the same pairing cut token consumption sharply in a long web search evaluation. Those are the vendor's own evaluations rather than an independent test, and they deserve to be read that way.

The service bill sits on top of the token bill as soon as you rent memory instead of hosting it, and the tools table further down carries each published price. A file on disk costs nothing at all, which is the honest baseline every paid option has to beat. Per model token rates sit side by side in our LLM API pricing comparison.

Which tools give an AI agent memory in 2026?

The memory tools worth knowing in 2026 split into 3 families, the file store you host yourself, the extraction service you rent, and the transcript your model provider keeps for you. The table below lists what each one saves, where it runs, and the price printed on its own pricing page.

If your agent runs on one machine for one person, the file store wins on cost and on how easy it is to debug, because you can open the memory file in an editor and read exactly what your agent believes about you. That single property is worth more than it sounds. Nobody debugs a vector index at midnight with any pleasure.

The extraction services earn their money once you have a lot of end users and no appetite for writing a retrieval layer yourself. Mem0 is open source under the Apache license, so the same code runs on your own hardware if the hosted plan stops making sense. Zep costs more and buys you the time dimension, which matters when your facts change often and quietly.

OpenAI sits in a different position again. Its Responses API stores your conversations for you and lets you chain turns by passing the previous response id, and you switch that off by sending store as false. That is persistence rather than memory, since nothing gets distilled, though for a support bot that only needs yesterday's thread it is the smallest amount of code that works.

Whichever family you pick, the memory lives behind a tool call, which is the same plumbing every other agent capability uses. If that layer is new to you, how to build an MCP server covers the mechanics, and our ranking of the best AI agent builder shows which platforms hand you a memory store without any of this work.

What happens when an AI agent's memory gets poisoned?

A poisoned memory is a false fact an attacker persuades an agent to save, and it survives every restart because it now lives in the store the agent trusts most. OWASP ranks it as ASI06, Memory and Context Poisoning, in its Top 10 for Agentic Applications.

The clearest public demonstration belongs to the researcher Johann Rehberger. A document carries hidden instructions inside it, the user asks Gemini to summarize the document, and the summary quietly carries a conditional, so the next time the user answers with yes or sure or no, Gemini calls its memory tool and saves what the document asked for. The facts he planted were that the user is 102 years old and believes the earth is flat.

Rehberger describes the result as persistence of false information in storage the model keeps reading. Google assessed the overall risk as low in both likelihood and impact, which is a fair reading for a consumer chatbot where the damage is a wrong biography. It reads differently in an agent that holds your calendar and a payment tool.

File based stores have a second hole, and Anthropic documents it in a warning box of its own. A path such as /memories/../../secrets.env reaches files outside the memory directory, so every handler has to resolve paths properly and refuse anything that escapes. That check belongs to you, since the tool is client side and the model only ever asks for the operation.

The defenses are dull and they work. Validate every path before a write, cap how large a memory file may grow, and delete anything that has not been read in months. Above all, read the store yourself once a week, because a memory system nobody audits will hold a false fact for exactly as long as it takes for that fact to matter.

There is a softer version of the same problem that has nothing to do with attackers. An agent that saves too eagerly ends up with contradictions, and a model reading 2 opposing facts will pick one without telling you which. A store you can read in a minute stays correct because you notice when it is wrong, while one you have never opened is running on trust alone.

Where should you start with AI agent memory?

Start with one markdown file the agent reads at the beginning of a session and rewrites at the end, because it costs nothing and answers the only question that matters early on, which is whether your agent has anything worth remembering at all. Most first agents do not, and finding that out for free is a good outcome.

Name the file after the job rather than after the tool. A file called clients.md tells the next reader what belongs in it, while a file called memory.json invites everything and therefore collects everything. Keep it short enough that a human still reads the whole thing, and let the agent rewrite it rather than append to it forever.

Move up a level when the file stops fitting. The honest signal is not a feeling, it is the moment the memory file no longer fits comfortably in the space you want to spend on it, or the moment you need to answer a question like what did we decide about this client in March. Retrieval earns its complexity there, and not a day earlier.

Before paying for a memory service, 3 questions decide it for you. Can you name what the agent should remember, in a sentence, without saying everything? Would you be comfortable reading the whole store out loud to the user it describes? And does anything break if the store is wiped tomorrow morning?

That third question sorts most cases on its own. An agent whose memory can be deleted without consequence does not have a memory problem, it has a prompting problem, and no vector database is going to fix that. For a single agent on one machine, which is where most builders actually are, the answer stays a file you can read. Everything on the tools table above exists for the day that stops being true, and the discipline of writing the file by hand is what tells you which of them you will need. If you want the same thinking applied to splitting work across several agents, Claude Code subagents is the companion piece.