# Long-Term Agentic Memory with LangGraph: a short course on three types of memory that doubles as a way to diagnose agents

> Harrison Chase teaches how to build three types of memory into an email assistant. Take that division to a customer and you will have the right questions when they have to correct an agent for the third time.

Original: https://fdetimes.net/en/books-courses/long-term-agentic-memory-langgraph-course/

In 1 hour 24 minutes, Harrison Chase, co-founder and CEO of LangChain, walks learners through a very ordinary exercise: build an email assistant, then give it three types of memory, one at a time. For an FDE, the greatest value lies not in the library but in the three-way split itself. When an agent repeats a mistake, it helps you see where the fix belongs.

[Long-Term Agentic Memory with LangGraph](https://www.deeplearning.ai/courses/long-term-agentic-memory-with-langgraph) is an intermediate short course on DeepLearning.AI, made with LangChain.

Picture week three of a deployment: the customer corrects the agent on the same error for the third time and asks why it does not remember. The course helps you name the problem correctly and gives you a ready implementation pattern to answer with, instead of patching another line into the prompt.

## One email assistant, three upgrades

The project running through the course is an email assistant. The lessons follow a sequence: the baseline, then semantic, then episodic, then procedural.

Because each lesson builds on the last, you see where each type of memory attaches within the same agent, rather than learning three separate concepts. The entry requirements are also light: familiarity with Python and a basic understanding of prompting and LLM application development.

## A recurring error: which type of memory is the agent missing?

The course does not teach error diagnosis, but its three-way split works very well for it. The [LangMem conceptual guide](https://langchain-ai.github.io/langmem/concepts/conceptual_guide/) has definitions good enough to start with.

Semantic memory stores facts that ground the agent's answers; the course's example is important birthdays for a calendar agent. Episodic memory keeps successful interactions as examples for later ones. Procedural memory sets out how the agent should behave and respond.

These three definitions are enough to separate a vague complaint into three different fixes. Take a hypothetical example, the support inbox of a logistics company:

| Type | The customer's complaint | What to store |
|---|---|---|
| Semantic | "It still quotes the wrong turnaround commitment for this client" | The contractual commitment for each client |
| Episodic | "It handled this kind of email correctly last time, so why did it misclassify it now?" | That email and its correct classification |
| Procedural | "We already told it refunds must go to an approver" | The approver routing rule in the agent's instructions |

**Key point:** Agent repeating an old mistake? Before fixing it, ask which type of memory it is missing.

So the first job at a customer is not choosing a storage tool. Gather the times users have corrected the agent, label each one using the table above, then start with the type that appears most often.

## Few-shot examples and system prompts are memory too

In the course, episodic memory is few-shot examples at the triage step, and procedural memory is a system prompt refined through feedback. Technically, you already know most of both; the difference is that they are built up gradually from what the agent experiences.

In a [blog post on agent memory](https://www.langchain.com/blog/memory-for-agents), Chase also writes that episodic memory is implemented in practice through few-shot examples, and that some agents update their own system prompts.

But once an agent's behaviour changes in response to feedback, you need a fixed measure. Suppose that on 100 labelled emails the baseline misclassifies 15. After the prompt is tuned, 6 of the wrong ones are corrected, but 4 that were right now break.

Counting both directions, 13 emails are wrong, a reduction of just 2, while the customer may easily see only the 6 newly fixed cases. The 4 broken cases will come back as new complaints if nobody measures them.

Before switching on an optimisation mechanism at a customer, have this test set ready and save every version of the prompt so that you can roll back.

## Who should take it, and in what order

The course best suits engineers who have already built a working agent or are about to take one to a customer. If you have never written an LLM application, learn the basics first, because the course treats them as assumed knowledge.

The sensible order is to follow the lessons in sequence, not to jump straight to the procedural part. Then read the LangMem conceptual guide to compare its definition of each type of memory, and redo the exercise with data other than email. The course page says it was updated on 17 July 2026, so check your work against the library's current documentation.

## Should one person's memory spread to the whole team?

Remember the exercise's limit: it revolves around a single email assistant. In a company, you also have to settle who owns the memory, whether one employee's preferences should spread to colleagues, and who may view and delete it.

The [LangGraph documentation](https://docs.langchain.com/oss/python/concepts/memory.md) describes a structure you can use to discuss this: each memory sits in a custom namespace, like a folder, and has its own key, like a file name.

Before go-live, draw the namespaces by employee and by team with the customer, because the drawing forces both sides to answer those questions.

## On your CV, list error counts rather than the course name

When you put this project on your CV, do not just name the course. State which type of memory you added, how many samples you measured it on and how the number of errors changed.

When a job description mentions agents, ask the interviewer how they handle long-term memory. The answer often tells you whether their product has run for a long time at customers or has stopped at the demo stage.

Customers will not ask which memory library your agent uses. They care about one thing: whether the error fixed last week has come back.

**Try this week:**

- Take the 10 most recent times users corrected your agent, label each one semantic, episodic or procedural, and see which type dominates.
- Create a set of 100 labelled inputs and record the error count of the current agent version, before adding any memory.
- Once you finish the course, replace the email data with a public or self-made ticket stream, then write one page recording the error count before and after adding each type of memory.

## Sources

- [Introduction - Long-Term Agentic Memory with LangGraph (DeepLearning.AI)](https://learn.deeplearning.ai/courses/long-term-agentic-memory-with-langgraph/lesson/ovv0p/introduction)

- [Long-Term Agentic Memory with LangGraph - DeepLearning.AI short course](https://www.deeplearning.ai/short-courses/long-term-agentic-memory-with-langgraph/)

- [Long-Term Agentic Memory With LangGraph - DeepLearning.AI](https://www.deeplearning.ai/courses/long-term-agentic-memory-with-langgraph)

- [LangMem Conceptual Guide](https://langchain-ai.github.io/langmem/concepts/conceptual_guide/)

- [Memory for agents (Harrison Chase, LangChain blog)](https://www.langchain.com/blog/memory-for-agents)

- [Memory overview (LangChain docs)](https://docs.langchain.com/oss/python/concepts/memory.md)