Files
Saket Aryan 0d37619f24 fix(plugins): say what telemetry actually sends, and salt the hashes
The plugin README promises "anonymous usage events" and the telemetry module's
docstring says it sends only "salted hashes". Neither is true.

resolve_distinct_id() exchanges the API key for the account email and sends that
as the distinct_id on every event. Installing the plugin requires an API key, so
this is nearly every user. That is probably the behaviour we want — the Python
SDK and the CLI attribute the same way — but the description has to match it.

repo_hash and session_hash were unsalted SHA-256 cut to 16 hex characters.
repo.identity is a git remote URL, or `local:<absolute path>` when there is no
remote, which normally contains the account username. Sixteen unsalted hex
characters over that input space is enumerable, so the hash was not a privacy
control at all.

Salted per install, with the salt kept in the identity file. That preserves
every within-account join the analytics actually use and gives up only
cross-machine joins on the same repository, which nothing computes. Since the
distinct_id is already the email, the hash was never buying privacy from us —
only from whoever obtains the data later, which is exactly what the salt fixes.

Also corrects deepseek-plugin's README and source comment, which told readers
ZAPIER and STRANDS were already in the backend's KNOWN_EVENT_SOURCES allowlist.
Neither was.

Adds a Telemetry section to docs/integrations/claude-code.mdx, which had none.

Claude-Session: https://claude.ai/code/session_01C7tEmH86HAr7GoAAKCEHZb
2026-09-15 00:17:26 +05:30

4.7 KiB

mem0-strands

Persistent long-term memory for Strands Agents, backed by Mem0

A community Strands Agents integration that plugs Mem0 in as a first-class MemoryStore.


mem0-strands gives Strands agents durable memory that survives across sessions, backed by Mem0. Where the mem0_memory tool is called explicitly by the model, Mem0MemoryStore plugs into the agent loop directly: the manager recalls context and injects it automatically, and writes new memories, either verbatim or by extracting facts from the conversation.

  • Automatic recall + injection — relevant memories are searched and prepended to the prompt every turn, no tool call required.
  • Server-side extraction — raw conversation turns are handed to Mem0, which distills and de-duplicates facts on its own pipeline (no extra client-side model call).
  • Hosted or self-hosted — the managed Mem0 Platform by default, or your own Mem0 OSS backend via a config dict.

Install

pip install mem0-strands

Usage

from strands import Agent
from strands.memory import MemoryManager
from mem0_strands import Mem0MemoryStore

# Recall + write, distilling facts from the conversation via Mem0's server-side extraction.
store = Mem0MemoryStore(user_id="alex", writable=True, extraction=True)
agent = Agent(memory_manager=MemoryManager(stores=[store]))

# The agent now recalls from and writes to Mem0 without any explicit tool call.
agent("Remember that I prefer dark-mode dashboards and only drink oat milk.")
agent("How do I like my dashboards?")  # recalls the stored preference

Set MEM0_API_KEY for the hosted platform (get one at app.mem0.ai), or pass api_key=.... For a self-hosted Mem0 OSS backend, pass a config=... dict instead.

How it works

Mem0MemoryStore implements all three MemoryStore hooks:

Method Maps to When it runs
search(query) mem0.search(query, filters={...}) Every turn, to recall and inject context
add(content) mem0.add(content, infer=False) The add_memory tool / a client-side extractor — stores a fact verbatim
add_messages(messages) mem0.add(rendered_turns, infer=True) Extraction — renders conversation turns to text, then hands them to Mem0's server-side extraction

Because add_messages is implemented, enabling extraction routes conversation turns straight to Mem0's own extraction pipeline. A store that only implemented add would instead need a client-side ModelExtractor (an extra model call) to distill facts first.

Configuration

Argument Default Description
user_id / agent_id / run_id / app_id (at least one required) Mem0 entity scope that owns the memories
name "mem0" Store identifier, used to target it from memory tools
writable True Whether the manager may write to the store
extraction None Automatic extraction (bool or ExtractionConfig)
max_search_results None Default result cap per search (falls back to 5)
metadata None Default metadata merged into every write
api_key / host env Mem0 platform key / base URL (api_key defaults to $MEM0_API_KEY)
config None Mem0 OSS config dict for a self-hosted backend

The explicit tool

For the model-called tool (store / retrieve / get / delete), use the mem0_memory tool from strands-agents-tools. The store and the tool share one Mem0 backend and namespace.

Telemetry

The store sends usage events (store configuration, operation, duration, result counts, coarse failure kind) over the Mem0 SDK's existing telemetry client, tagged source="STRANDS". These are not anonymous: when an API key is configured they are sent under your Mem0 account email, the same way the SDK attributes its own. Queries, memory text, message content, entity ids, and metadata are never sent. Turn it off with MEM0_TELEMETRY=false.

Development

The package lives under python/ (monorepo-style layout matching the Strands extension-template).

cd python
pip install hatch
hatch run test        # pytest (no live server required — mocked client)
hatch run prepare     # format + lint + typecheck + test

License

Apache-2.0. Mem0 is a trademark of its respective owner. Strands Agents is a project of its respective authors.