TencentDB Agent Memory's default branch is a feature branch, and its migration tool is titled v2 to v3

The newest tag is a 1.x patch published after a 2.x beta

The release list and the default branch point in different directions. The recent releases are v2.0.2 on 2026-10-09, v2.0.3-beta.1 on 2026-10-13, and v2.0.3 on 2026-10-26, so the 2.x line now has stable patch releases. The default branch, however, is feat/server_team, a feature branch rather than main. The README frames the project as in motion, describing Team Memory Beta as evolving quickly and inviting you to install it and start exploring in minutes. The practical consequence is that a reader who installs a tag and a reader who clones the default branch can end up on different code.

The migration is described as v1 to v2 and the tool is titled v2 to v3

There is a versioning inconsistency in the upgrade path, and it is worth pinning down because data migrations are not something you want to run twice. The readme says that if you are already on an older release, in the v1.x or v0.x range, and want to bring existing data over to v2.0.0 and later, a migration tool is provided, and it points at a document titled Data Migration Tool with a v2 to v3 label, located under a scripts directory inside the MemoryCore component. So the prose describes a move from the old lines up to 2.0.0, while the tool that performs the move is named for a later jump. Either the target version in the prose is behind the tool, or the tool is named for the internal schema revision rather than the release. New installations are told they can skip the tool entirely, which means only upgraders meet this.

One shell script starts three services, and you configure two sets of credentials first

The install path is short and concrete, and it requires an edit before anything runs:

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # Fill in two sets of LLM parameters (memory group + proxy group)
./start-all.sh     # Launch everything with one command; when finished, it prints a one-liner you can paste directly into Claude

Three services come up together, described as memory-core, memory-hub, and proxy, and the panel is at a fixed local port. The comment on the editor line is the real prerequisite: two separate sets of LLM parameters, one for the memory group and one for the proxy group, meaning two credential sets rather than one. The script's last act is to print a line you can paste into Claude, so the tool hands you the integration string rather than making you look it up. That is a good first-run experience, and it also means the two credential groups are the thing to get right before you start.

The proxy is the whole integration, and the readme does not say what it does with prompts

The integration story is one sentence: one proxy, unchanged protocol, zero-code integration, point the agent's base URL to the proxy and it is done, with no plugin, hook, or MCP server required. Named clients include DeepSeek Harness, Claude Code, Codex, CodeBuddy, WorkBuddy, Hermes, and OpenClaw, with a generic integration guide for anything else and an open invitation to send a pull request adding native support. The convenience is genuine and the trade is worth naming. If the only requirement is repointing a base URL, then the proxy sits in the path of every model request your agent makes, which means it sees prompts and completions. The readme describes the proxy's role as sharing memory and points to the install document for per-client configuration, so check how requests are logged, cached, or retained before routing traffic through it.

Chat memory is distilled up four layers, and nothing says what promotes a memory

Chat memory is described as retaining preferences, facts, decisions, and interaction history, with each agent automatically getting its own memory when it is created so you do not re-introduce yourself next time. The structure is a ladder: L0 Conversation becomes L1 Atom, becomes L2 Scenario, becomes L3 Persona, with raw conversations distilled layer by layer. That is a sensible compression scheme and it is lossy by construction. A constraint that mattered once, like a note not to refactor an old auth module because mobile still depends on it, is exactly the kind of detail that a summarisation ladder can drop, and the readme's own example of costly context is the case most at risk. Before relying on it, check what triggers promotion from one layer to the next, whether a human approves it, and whether anything is retained at the lower layers once distilled. Those are the questions that determine whether you can trust the persona layer as a summary of what actually happened.

Personal skills are private by default, and an extracted skill can carry execution steps

The skill asset is described as more than a prompt snippet: it has versions, resource files, trigger boundaries, execution steps, and validation rules, and agents can extract and manage reusable skills from conversations and tool calls once complex work is finished, then import them into the context of a designated agent when needed. Two properties of that design deserve attention. The first is governance, because personal skills are private by default and can be shared with the team after review, which is a real access boundary with a promotion step rather than a flat namespace. The second is capability, because a skill that carries trigger boundaries and execution steps is not inert text. It is something the system decided was worth doing, derived from work that already happened, and it can now be assigned to another agent. That is a supply-chain shape applied to behaviour rather than code, and the review step is the only thing standing between a private extraction and a team's shared automation.

Five readmes and four components, with the MongoDB backend off by default

The repository root has more entry points than one would hope. There are four components: MemoryCore, MemoryKnowledge, MemoryPanel, and MemoryProxy. There are four readme-shaped files, being the main one, a Chinese version, a docker one, and a deployment one, and three more documents exist in bilingual pairs, covering installation, the roadmap, and contributing. So there are several plausible documents to read and no single one that covers the system, and the complete installation documentation lives in a separate install document that the readme links. One configuration fact is stated plainly and is worth knowing before you plan the deployment: the MongoDB storage backend is experimental and off by default, with the install document carrying the details. So the default storage path is whatever ships enabled, and choosing MongoDB is an opt-in into something the project labels experimental.

Editorial conclusion

TencentDB Agent Memory suits a team running several coding agents against the same codebase that is tired of re-explaining context each session, and that is willing to run three services and two sets of model credentials locally. It is a poor fit if you need the default branch to match a release, since the default branch is a feature branch, and a poor fit if you cannot route model traffic through a proxy, because that is the entire integration mechanism. Before you commit, read the install document rather than the readme, decide whether experimental storage is something you want in the first deployment, and work out what your proxy does with prompts.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes