# Agent Memory Techniques: 30 Runnable Notebooks for LLM Memory Patterns

> NirDiamant/Agent_Memory_Techniques is a collection of 30 Jupyter notebooks that walk through conversation buffers, vector stores, knowledge graphs, episodic and semantic memory, and integrations with MemGPT, Mem0, Letta, Zep and Graphiti. It is teaching material, not a library, and the distinction matters.

**NirDiamant/Agent_Memory_Techniques** — Agent memory for LLMs: 30 runnable Jupyter notebooks covering conversation buffers, vector stores, knowledge graphs, episodic and semantic memory, MemGPT, Mem0, Letta, Zep, Graphiti, LoCoMo benchmarks, and production patterns.

- Repository: https://github.com/NirDiamant/Agent_Memory_Techniques
- Website: https://diamantai.substack.com/
- Stars: 1,081 · Forks: 139
- Language: Jupyter Notebook
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nirdiamant-agent-memory-techniques

## What Agent Memory Techniques actually is, and who it is written for

This is a curriculum, not a framework. The repository holds 30 runnable Jupyter notebooks under all_techniques/, each one dedicated to a single memory pattern: conversation buffers, vector stores, knowledge graphs, working memory, episodic memory, semantic memory, and third-party systems including MemGPT, Mem0, Letta, Zep and Graphiti. There is also material on LoCoMo benchmarks and production memory patterns.

The audience is narrow and specific. If you have built an agent that forgets everything between turns and you are trying to choose between a rolling buffer and a vector store, the notebooks give you a working implementation of each so you can compare the mechanics side by side. The README points newcomers to 01 Conversation Buffer Memory as the entry point and offers Learning Paths for people who want a guided order rather than a flat list.

The framing throughout is educational. The README describes the collection as teaching every major agent memory technique, and the supporting material (a 464-page book, a paid course) reinforces that. Nothing in the repository layout suggests a runtime dependency you would add to a production service. That is the first thing to internalize: you read this to make a decision, then you implement the decision yourself or adopt the library the relevant notebook demonstrates.

## How the notebooks are organized and what each one contains

The repository is a flat set of numbered technique directories under all_techniques/, with shared code in utils/, sample data in data/, and prose in docs/. A tests/ directory exists at the top level, and the presence of nbformat in requirements.txt points to notebook validation rather than application testing.

The data flow inside a typical notebook follows a common shape. You construct a memory object, feed it a conversation, then query it and inspect what comes back. For buffer techniques the store is the message list itself. For vector techniques the messages are embedded, written to a local store, and retrieved by similarity. For graph techniques the extraction step produces entities and relations that are queried by traversal rather than by distance.

That progression is the real content. A buffer keeps everything and grows without bound. A vector store keeps everything but retrieves only the nearest neighbors, so relevance replaces recency. A knowledge graph keeps only what an extraction step judged worth storing, which means the quality of your entity and relation extraction sets the ceiling on what the agent can recall. Each notebook makes one of those trade-offs concrete.

The third-party notebooks (Mem0, Letta, Zep, Graphiti) are different in kind. They demonstrate an external system's API rather than a pattern you implement, so what you learn is the integration surface, not the internals. The .env.example reserves optional keys for ZEP_API_KEY, MEM0_API_KEY, PINECONE_API_KEY and Neo4j connection settings, which tells you those notebooks expect a running service or a hosted account.

## Installing the environment and running your first notebook

The repository does not ship a package, so setup means cloning it and installing requirements.txt into an environment with Python 3.10 or newer, which the README badge states as the minimum.

```bash
git clone https://github.com/NirDiamant/Agent_Memory_Techniques.git
cd Agent_Memory_Techniques
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```

The install pulls a substantial dependency set: anthropic, openai, langchain, langchain-community, langchain-openai, langchain-anthropic, chromadb, faiss-cpu, sentence-transformers, python-dotenv, tiktoken, pydantic, ipykernel, nbformat, pandas, numpy, mem0ai, letta-client and networkx. Expect the embedding and vector dependencies to dominate download time.

Next, create your environment file. The .env.example marks at least one LLM API key as required and lists the rest as optional, scoped to specific technique notebooks.

```bash
cp .env.example .env
```

```bash
# Required: At least one LLM API key
OPENAI_API_KEY=your_openai_api_key_here
ANTHROPIC_API_KEY=your_anthropic_api_key_here
```

Fill in whichever key matches the provider you intend to use, then launch Jupyter and open the first technique.

```bash
jupyter notebook all_techniques/01_conversation_buffer_memory/
```

You should see the notebook load with its cells unexecuted. Run them in order. The buffer example appends messages to a list and passes the list back to the model, so the visible output is a reply that reflects earlier turns. If authentication fails, the error surfaces on the first cell that calls the model, not at import time.

## Where this repository stops being the right tool

There is no memory class to import. If you were hoping to add a line to requirements.txt and call a Memory object in your service, this is the wrong repository. Every technique lives inside a notebook, which means the code is written for reading and executing interactively, not for being vendored into an application. You will be copying and adapting.

