How to build agent memory with Redis Agent Memory and LangGraph

TL;DR: In this tutorial, you will build a LangGraph travel agent that uses Redis Agent Memory for both short-term and long-term memory. Short-term session memory keeps the active conversation coherent, while long-term memory stores durable user facts and preferences across sessions.

Note: This tutorial uses the code from the following GitHub repository:

https://github.com/redis-developer/redis-agent-memory-with-langgraph-demo

#Memory model comparison

#Prerequisites

• Docker and Docker Compose.
• An OpenAI API key.
• A Redis Agent Memory data-plane URL, store ID, and API key.
• Redis Insight for optional inspection.
• Basic familiarity with Python, FastAPI, and LangGraph.

Note: The demo does not start a local Redis instance or deploy Redis Agent Memory. It expects an existing Redis Agent Memory service endpoint.

#Setup

#How the demo works

1. Nginx serves the static frontend.
2. FastAPI handles /api/* routes.
3. The backend creates a Redis Agent Memory client per request, then calls RedisAgentMemoryService.run_turn() to run one LangGraph workflow.

#Why Redis Agent Memory?

#Session-scoped memory

#Durable long-term memory

#App-level control

• Which session events go into the prompt.
• Which long-term memories match the current user request.
• Which extracted facts deserve durable storage.
• Which owner and namespace isolate memory for this user and app.

#Trade-offs to keep in mind

• Redis Agent Memory must be reachable from the backend.
• LLM-based extraction can vary by model and phrasing.
• Bad owner IDs or namespaces can mix users' memories.
• Long-term memory should store durable preferences, not every conversational detail.

#1. Configure the FastAPI app and memory client

#How it works

#Data flow

1. load_config() reads .env and environment variables.
2. get_service() creates and caches RedisAgentMemoryService.
3. agent_memory_client() builds the Redis Agent Memory client from the cached config.
4. FastAPI routes use the client inside a context manager.

#Code walkthrough

1. Required variables fail fast. Missing Redis Agent Memory credentials raise a runtime error during config loading.
2. The service is cached. FastAPI creates one service with stable config instead of rebuilding the LLM wrappers for every route.
3. The client is request-scoped. Each route opens the Redis Agent Memory client with with agent_memory_client(service).
4. Readiness checks the dependency. /api/ready verifies Redis Agent Memory availability before the frontend treats the backend as ready.

#Trade-offs

• Simple request-scoped client usage is easy to reason about.
• Readiness depends on external Redis Agent Memory availability.

#2. Retrieve short-term memory for the current session

#How it works

#Redis Agent Memory mapping

#Code walkthrough

1. STM is session-scoped. The lookup uses only the current session_id.
2. The frontend does not resend history. Redis Agent Memory stores prior events for the session.
3. Deletes stay scoped. Deleting session memory clears only this session, not durable long-term memory.
4. Prompt size stays bounded. SESSION_CONTEXT_LIMIT = 12 keeps the latest events instead of injecting the whole session.

#Trade-offs

• Simple truncation is predictable, but it is less nuanced than summarization.
• Session memory should not become the storage location for every durable fact.

#3. Search long-term memory before the LLM call

#How it works

#Redis Agent Memory mapping

#Code walkthrough

1. The query comes from the current turn. The demo searches with the user's latest message.
2. Owner ID separates users. Use a stable per-user value in real apps.
3. Namespace separates apps and environments. This prevents unrelated memories from leaking into the demo.
4. Recall is relevance-based. The app asks for up to five relevant memories, not a full dump of all memories.
5. Redis Agent Memory hides plumbing. The app calls memory APIs instead of direct Redis vector search code.

#Trade-offs

• Relevant recall depends on memory quality and query phrasing.
• Shared demo defaults can pollute results. Use stable owner IDs and separate namespaces in production.

#4. Inject memory into a LangGraph agent turn

#How it works

#Data flow

#Code walkthrough

1. LangGraph makes the turn observable. Each node has one job.
2. STM and LTM stay separate. The state has session_context and recalled_memories fields.
3. The prompt tells the model how to use each scope. Short-term memory supports continuity. Long-term memory supports durable personalization.
4. The assistant hides implementation details. The model is instructed not to mention the memory plumbing.

#Trade-offs

• A small graph is easy to teach and debug.
• More complex agents may add tool calls, routing, summarization, or human review nodes.

#5. Write session events and extract durable memories

#How it works

#Redis Agent Memory mapping

#Code walkthrough

1. Every turn updates STM. The backend writes both user and assistant events to the current session.
2. The extractor is selective. Durable facts, stable preferences, and constraints can become long-term memory.
3. Transient details stay in STM. Dates, destinations, and active booking requests should not become long-term memory unless the user asks the agent to remember them.
4. Duplicates are filtered. The demo dedupes against recalled long-term memory and accepted candidates from the same turn.
5. Deterministic IDs help idempotency. Repeating the same memory for the same owner and namespace produces the same ID.

#Trade-offs

• LLM extraction can still vary.
• Deduping only against retrieved memories can miss duplicates that were not recalled.
• Real apps may need user confirmation, review queues, or deletion controls for long-term memory.

#6. Show memory behavior in the web UI

#How it works

#Data flow

1. The browser sends session_id and message to /api/chat.
2. FastAPI returns the assistant message and memory arrays.
3. The UI renders each memory array in its panel.
4. The + button creates a new session with the same owner ID.
5. The × button deletes current session memory only.

#Code walkthrough

1. Memory is visible. The UI makes hidden agent memory behavior easy to inspect.
2. New sessions demonstrate LTM reuse. The + button starts a new session but keeps the same configured owner ID.
3. Deleting STM demonstrates scope separation. The × button clears the current session without deleting durable memory.
4. The frontend stays minimal. Nginx serves static files and proxies /api/* to FastAPI.

#Trade-offs

• The UI is intentionally minimal.
• It is not an auth or multi-user production frontend.

#Running the demo

1. Start Docker:
2. Open http://localhost:8080.
3. Send: My name is Ricardo.
4. Send: Remember that I prefer flying Delta.
5. Send: I am planning a trip to Lisbon next month.
6. Watch the memory panels. The name and airline preference can become long-term memory. The active trip detail should stay in short-term memory unless the user explicitly asks the agent to remember it.
7. Click + to start a new session.
8. Ask: What do you remember about me?
9. Confirm that durable long-term memory persists across sessions.
10. Click × to delete the current session memory and note that long-term memory remains.

Caveat: If the UI does not load, check /api/ready and verify your Redis Agent Memory credentials.

Caveat: If memory extraction looks different from the examples, remember that model output can vary by model version and phrasing.

Note: If long-term memory looks polluted, change DEMO_OWNER_ID or DEMO_NAMESPACE for a clean run.

#Running the tests

• tests/test_utils.py for pure helper functions.
• tests/test_api.py for FastAPI endpoints with TestClient.
• tests/test_service.py for service behavior and long-term memory deduplication.

#Production considerations

• Use real authentication and stable user IDs instead of demo defaults.
• Add delete, export, and review paths for long-term memory where needed.
• Keep namespaces separate for each app and environment.
• Monitor readiness, Redis Agent Memory latency, and downstream LLM latency.
• Consider summarization when session memory grows beyond simple truncation.
• Consider human-in-the-loop review before storing sensitive memories.
• Avoid storing secrets or sensitive transient details as long-term memory.

#Next steps

• Add a memory review screen before writing long-term memory.
• Add user-specific auth and owner IDs.
• Add summarization for older session events.
• Add Redis Iris to bring in real travel data.
• Inspect memory with Redis Insight if available.
• Deploy with a managed Redis or Redis Agent Memory setup.

#References

• Redis Iris
• Demo source
• Build a memory-aware AI agent with Redis Agent Memory and Redis Context Retriever
• Redis Agent Memory package
• LangGraph documentation
• OpenAI docs
• Redis Cloud free tier
• What is Agent Memory? Example using LangGraph and Redis
• Build a car dealership AI agent with Google ADK and Redis Agent Memory Server