TencentDB Agent Memory gives an agent team a shared, growing memory instead of starting cold every session. Two ways it relates to gm's own / (see / skills for that): (1) as a fully standalone system (this skill's main content, below) when the ask spans multiple agent frameworks, multiple team members, or needs a human-reviewable panel; (2) as an opt-in storage backend for gm's own memory verbs ( in , disabled by default) -- when a namespace is routed to it, gm's /// write file-pointer-indexed content compatible with this system's format instead of gm's default 384-dim md-corpus store, with no change to the verb surface an agent calls. Reach for THIS skill's setup instructions (Docker Compose, panel UI) for the standalone deployment; reach for 's own docs when the ask is just "make gm's memory use the Tencent-compatible backend."

Assets are portable across agent frameworks and shareable across a team -- a new agent or team member can load existing memory instead of relearning from scratch.

git clone https://github.com/AnEntrypoint/agent-memory.git
cd agent-memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # fill in LLM params for both the memory group and the proxy group
./start-all.sh     # starts memory-core + memory-hub + proxy; prints a one-liner for Claude Code setup

Open the panel at .

For a standalone Memory Hub, Proxy + Claude Code / CodeBuddy integration, port reference, and teardown, see in the repo ( for Chinese).

openclaw plugins install @tencentdb-agent-memory/memory-tencentdb

Minimal config in :

{ "memory-tencentdb": { "enabled": true } }

Zero-config works for basic capability. Production tuning groups: , , , , , -- see for the full recommended template and failure-mode notes (embedding four-tuple, retention-day gating, etc.).

Use the migration tool documented at in the repo. New installs skip this.

Distinct from #3 above (that's the standalone system's own internal format evolution). This is for a project that already has gm-native memories (, written by / before was enabled) and wants them carried over once a namespace opts into the Tencent-compatible backend, so recall doesn't go cold on the switch.

Two ways to run this migration -- same underlying write path (), pick whichever fits the situation:

Both refuse up front unless the destination namespace's resolved is exactly -- gm's embedder cannot produce vectors at any other width, and a namespace configured for externally-embedded 768-dim content (the default) cannot safely receive them (recall queries that namespace through the project-resolved dim, not a per-import override, so a dim mismatch there is a real defect, not a formality). A project wanting both kinds of content needs two separate -routed namespaces, each at its own dim.

By default this is a one-way copy, not a move: the source files and their index rows are left untouched, so the default backend keeps working for any namespace not also switched over. Pass (verb) or (script) to opt into moving each successfully-migrated source file to instead of leaving it in place -- content stays inspectable, but the live corpus no longer duplicates what the new backend now serves.

Treat and any LLM credentials as sensitive -- do not echo them into chat, logs, or screenshots. Prefer environment-variable injection over literal values in config files. When editing config, touch only the /agent-memory section; do not overwrite unrelated plugin or service config.