Skip to content
Reviewed by Bipeen Sinha Oct 03, 2026

Home › Guides › AI Agent Memory

Tech Explained · 2026

What Is AI Agent Memory in 2026? The 4 Memory Types, Memory vs RAG and 6 Steps to Ship It

AI agent memory is the write path that lets an agent keep what it learned after a session ends: facts about a user, past attempts, and working procedures stored outside the context window and retrieved on later turns. Anthropic's own 100-turn search evaluation reports 84% fewer tokens when memory is paired with context editing.

3 October 2026·11 min read·By the 360 Digital Transformation Editorial Team
Key takeaways
  • Memory is a write path, not a bigger index. RAG reads a corpus somebody else curated. Memory decides, after every turn, what to store, what to update and what to throw away.
  • Four types do the real work. Working, episodic, semantic and procedural. Most teams ship semantic first and skip episodic, the one that stops the agent repeating yesterday's failed approach.
  • The retrieval quota bites long before storage does. Mem0's pricing page as of October 2026 lists a free Hobby tier with 10K memories but only 1K retrieval calls a month, roughly 33 reads a day.
  • Self-hosting is genuinely free. Letta's framework and self-hosted server are Apache 2.0 licensed, and LangGraph's cross-thread store ships inside the framework at no cost.
  • Memory is an attack surface. The OWASP Top 10 for Agentic Applications (2026) lists Memory and Context Poisoning as ASI06, and unlike a prompt injection a poisoned write survives the session.

Your agent nailed the demo. It answered the claims question, called the right tool, and sounded like it understood the account. Then the user opened a fresh thread the next morning and it asked for the policy number again, the one it had been handed twice the day before. Nothing crashed. The traces are clean. The agent simply has no idea who it is talking to, because every thread starts from zero.

What Is AI Agent Memory, and What It Is Not

AI agent memory is the machinery that survives the end of a conversation. A context window is rented space: whatever sits in it at the moment of the call shapes the answer, then it is gone. Memory is owned space. Your system looked at a finished turn, decided "this assessor handles only Maharashtra motor claims" was worth keeping, wrote it somewhere durable, and will pull it back three weeks from now without being asked.

The distinction that matters in code is read path versus write path. Retrieval gives you a read path, and you probably already have one. Memory forces a write path that is just as considered: an extraction step that proposes candidate facts, a reconciliation step that decides whether a new fact adds to, replaces or expires an old one, and a scoping rule that keeps one user's memories out of another user's prompt.

Reconciliation is where teams underestimate the work. "The user prefers email" and "the user asked to be called instead" are not two facts. They are one fact and a correction, and an agent that stores both will retrieve both and flip behaviour depending on which ranks higher that day.

The record itself is smaller than people expect. In LangGraph a memory is a JSON document filed under a namespace and a key, so one fact is about this much: namespace ("claims_agent", "assessor_417"), key formatting_pref, value {"text": "figures in lakhs", "source": "user_utterance", "written_at": "2026-09-14"}. Three pieces of metadata carry most of the weight: where the fact came from, when it was written, and what it supersedes. Vendors wrap this in an API, but the thing you actually need is that plain, and if you cannot name those three fields for your own agent you are not ready to pick a vendor yet.

The memory loop in one turn

The top row is what every RAG app already does. The bottom half, extract and reconcile, is the part that makes it memory.

The read and write loop of an AI agent memory system A user turn triggers a scoped retrieval from the long-term memory store, the retrieved facts are assembled into the prompt, the model and tools run, then an extraction step proposes candidate facts which a reconciliation step adds, updates or expires before writing them back to the store. User turn new thread Retrieve scope by user_id Assemble context facts + history + tools LLM + tools answer, act Extract candidates what looks durable? Reconcile add / update / expire Long-term memory store survives thread and session turn top-k 1 call trace facts write read

Architecture generalised from the LangGraph checkpointer and store docs and the Anthropic memory tool documentation, checked 3 October 2026.

The 4 Types of AI Agent Memory Engineers Actually Build

The naming comes from cognitive science and was formalised for language agents in the CoALA paper, which mapped semantic, episodic and procedural memory onto agent architectures. Skip the theory if you like, but learn the buckets: the types of AI agent memory each fail in a recognisably different way, and the fix for one does nothing for another.

