TencentDB Agent Memory is an **MIT-licensed team memory hub for AI agents**, open-sourced by Tencent Cloud on **7 April 2026**. It has grown to roughly **11,177 stars and 1,061 forks**, and it appeared on GitHub Trending again today. The project shipped **v1.0.0** on 11 June 2026 and is currently on **v2.0.0-beta.1** (22 July 2026). The premise is narrow and practical: if an agent has already learned something about your project, the next agent should not have to learn it again. ## The Problem: Every Session Starts From Zero Most agent memory work stops at conversation recall — store the transcript, embed it, retrieve it later. Tencent's framing is broader. Anything that stops the next agent from reinventing the wheel counts as memory: the decisions made in a chat, the workflow that finally worked, the design doc somebody already read, the call graph of the repository being modified. The stated pipeline is `existing information → reusable memory assets → fewer turns → less rework`. What makes this more than a vector store is that assets are **governed** — they have owners, versions, visibility, and bindings to specific agents. ## Four Asset Types Rather than one undifferentiated memory blob, the system distinguishes four kinds of asset: | Asset | What it captures | Where it comes from | |---|---|---| | **Chat Memory** | Preferences, facts, decisions, interaction history | Distilled from agent conversations | | **Skill** | Reusable procedures with versions, resource files, trigger boundaries, execution steps, validation rules | Extracted from completed work and tool calls | | **Wiki** | Product docs, design specs, runbooks as structured pages with a link graph | Imported documents | | **CodeGraph** | Symbols, files, call relationships, impact paths | Indexed repositories | The Skill definition is the notable one — it is explicitly not a prompt snippet. Versioning, trigger boundaries, and validation rules are what let a skill be reviewed and shared rather than copy-pasted between prompts. ## Layered Distillation Chat memory is not stored flat. An asynchronous pipeline refines raw conversation through four levels: | Layer | Contents | Primary use | |---|---|---| | **L0 Conversation** | Raw conversations with full context | Verify exact wording, timestamps, sources | | **L1 Atom** | Facts, preferences, constraints, events | Precise recall of actionable information | | **L2 Scenario** | Knowledge blocks organized by project or scenario | Quickly restore a working context | | **L3 Core / Persona** | Long-term profiles, stable patterns, high-level cognition | Rapid entry into a user's or team's context | Retrieval mirrors that structure. L2 and L3 normally provide a fast context bootstrap; when a specific fact is needed, **BM25 plus vector retrieval fused with RRF** falls back to L1 and L0. Results are capped by item count, character budget, and timeout — a deliberate guard against memory crowding out the actual task in the context window. That cap is the detail most memory systems get wrong, and it is good to see it treated as a first-class constraint. ## Governance, Not Just Retrieval The README draws a direct contrast with plain RAG: retrieval answers "what can be found?", while a memory hub also has to answer "who can use it, which version is valid, and which agent should receive it." Assets are registered uniformly as Memory Assets, and **Fixed Binding plus ACL** determines what a given agent can reach. Visibility runs `private` (owner only), `team` (all members), and `restricted` (precise User / Role / Agent access lists). The permission scope narrows first, and retrieval runs inside it. Practically, this means a team can share a release checklist skill without also exposing one member's private client notes, and swapping agent frameworks means re-equipping assets rather than rebuilding them. Knowledge is pulled rather than pushed. Agents discover capabilities through `/v3/tools/list` and then call `/v3/tools/call` to read a Wiki page, source file, or impact path — so documents and code stay available as tools instead of being injected wholesale into every prompt. ## Installation Three services come up together — `memory-core`, `memory-hub`, and `proxy`: ```bash git clone https://github.com/Tencent/TencentDB-Agent-Memory.git cd TencentDB-Agent-Memory/deploy/global-images cp .env.example .env $EDITOR .env # two sets of LLM parameters: memory group + proxy group ./start-all.sh ``` The panel opens at `http://localhost:8125`, and the start script prints a one-liner that pastes directly into Claude. The stack requires **Node 22.16+**, and integrates with **OpenClaw** (2026.3.13+) and the **Hermes** gateway. Teams on v1.x or v0.x have a supplied migration tool for moving data to v2. ## Reported Results The single benchmark published is **PersonaMem**, which tests whether an agent correctly understands and applies user information after extended interaction: | Benchmark | Without | With | Relative gain | |---|---|---|---| | PersonaMem | 48% | 76% | +59% | One benchmark on a memory-favorable task is thin evidence, and the README does not publish latency overhead, token cost, or comparisons against other memory systems. Treat the number as directional. ## Caveats The project is candid about its rough edges, and they matter for anyone considering it: - **v2 is beta.** The current release is `v2.0.0-beta.1`, and the README describes Team Memory as "evolving quickly." With **413 open issues**, interfaces should be expected to move. - **Asynchronous builds.** Wiki and CodeGraph are constructed in the background; both need processing time before reaching `ready` status. - **Repository limits.** CodeGraph prioritizes public HTTPS repositories — private repos and SSH credentials are still being refined, which is a real obstacle for the enterprise teams most likely to want this. - **Manual routing.** Asset binding is manual today; automated memory routing is still under iteration, so the "equip the right agent" step is human work. - **Narrow framework support.** OpenClaw, Hermes, and the SDK are supported; broader cross-framework migration is on the roadmap, which sits awkwardly beside the framework-portability pitch. - **Two LLM configurations required.** Setup needs separate credentials for the memory group and proxy group, adding operational cost beyond a single API key. The project also credits its foundations openly: the CodeGraph asset module uses code from [colbymchenry/codegraph](https://github.com/colbymchenry/codegraph), Skill management builds on code from Nous Research's Hermes Agent, and the Wiki layer is informed by Andrej Karpathy's "LLM Wiki" concept. ## Verdict The useful contribution here is treating memory as a **governed asset with an owner, a version, and an access list**, rather than as a retrieval index. That framing is what distinguishes a team memory hub from a shared vector database, and the layered L0–L3 distillation with hard context budgets shows the design has been through contact with real context-window limits. Teams running several agents across shared codebases — where the same onboarding explanation gets repeated every session — will find the four-asset model worth an evaluation, particularly if they already use OpenClaw or Hermes. Teams on private repositories, on unsupported frameworks, or unwilling to run a beta service that mediates their agent context should wait for the stable v2 and broader adapter coverage.