Semantic long-term memory for LangGraph agents

LangGraph separates two kinds of agent state. Short-term state is the conversation thread itself, which a checkpointer persists so a thread can resume, replay, and recover (see Using DynamoDB as a checkpoint store for LangGraph agents). Long-term memory is what the agent knows across threads, and LangGraph models it as a store: a namespaced key-value surface the agent writes to deliberately and reads back later.

The DynamoDBStore class, in the langgraph-checkpoint-aws package, is the DynamoDB implementation of that store. It handles the key-value side with hierarchical namespaces, Time to Live for expiring stale memories, and basic filtering. With a vector index configured (see Using vector indexes in DynamoDB), its search() method performs semantic search: memories are embedded on write, indexed asynchronously, and recalled by meaning, ranked by similarity, from the same table that holds them. There is no separate vector database to provision and no pipeline copying data into it.

Prerequisites

Install the libraries using pip:

pip install langgraph langgraph-checkpoint-aws langchain-aws

Set up the store

Configure the store with an index block and call setup():

from langchain_aws import BedrockEmbeddings
from langgraph_checkpoint_aws import DynamoDBStore

store = DynamoDBStore(
    table_name="support-agent-memory",
    region_name="us-east-1",
    index={
        "embed": BedrockEmbeddings(model_id="amazon.titan-embed-text-v2:0"),
        "dims": 1024,
        "fields": ["text"],
        "distance_function": "COSINE",
    },
)

store.setup()

Four settings in the index block are worth understanding:

setup() creates the table if it's absent, attaches the vector index, and enables Time to Live if you configured it. On an existing table, it adds only what's missing, so existing DynamoDBStore deployments can adopt semantic search without recreating the table or migrating items. Keep in mind that setup() doesn't return until the index reports ACTIVE and is no longer backfilling: an index that reports ACTIVE while still backfilling rejects SearchVectors calls. On a new empty table the wait is short. Retrofitting onto a table with existing items takes as long as the backfill takes.

Write memories

Writing is an ordinary put(). The embedding happens for you:

namespace = ("memories", "acme-corp", "user-8812")

store.put(namespace, "mem-1", {
    "text": "Account runs a proxy that closes idle sockets after 60 seconds",
    "source": "ticket-4471",
})
store.put(namespace, "mem-2", {
    "text": "Customer prefers email, asked not to be called by phone",
    "source": "ticket-4471",
})
store.put(namespace, "mem-3", {
    "text": "Uses a custom build of the SDK pinned to version 2.14",
    "source": "ticket-4502",
})

Recall by meaning

The customer opens a new conversation and says their connection keeps dropping after about a minute:

results = store.search(
    namespace,
    query="connection drops after a minute of inactivity",
    limit=3,
)

for item in results:
    print(round(item.score, 3), item.value["text"])

Output:

0.324 Account runs a proxy that closes idle sockets after 60 seconds
0.039 Customer prefers email, asked not to be called by phone
0.031 Uses a custom build of the SDK pinned to version 2.14

The relevant memory ranks first, and no key in the query matched anything. SearchItem.score follows the LangGraph convention where higher is more relevant. DynamoDB returns a distance, where lower is closer, so the store converts: for COSINE the score is 1 - distance, for EUCLIDEAN it is 1 / (1 + distance), and DOT_PRODUCT scores pass through unchanged. If you gate on an absolute score to decide whether a memory is relevant enough to inject into a prompt, calibrate that threshold against your own data and your chosen distance function.

Scope memory with the search schema

When DynamoDBStore creates the vector index, it declares the table's partition key as a HASH element in the index search schema. Because that element exists, every search must supply a condition for it, and the store supplies the namespace: the namespace tuple is joined to form the partition key value, so every semantic search is pinned to exactly one namespace. Three consequences follow:

The following table summarizes how to choose a namespace shape.

Avoid putting every memory in one namespace and filtering on metadata: filters are applied after DynamoDB has already selected the nearest matches across the entire namespace, and a single search returns at most the top 100 matches, so once one busy tenant fills the top 100 for a common query, a quieter tenant's search returns fewer results than requested even though their memories are present. Prefer namespace scoping over filters for anything that determines correctness. Going finer than your recall boundary is a legitimate design too: an agent that needs both user-specific and account-wide context searches both namespaces and merges the results.

Considerations

Additional resources