Working memory: the current thread

Message history for one conversation, plus scratchpad notes and tool results. In LangGraph this is the checkpointer keyed on thread_id, and the LangChain docs are explicit that checkpoints reset at the thread boundary. Cheap to build, and not memory in the sense anyone means when they complain the agent forgot them.

Semantic memory: durable facts

"This assessor only handles motor claims." "Finance wants figures in lakhs, not millions." Flat, timeless statements about users and entities. Every vendor ships this first because it is the easiest to extract and the easiest to demo.

Episodic memory: what happened last time

The agent ran a SQL query, it timed out, it retried with a date filter and that worked. Store the episode and the agent stops rediscovering the same workaround. Skip it and your agent stays competent but never improves. Highest payoff, lowest adoption, because writing a useful episode summary is harder than extracting a fact.

Procedural memory: how the work is done

Rules, playbooks and refined instructions. This lives in the system prompt or in files rather than a database, which is what Anthropic's memory tool does: it hands the model a directory it can read and write, so the agent edits its own notes instead of querying a store. Teams building agent architectures on Claude practise that pattern end to end in 360DT's CCAR-F architect prep course.

Memory type What it holds Typical home Lifetime How it fails
Working Message history, scratchpad, tool output Checkpointer keyed on thread_id One thread Context exhaustion on long runs
Semantic Stable facts about users and entities Vector or key-value store, namespaced per user Until corrected Stale facts outrank current ones
Episodic Past attempts, outcomes, errors Append-only event log plus summaries Weeks to months Never written, so failures repeat
Procedural Playbooks, refined instructions Files or system prompt, model-editable Until a human reviews it Agent rewrites its own rules unsupervised
Entity profile One row per customer, account or policy Relational table, joined at retrieval Life of the record Treated as memory when it is just a database read

That last row deserves a pause. Much of what gets sold as agent memory is a SELECT against a table you already own. If a fact has a system of record, read it from the system of record. Memory is for the facts with no owner. Getting those tables query-ready is ordinary data engineering, taught live in a Microsoft Fabric data engineering program.

AI Agent Memory vs RAG: Why a Retrieval Index Is Not Memory

Both put text into a prompt by similarity search, which is why they get conflated. The real agent memory vs RAG difference is who writes, and how often. A RAG index is built from documents somebody else authored and changes when a pipeline runs. A memory store is written by the agent itself, every turn, about one specific user, and it has to handle contradiction.

Put plainly: RAG makes the agent answer better, memory makes it behave consistently. You can have flawless retrieval over your entire policy library and still ship an agent that reintroduces itself every morning. If your pilot is a RAG app today, the memory layer is the next build, and that progression is the spine of the Generative AI Developer course.

Three numbers worth knowing before you build

All three are figures published by the vendor or standards body named, not estimates.

84%
Token reduction Anthropic reports on its 100-turn web search evaluation with context editing enabled
1,000
Retrieval calls a month on Mem0's free Hobby tier, against 10,000 memories of storage
ASI06
Rank of Memory and Context Poisoning in the OWASP Top 10 for Agentic Applications 2026

Sources: Anthropic engineering documentation on context editing and the memory tool, the Mem0 pricing page, and the OWASP Top 10 for Agentic Applications (2026). Checked 3 October 2026.

If the retrieval half of this is still fuzzy, start with the mechanics. Also read: Retrieval Augmented Generation Explained in 2026: How RAG Actually Works, Step by Step.

Mem0 vs Zep vs Letta vs LangGraph: What a Memory Layer Costs in 2026

Four options cover most real decisions. Two managed services, one framework with a commercial cloud, and one that is already in your dependency tree if you use LangGraph.

