Skip to content

docs: clarify short-term memory behavior in the memory example#483

Open
azarboon wants to merge 2 commits intostrands-agents:mainfrom
azarboon:memory-agent2
Open

docs: clarify short-term memory behavior in the memory example#483
azarboon wants to merge 2 commits intostrands-agents:mainfrom
azarboon:memory-agent2

Conversation

@azarboon
Copy link
Copy Markdown
Contributor

@azarboon azarboon commented Jan 27, 2026

Description

What changed:
This change clarifies that the memory used in the memory agent workflow is short-term, using the same terminology as the mem0 documentation, and is scoped to the current session by default. It also directs users to the relevant configuration and documentation for enabling persistence across sessions. Links to the appropriate mem0 documentation are added to improve discoverability and navigation.

Why this change is needed:
The current documentation is largely silent and somewhat misleading regarding memory persistence. This ambiguity is compounded by the fact that mem0’s own documentation is vague on this topic. I had to spend time verifying the actual behavior, and this change aims to save that effort for future readers. The updated text aligns expectations with the default behavior and provides clear pointers to configuration options for enabling persistence.

Related Issues

Type of Change

  • New content
  • Content update/revision

Checklist

  • I have read the CONTRIBUTING document
  • My changes follow the project's documentation style
  • I have tested the documentation locally using mkdocs serve
  • Links in the documentation are valid and working

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@azarboon azarboon changed the title Clarify short-term nature of memory in documentation docs: clarify short-term nature of memory in documentation Jan 27, 2026
@azarboon azarboon changed the title docs: clarify short-term nature of memory in documentation docs: clarify short-term memory behavior in the memory example Jan 27, 2026
@ryanycoleman
Copy link
Copy Markdown
Member

Hi @azarboon, thanks for the contribution! I did some digging into the mem0 default behavior before merging to make sure the note is accurate.

Looking at the example's source code (memory_agent.py), it uses mem0_memory from strands_tools with no explicit vector store configuration. By default, mem0 uses a local Qdrant backend that persists to ~/.mem0/ on disk so memories actually survive across sessions without any additional setup.

I verified this by tracing through the mem0 source:

  • memory/setup.py creates a ~/.mem0/ directory for persistent config and data
  • memory/main.py initializes the vector store from defaults, which writes to that local directory
  • The mem0 docs on memory types describe both short-term and long-term memory, but the default local setup provides persistence

So the original wording ("Storing user-specific information persistently") appears to be accurate for the default config. The proposed note saying memory is "short-term and scoped to the current session" could mislead users into thinking they need extra setup for persistence, when persistence is actually the default.

That said, your instinct that users might want alternative options is helpful. Would you be open to revising the note to something like:

By default, mem0 persists memories to local storage at ~/.mem0/. See mem0 vector store configuration for options on using a different backend for production use.

...and please accept our apologies for sitting on this PR!

@azarboon
Copy link
Copy Markdown
Contributor Author

Hi @azarboon, thanks for the contribution! I did some digging into the mem0 default behavior before merging to make sure the note is accurate.

Looking at the example's source code (memory_agent.py), it uses mem0_memory from strands_tools with no explicit vector store configuration. By default, mem0 uses a local Qdrant backend that persists to ~/.mem0/ on disk so memories actually survive across sessions without any additional setup.

I verified this by tracing through the mem0 source:

  • memory/setup.py creates a ~/.mem0/ directory for persistent config and data
  • memory/main.py initializes the vector store from defaults, which writes to that local directory
  • The mem0 docs on memory types describe both short-term and long-term memory, but the default local setup provides persistence

So the original wording ("Storing user-specific information persistently") appears to be accurate for the default config. The proposed note saying memory is "short-term and scoped to the current session" could mislead users into thinking they need extra setup for persistence, when persistence is actually the default.

That said, your instinct that users might want alternative options is helpful. Would you be open to revising the note to something like:

By default, mem0 persists memories to local storage at ~/.mem0/. See mem0 vector store configuration for options on using a different backend for production use.

...and please accept our apologies for sitting on this PR!

thank you @ryanycoleman for digging into this and for the comment. I have updated the commit accordingly. I think it is ready for merge.

@github-actions
Copy link
Copy Markdown
Contributor

Documentation Preview Failed

The documentation deployment encountered an error. Please check the deployment logs for more details.

Comment thread docs/examples/python/memory_agent.md
@github-actions
Copy link
Copy Markdown
Contributor

Assessment: Approve ✅

This is a helpful documentation improvement that clarifies mem0's default memory persistence behavior. The content has been verified by a maintainer and the external link is valid.

Review Details
  • Content: Accurately describes that mem0 persists to ~/.mem0/ by default
  • Link: External documentation link verified as working
  • Scope: Minimal, focused change addressing user confusion

One minor suggestion for syntax consistency has been left as an inline comment, but this is non-blocking. Thanks for the contribution!

@zastrowm
Copy link
Copy Markdown
Member

it looks like there's a conflict here?

@azarboon
Copy link
Copy Markdown
Contributor Author

it looks like there's a conflict here?

@zastrowm @ryanycoleman

Yes, there appears to be an issue, but I don’t fully understand it. My changes were minimal. Could you help me resolve it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants