Store managers: extract and save in one step

create_memory_store_manager combines a memory manager with the store: it finds related memories, asks the model to extract and update, and writes the result.

asha = {"configurable": {"user_id": "asha"}}
manager.invoke({"messages": [{"role": "user", "content": "My name is Asha and please email me."}]}, config=asha)

for item in sorted(store.search(("memories", "asha")), key=lambda item: item.value["content"]["content"]):
    print(item.value)

The namespace ("memories", "{user_id}") is a template. {user_id} is filled from config["configurable"] on every call, so one manager serves every customer and each customer's memories land in their own namespace. Values are stored with the schema's name as kind and the fields as content.

manager.invoke({"messages": [{"role": "user", "content": "Text me instead, my inbox is full."}]}, config=asha)
print(sorted(item.value["content"]["content"] for item in store.search(("memories", "asha"))))

ravi = {"configurable": {"user_id": "ravi"}}
manager.invoke({"messages": [{"role": "user", "content": "Please call me."}]}, config=ravi)
print(sorted(item.value["content"]["content"] for item in store.search(("memories", "ravi"))))

Before extracting, the store manager searched Asha's namespace with the new conversation and passed what it found as existing memories, so the contact preference was patched instead of duplicated. Ravi's call wrote to his own namespace and saw none of Asha's.

What it does, in order

• Search the namespace for memories related to the conversation, up to query_limit, 5 by default. query_model can write better search queries first.
• Call the memory manager with those as existing memories.
• Put new and updated memories, and delete removed ones if enable_deletes=True.