Criterion Mem0 Zep Letta LangGraph store
What it is Hosted memory API plus OSS SDK Hosted memory service on the Graphiti engine Stateful agent framework, formerly MemGPT Persistence layer inside LangGraph
Memory model Extracted facts, embedding retrieval Temporal knowledge graph that records when a fact was true Self-editing memory blocks, OS-style paging JSON documents under a namespace and key
Free tier or licence Hobby: 10K memories, 1K retrieval calls a month Free developer tier, graph features gated Framework and self-hosted server, Apache 2.0, no usage caps Included with the framework, you supply the database
Paid entry point Starter at $19 a month, 50K memories and 5K retrieval calls Usage-based cloud pricing Letta Cloud Pro at $20 a month for up to 20 stateful agents No licence cost, you pay for Postgres
Graph or temporal support Graph memory on the Pro plan at $249 a month Core design, bitemporal by default Not graph-native Build it yourself
Self-host Yes, OSS edition Graphiti engine is open source Yes, fully, and free Always self-hosted
Best fit Fastest route from zero to working semantic memory Agents where "what was true in July" is a real question Long-lived agents you want to own outright Teams already on LangGraph who want no new vendor
Main catch Retrieval quota, not storage, is the ceiling Graph writes add latency and cost per turn You own the ops, including backups and upgrades Extraction and reconciliation are yours to write

One honest note on benchmarks. LOCOMO is the number everyone quotes and it is openly contested: Zep originally published 84%, Mem0 recalculated it at 58.44% alleging category errors, and Zep then counter-claimed 75.14%. On other benchmarks Zep reports 94.8% on DMR and 71.2% on LongMemEval with GPT-4o. Read that spread as a warning. Nobody here has a number you can procure against, so run your own 50-conversation evaluation on your own data first. Building that harness is a core skill in its own right, covered against the AI-300 objectives in 360DT's MLOps engineer course.

A fifth option belongs here even though it is not a row in the table, because it is not a store at all. Anthropic's memory tool, shipped as memory_20250818, hands Claude a directory of files it reads and writes itself, and it pairs with server-side context editing that clears the oldest tool calls once input tokens cross a trigger threshold. Anthropic reports a 39% improvement over baseline on agentic search tasks when memory and context editing run together. If your agent is Claude-based and your memories read more like notes than like rows, try that before you add a database to the stack.

My default for a first build: LangGraph's store with Postgres behind it and a hand-written extraction prompt. You will write about 200 lines you could have rented. In exchange you will know exactly which facts your agent stores on day one, which is what matters when it starts behaving oddly in week six. Move to Mem0 or Zep when reconciliation logic, not storage, becomes the bottleneck.

A Worked Scenario: 22,000 Agent Turns a Month at an Indian Insurer

This is an illustrative scenario, not a real customer. Take a two-person AI team at a mid-size health insurer in Pune, building a claims-query agent for 40 internal assessors who each ask it roughly 25 questions a working day. Twenty-two working days gives 22,000 turns a month, and because the agent needs the assessor's region, claim types and formatting preference before it can answer anything, it reads memory on essentially every turn. Retrieval count equals turn count.

Now price it. Mem0's free Hobby tier allows 1,000 retrieval calls a month, so it expires on the second working day. Starter at $19 a month allows 5,000, about a week. Pro at $249 a month with 50,000 calls is the first tier that fits, roughly Rs 22,000 a month before a single token of model spend. Self-hosting on managed Postgres with pgvector lands in the low thousands of rupees, and the cost moves to the two engineers' time.

Self-hosting wins here, and not on price. It wins because claim notes are regulated personal data, and a two-person team can answer "where does this fact physically live" much faster when the answer is "our own database in the Mumbai region". The managed service becomes right the moment that team grows to eight and the bottleneck is engineering hours rather than rupees. Sizing and running that database is cloud work, covered live in the AWS Solutions Architect and DevOps course.

What Usually Goes Wrong With LLM Long-Term Memory

Nobody tells you this until you have shipped one. The failure mode of LLM long-term memory is almost never "it forgot". It is "it remembered something it should not have, and now it is confidently wrong in a way you cannot reproduce". You will spend an afternoon on a nonsense answer, find a six-week-old fact that was true once, and realise you built a system with no way to delete anything.

Four failures that show up in week six, not week one

Each one has a cheap fix if you design for it before launch and an expensive one afterwards.

1

Stale facts win the ranking

A superseded preference sits next to its replacement and scores higher on similarity, so the agent flips behaviour between sessions with no code change. Fix: store a timestamp and a supersedes pointer on every write, and filter before you rank.

Reconciliation
2

Memory bloat eats the context

Six months in, retrieval returns 40 facts of which 3 matter. Token spend climbs while answer quality drops. Fix: cap retrieved facts hard, and expire anything not read in 90 days.

Cost control
3

Cross-user leakage

