memory/long-term

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Long-term memory across different thread IDs

Long-term memory allows storing information across different thread IDs, useful for learning information about a user in one conversation and using it in another. This enables cross-conversation context and personalization.

Long-term memory stores user-specific data across sessions

Long-term memory stores user-specific or application-level data that persists across multiple conversation sessions. Use a store (InMemoryStore for development or database-backed stores for production) compiled into the graph.

InMemoryStore for long-term memory development

InMemoryStore provides in-memory long-term memory suitable for development. Import from langgraph.store.memory and pass to builder.compile(store=store). Can optionally enable semantic search with embeddings index.

PostgresStore for long-term memory production

PostgresStore is a production-grade store backed by PostgreSQL. Create it via PostgresStore.from_conn_string(DB_URI) and pass to builder.compile(store=store). Call store.setup() once before first use.

MongoDBStore for long-term memory production

MongoDBStore is a production-grade store backed by MongoDB. Create it via MongoDBStore.fromConnString(MONGODB_URI, { dbName, collectionName }) and pass to builder.compile({ store }). Supports optional embeddings for semantic search.

RedisStore for long-term memory production

RedisStore is a production-grade store backed by Redis. Create it via RedisStore.from_conn_string(DB_URI) and pass to builder.compile(store=store). Call store.setup() once before first use.

OracleStore for long-term memory production

OracleStore is a production-grade store backed by Oracle AI Database with vector search capability. Create it via OracleStore.from_conn_string(DB_URI, index={"embed": embeddings, "dims": 1536}) and pass to builder.compile(store=store). Requires Oracle AI Vector Search.

Example: Long-term memory with Postgres store

Example showing PostgresStore with semantic search for long-term memory. Demonstrates searching memories based on user input and storing new memories. Shows how to use runtime.store.asearch() and runtime.store.aput() with a context_schema.

Example: Long-term memory with MongoDB store

Example showing MongoDBStore with semantic search for long-term memory. Demonstrates searching and storing memories across conversation threads for the same user.

Example: Long-term memory with Redis store

Example showing RedisStore for long-term memory. Demonstrates searching and storing memories using runtime.store methods in both sync and async patterns.

Example: Long-term memory with Oracle store

Example showing OracleStore with vector search for long-term memory. Requires Oracle AI Database with vector search capability and embeddings. Demonstrates semantic search via store.asearch() and store.aput().

Example: Long-term memory with semantic search and Runtime

Example showing how to use Runtime object to access store in graph nodes. Demonstrates async chat function that searches memories based on user message and uses them in system prompt. Uses InMemoryStore with embeddings.

MongoDB auto embedding for vector search in memory store

MongoDB Atlas can generate embeddings server-side via Voyage AI for automatic embedding. Configure the indexConfig with name, path (the field to embed, e.g., 'value.content'), and model (e.g., 'voyage-4'). Values stored must have the field matching the configured path. Use MongoDBStore.fromConnString with dbName, collectionName, and indexConfig parameters. The store automatically generates query embeddings server-side when calling runtime.store.search().

MongoDB store configuration with auto embedding

Initialize MongoDBStore.fromConnString with MONGODB_URI, dbName, collectionName, and indexConfig. The indexConfig must specify: name (index name), path (field path for embeddings like 'value.content'), and model (Voyage AI model like 'voyage-4'). Store data as objects with the field matching the path. When calling runtime.store.search() with a query, MongoDB generates embeddings server-side matching the configured model.

Give your agent this brain