The dependency set is another boundary. Installing all of requirements.txt brings in Chroma, FAISS, sentence-transformers and two provider SDKs at once. That is fine on a laptop for study. It is not a dependency graph you would want to inherit in a service that needs one retrieval path, and the notebooks do not separate their requirements per technique, so you cannot install only what notebook 07 needs.

Several notebooks depend on external services. The optional keys in .env.example point at Pinecone, Zep, Mem0 and Neo4j. Those demonstrations will not run from a clean clone without accounts or a local Neo4j instance at bolt://localhost:7687. The README does not document offline fallbacks for them, and it does not document rollback or teardown steps for the hosted services once you have written data into them.

Finally, the third-party notebooks are snapshots of other projects' APIs. Mem0, Letta, Zep and Graphiti each change on their own schedule. The repository's last push was on 2026-09-04 and the only release is v1.0.0 from 2026-05-30, so a notebook written against an earlier client version may need adjustment before it runs.

## Choosing between a vector store and a knowledge graph notebook

The most useful comparison in the collection is the one between the vector-store techniques and the knowledge-graph techniques, because they answer different questions about the same conversation.

A vector store answers "what past text is semantically close to this query?" You embed messages, write them to Chroma or FAISS, and retrieve the top matches. The notebook approach is straightforward and the failure mode is familiar: retrieval returns plausible text that may be stale or contradictory, and the model has no way to tell which of two conflicting memories is current. Recency has to be encoded separately, usually in metadata.

A knowledge graph answers "what entities and relations do I know about?" The pipeline extracts entities and relationships, stores them in a graph (networkx appears in requirements.txt, and the Neo4j variables in .env.example suggest a database-backed variant), and queries by traversal. This gives you structure and lets you update a fact in place rather than appending a contradicting memory. The cost moves upstream: extraction quality determines everything, and an extraction step that misses a relation silently loses information with no retrieval error to alert you.

The practical reading is that these are complements, not alternatives. A vector store handles the long tail of conversational context; a graph handles the small set of facts that must stay consistent. The notebooks let you see both mechanisms at the level of code before you decide which one your agent actually needs.

## Maintenance, licensing and the cost of keeping up

The repository is not archived and the last push was on 2026-09-04, which is recent. The single release, v1.0.0, dates to 2026-05-30. There is a ROADMAP.md at the top level and a .pre-commit-config.yaml, so contributions are expected to pass linting before merge, and the README links a CONTRIBUTING.md under .github/.

Upgrade cost is concentrated in the third-party notebooks. Because requirements.txt pins nothing, a fresh pip install resolves to whatever the current versions of mem0ai, letta-client, langchain and the rest happen to be. A notebook that worked against one client version can break against the next without any change in this repository. If you depend on a specific notebook, pin the versions yourself in a separate environment file.

The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant. It also requires that you preserve copyright and licence notices in redistributed copies. This is a description of the licence text, not legal advice; check the LICENSE file and your own counsel if you plan to redistribute adapted notebook code inside a product. Note that the README's commercial material (the course and the book) is separate from the repository and carries its own terms.

## Conclusion

Adopt this repository if you are designing a memory layer and need to compare patterns before committing to one, or if you are onboarding engineers who have never built retrieval into an agent. Skip it if you want a drop-in memory service: nothing here is packaged for import, and each notebook is a standalone demonstration with its own dependencies. Before starting, check the .env.example keys against the notebooks you intend to run, confirm your Python version is 3.10 or newer, and read the ROADMAP.md to see which techniques are planned rather than present.

## FAQ

### What are the four types of agentic memory covered in Agent Memory Techniques?

The repository's topics and notebook set distinguish working memory, episodic memory, semantic memory and conversation buffer memory, alongside vector-store and knowledge-graph implementations of each. Each type has its own numbered directory under all_techniques/.

### How many memory techniques does Agent Memory Techniques include?

The README states that the repository contains 30 runnable Jupyter notebooks, covering conversation buffers, vector stores, knowledge graphs, episodic and semantic memory, working memory, MemGPT, Mem0, Letta, Zep, Graphiti, LoCoMo benchmarks and production memory patterns.

### How do I use memory in an agent with Agent Memory Techniques?

Clone the repository, install requirements.txt into a Python 3.10+ environment, copy .env.example to .env with at least one LLM API key, then open a notebook under all_techniques/ and run its cells in order. The README recommends starting with 01 Conversation Buffer Memory.

## Sources

- [License: Apache-2.0](https://github.com/NirDiamant/Agent_Memory_Techniques/blob/main/LICENSE)
- [NirDiamant/Agent_Memory_Techniques on GitHub](https://github.com/NirDiamant/Agent_Memory_Techniques)
- [Project website](https://diamantai.substack.com/)
- [README](https://github.com/NirDiamant/Agent_Memory_Techniques/blob/main/README.md)
- [Releases](https://github.com/NirDiamant/Agent_Memory_Techniques/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nirdiamant-agent-memory-techniques