One missing namespace filter and assessor A's notes land in assessor B's prompt. This is the one that becomes a compliance incident rather than a bug ticket. Fix: scope at the store layer, never in the prompt, and write a test that asserts it.

Privacy
4

The agent remembers its own hallucination

The model invents a detail, extraction treats the transcript as ground truth, and the invention becomes permanent. Fix: never extract memories from model output alone. Require a user utterance or a tool result as the source.

Provenance

Failure patterns drawn from the OWASP Top 10 for Agentic Applications (2026) guidance on memory writes and from published memory framework documentation, checked 3 October 2026.

The one you cannot retrofit

Build the delete path on day one. Not a soft flag: an actual "forget everything about this user" operation that clears the store, the embeddings and any derived summaries. You will need it for a DPDP Act deletion request, for a poisoned entry, and for the ordinary case of an employee leaving. Teams that add it in month eight discover their summaries contain facts whose source rows are already gone.

Memory Poisoning: The Attack That Waits

The OWASP Top 10 for Agentic Applications (2026) lists Memory and Context Poisoning as ASI06, and it earned its own entry on timing. A prompt injection ends when the session ends. A poisoned memory write is committed to storage, so the attacker acts once and the agent misbehaves for every user, on every future turn, until somebody finds the row.

The structural weakness OWASP points at is the missing validation step between the model deciding to store something and the store accepting it. Most implementations have no write-path check at all, which means anything the model is willing to extract is something you have agreed to trust forever.

Four controls, in the order I would add them: validate and scan on write rather than on read; segment the store by user, task and domain so one poisoned entry cannot travel; attach provenance to every fact and decay low-trust sources; keep snapshots so you can roll back to a known-good point. Notice that none of these are model-level defences, because once a poisoned fact is persisted, prompt-level guardrails are mostly decoration. The tool-use and safety domains behind this are examined in the CCDV-F developer prep course, with the wider exam map in the full certifications overview. Also read: What Is Prompt Injection in 2026? How Indirect Attacks Work, Prompt Injection vs Jailbreaking and 7 Defences That Hold.

How to Ship AI Agent Memory in 6 Steps

Do not start by choosing a vendor. Start by writing down, on one page, the kinds of fact your agent is allowed to remember. Everything downstream gets easier once that list exists, and most teams find it has three items, not fifty.

A six-week path from stateless agent to working memory

Weekend-pace plan for an engineer who already has a working agent and roughly 8 hours a week.

Wk 1

Write the memory schema

List the fact types, their fields and who owns each one. Deliverable: a one-page schema where every fact type has a source, a scope and an expiry rule.

Wk 2

Get persistence working at all

Add a checkpointer so a thread survives a restart, then a store keyed on user_id. Deliverable: the agent recalls a fact from a previous thread.

Wk 3

Build the extraction step

A cheap separate model call that reads the finished turn and proposes candidate facts as structured output. Deliverable: candidates logged, not yet written.

Wk 4

Build reconciliation and delete

Decide add, update or expire against what is stored, and ship the forget-this-user operation the same week. Deliverable: a contradiction test that passes.

Wk 5

Evaluate on 50 real conversations

Score recall of facts that should persist, and precision against facts that should not. Deliverable: a baseline you can regress against.

Wk 6

Instrument, scope, and harden

Trace every read and write, assert namespace isolation, add provenance. Deliverable: a dashboard showing memory reads per turn and store growth per day.

Sequence built from the LangGraph persistence documentation and the OWASP ASI06 mitigation list, checked 3 October 2026.

Week 6 is the one people cut, and the one that saves them later: you cannot debug a memory system you cannot see. For the tracing patterns, Also read: What Is AI Agent Observability in 2026. To build the extraction, reconciliation and evaluation steps with a trainer reading your code, that is the back half of 360DT's live AI Engineer course.

Is AI Agent Memory Worth Building in 2026?

Most agents should not have memory. If yours answers one question and exits, a memory layer buys you a write path to maintain, a privacy surface to defend and a monthly bill, in return for a feature nobody asked for. The honest test is whether a user ever opens a second session about the same subject. If they do not, spend the time on retrieval quality instead.

The case flips hard for three shapes of agent: internal tools used daily by the same small group, long multi-step tasks where repeating a failed approach is expensive, and anything customer-facing where being asked the same detail twice reads as incompetence. Those cover most of what Indian enterprises are piloting right now, which is why this moved from research curiosity to a line in job descriptions inside about a year.

Say the rest plainly too: the vendor category is young and noisy. Pricing shifted this year, the headline benchmark is disputed, and the free tiers are sized for demos. None of that is a reason to wait. It is a reason to own the schema and the extraction logic yourself and keep storage swappable.

In your position I would do exactly that this month: write the one-page fact schema, wire LangGraph's store to a Postgres instance you control, and keep the delete path in the first commit rather than the fortieth. Learn it in that order and the vendor question answers itself later, cheaply. If you would rather build it with a trainer reading your code each weekend instead of alone, the extraction, reconciliation and evaluation work is the back half of the AI Engineer course, and that is the sensible next step.

Live course

Build the memory, retrieval and evaluation layers of a real agent, live with a trainer

Live online·Sat–Sun, 8–11 PM IST·100+ hrs·Rs 24,999

The AI Engineer course teaches you to build agents that plan, use tools and act, certified on both Microsoft Copilot Studio and Claude Code, the two stacks real job postings are naming. You write the RAG and agent code yourself across 16 weeks, not in a sandbox.

Explore the course
AI Engineer Course: Generative AI, RAG & AI Agents (Microsoft + Claude Certified)

Frequently asked questions

What is AI agent memory in simple terms?

AI agent memory is storage the agent writes to itself so useful information survives the end of a conversation. When a turn finishes, an extraction step decides which facts, past attempts or preferences are worth keeping, and a later session pulls them back into the prompt. Without it, every new thread starts from nothing.

What is the difference between agent memory and RAG?

RAG is read-only retrieval over a corpus somebody else authored, and it changes only when an indexing pipeline runs. Agent memory is written by the agent on every turn, scoped to a single user, and must handle contradiction and expiry. RAG improves the answer; memory improves the behaviour across sessions.

Is Mem0 free to use?

There is a free Hobby tier. The Mem0 pricing page as of October 2026 lists 10,000 memories and 1,000 retrieval calls a month on it, with Starter at $19 and Pro at $249 a month. Because a production agent reads memory on nearly every turn, the retrieval allowance runs out long before storage does. Check your expected turn volume against that 1,000 figure, not the memory count.

Which agent memory framework should a beginner start with?

If you already use LangGraph, use its built-in store with Postgres behind it and write your own extraction prompt. No licence fee, and you learn what your agent stores. Move to a managed layer such as Mem0 or Zep once reconciliation logic rather than storage is the bottleneck.

How do you stop an agent from remembering the wrong thing?

Three rules cover most of it. Only extract facts whose source is a user utterance or a tool result, never the model's own output. Store a timestamp and a supersedes pointer so corrections beat older entries. Expire anything that has not been read in roughly 90 days.

Can agent memory leak one user's data to another?

Yes, and it is the most common serious bug in this area. A single missing namespace filter puts one user's stored facts into another user's prompt. Enforce scoping at the store layer rather than in prompt instructions, and write an automated test that asserts a query for user A never returns user B's rows.

How long does it take to learn to build agent memory?

If you can already build a working agent with tool calls, roughly six weeks at 8 hours a week gets you from stateless to a memory layer with extraction, reconciliation, a delete path and an evaluation baseline. Starting from no agent experience, plan for a structured programme instead: 360DT's AI Engineer course runs 100+ hours of live sessions over 16 weeks.

About this guide. 360 Digital Transformation is an Anthropic Partner. Other certification bodies, vendors and employers named here are not affiliated with us. Product features and pricing change often; figures cited were checked on 3 October 2026.

Learn it live with 360 Digital Transformation

Turn this guide into a skill employers can see

Live weekend cohort★ 4.9 (2,300+ reviews)EMI available

AI Engineer Course: Generative AI, RAG & AI Agents (Microsoft + Claude Certified)

Rs. 27,999Rs. 37,239 Save 24%

Tools and platforms you work with

  • Python
  • Claude API
  • FAISS
  • ChromaDB
  • LangChain
  • LangGraph
  • CrewAI
  • AutoGen (AG2)
Add bonus modules
See the syllabus and batch dates

Other live courses on this career path