TL;DR
TencentDB Agent Memory is Tencent Cloud’s open-source, self-hosted team-level memory hub for AI coding agents. The pitch is deceptively simple: if you’ve already explained your project once, a new agent session shouldn’t make you explain it again. It turns your team’s conversations, documents, and code into four reusable memory assets — Chat Memory, Skill, Wiki, and CodeGraph — that are versioned, permissioned, and equipped to specific agents.
Single-agent memory is a crowded field (Cognee, Mem0, Supermemory, Honcho, and a dozen more). What makes this one different is the governance layer: a teammate’s agent can read what your agent learned, but only if you shared it — private-by-default, with real ACLs. The stable v2.0.0 landed August 3, 2026, it’s MIT-licensed, and it hit #1 on GitHub Trending.
- Four asset types replace flat chat logs: Chat Memory, Skill, Wiki, CodeGraph
- ACL-governed sharing — private / team / restricted / agent visibility, private by default
- Self-hosted, one-command Docker deploy, no vendor API dependency
- Layered memory (L0→L3) with BM25 + vector + RRF retrieval under strict budget caps
- Protocol-native: speaks both Anthropic and OpenAI APIs, integrates with Claude Code, OpenClaw, Hermes, CodeBuddy
- Self-reported PersonaMem jump from 48% → 76% (no independent reproduction yet)
If you’ve been wiring “agent memory” out of a pile of embeddings and a WHERE similarity > 0.8 query — and then copy-pasting the results between three teammates’ agents by hand — this is the layer you’ve been reinventing.
Quick Reference
| Field | Value |
|---|---|
| Repo | TencentCloud/TencentDB-Agent-Memory |
| License | MIT |
| Stable release | v2.0.0 (Aug 3, 2026) |
| Deploy | Self-hosted, 3 Docker images (linux/amd64 + linux/arm64) |
| SDKs | TypeScript, Python |
| Integrations | Claude Code, OpenClaw, Hermes, CodeBuddy, direct SDK |
| Default ports | 8420 (Core), 8125 (panel), 8424 (knowledge), 8096 (proxy) |
| Benchmark | PersonaMem 48% → 76% (self-reported) |
What Problem Does It Actually Solve?
Every team building with coding agents hits the same wall twice.
First wall: the context window is not memory. You can jam the last 20 messages back in on every turn, but that’s a rolling buffer, not recall. Knowledge learned in session 1 evaporates by session 100.
Second wall — the one nobody else is solving: memory is per-person. Your agent slowly learns “don’t refactor the old auth module — mobile still uses it.” Then your teammate spins up their own agent, which cheerfully refactors it, because that hard-won context lived in your chat history, not the team’s.
TencentDB Agent Memory’s framing is that memory is a team asset, not a session artifact:
Existing information → Reusable memory assets → Fewer turns → Less rework → More stable results.
The mental model they use in the README is a save file. Most agents’ first task is re-learning your project. This tool turns the learning cost you’ve already paid into a save file the whole squad can load on day one.
The Four Memory Assets
Instead of one undifferentiated blob of “memory,” everything registers as one of four typed Memory Assets:
| Asset | What it captures | Killer use case |
|---|---|---|
| Chat Memory | Preferences, facts, decisions, interaction history | ”This user prefers pytest over unittest” |
| Skill | Reusable procedures with versions, trigger boundaries, execution steps, validation rules | Release checklist, incident runbook |
| Wiki | Docs turned into structured pages with a link graph | Product spec an agent can navigate |
| CodeGraph | Symbols, files, call relationships, impact paths | ”Changing this function affects those 6 callers” |
The distinction between Skill and a plain prompt snippet matters. A Skill isn’t just text you paste — it carries versions, resource files, trigger boundaries, execution steps, and validation rules. It’s closer to a versioned runbook than a system-prompt fragment. (The Skill machinery borrows from Nous Research’s Hermes Agent, credited in the README.)
CodeGraph is the one that surprised me most. Standard RAG over a codebase tells the agent “the code is here.” CodeGraph tells it “changing this might affect those.” Before an agent modifies a function, it can inspect callers/callees and run impact analysis — which is exactly the safety check human reviewers do and agents usually skip. (The CodeGraph module builds on the open-source codegraph project.)
The Wiki layer is explicitly inspired by Andrej Karpathy’s “LLM-maintained knowledge base” idea — treating documentation as an incrementally growing artifact the model keeps up to date, rather than a static dump.
Layered Distillation: L0 → L3
Chat Memory isn’t stored flat. Raw conversations save as L0, then an async pipeline refines them into progressively more distilled layers:
| Layer | Stores | Used for |
|---|---|---|
| L0 Conversation | Raw conversation, full context | Verify exact wording, timestamps, sources |
| L1 Atom | Extracted facts, preferences, constraints, events | Precise recall of actionable info |
| L2 Scenario | Knowledge blocks organized per project/scenario | Restore a working context fast |
| L3 Core / Persona | Long-term profiles, stable patterns | Rapidly enter a user’s/team’s context |
Retrieval is layered too, and this is the clever bit for context-window economics. Normally L2/L3 give a fast context bootstrap — a compact summary that gets the agent oriented. Only when specific facts are needed does the system fall back to L1/L0 using BM25 + vector retrieval + RRF (reciprocal rank fusion). Every result set is capped by item count, character budget, and a timeout, so memory never crowds out the actual task in the context window.
That “budgeted retrieval” design is a direct answer to the most common failure mode of naive memory systems: dumping 8K tokens of half-relevant history into every prompt and calling it recall.
Governance Is the Actual Differentiator
Here’s the sentence from the README that sums up the whole project:
RAG answers “what can be found?” Team Memory also answers “who can use it, which version is valid, and which Agent should receive it.”
Standard RAG is a retrieval problem. Team memory is a permissions problem. TencentDB Agent Memory uses Fixed Binding + ACL: it first narrows scope by team, user, agent, and visibility, then retrieves against the current query.
Four visibility levels:
| Visibility | Semantics |
|---|---|
| private | Owner only — not even team admins can read it |
| team | All team members can read; Owner/Admin can manage |
| restricted | Precise access via User / Role / Agent ACL |
| agent | Targeted equipping of specific agents in the team |
New Chat Memory and Skills default to private. Sharing is an explicit action, not a default leak — which is the right default for anything touching a real codebase. You can assign a “Release” Skill to only the Release Agent, an “Architecture” Wiki to all dev agents, and CodeGraph to just Coder and Reviewer. Different roles, different loadouts.
This is genuinely novel. Cognee, Mem0, and Supermemory all give you storage and recall. None of them ship an opinionated ownership/version/ACL model out of the box. If your problem is “one dev, persistent memory,” those are simpler. If your problem is “five agents across three people who shouldn’t all see everything,” this is the only OSS option that treats that as a first-class concern.
Getting It Running
The deploy story is refreshingly short. Three services — memory-core, memory-hub, and proxy — start with one command:
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env # Fill in two sets of LLM params: memory group + proxy group
./start-all.sh # Launches everything; prints a one-liner to paste into Claude
Then open the panel at http://localhost:8125. When start-all.sh finishes, it prints a ready-to-paste connection string for Claude Code.
The Memory Proxy is the integration seam, and it’s smart. It speaks both Anthropic and OpenAI protocols, exposing /claude-code/<spaceId>/v1/messages and /v1/chat/completions. On the first turn, sessionInit uses Claude Code’s native AskUserQuestion tool to pick your team, agent, and task. Every subsequent turn injects that agent’s L2/L3 memory, matched Skills, and knowledge into the system prompt before forwarding upstream — so from the model’s perspective, memory just appears in context.
Official SDKs ship for TypeScript and Python, and there’s a migration tool if you’re coming from a v1.x install.
Community Reactions
The project has real traction — it first hit #1 on GitHub Trending on July 8, 2026, and the v2.0 relaunch put it back near the top. On r/openclaw, the recurring theme is that people found it while frustrated with reactive memory:
“The setup is generally solid, but my main pain point is that memory capture is still too reactive. I frequently have to explicitly prompt the agent to ‘remember this’ or manually dictate what needs to be stored.” — then linking to this repo as the fix they’d found.
That’s the honest state of the field: most memory tools still make you say “remember this.” TencentDB Agent Memory’s async L0→L3 distillation is aimed squarely at reducing that manual prompting, though (see limitations) fully automatic routing isn’t done yet.
The v2.0.0 release notes add some clearly team-driven features: Skill forced archiving, scheduled CodeGraph repository sync, system-admin asset management, an English/Chinese panel toggle, and a Cost Guard that assigns cheaper models to specific agents — a nice touch when you’re running a “squad” and don’t want your Reviewer agent burning Opus tokens.
Honest Limitations
The README is unusually candid about what’s unfinished, which I appreciate. Straight from the maintainers plus my own read:
- CodeGraph favors public HTTPS repos. Private-repo support and SSH credentials are “still being refined.” For most teams — whose code is private — this is the single biggest gap today.
- Memory routing is manual. The Hub supports manual asset binding; fully automated “the right memory shows up for the right agent” routing is still under iteration. You’ll be doing loadout config by hand for now.
- The benchmark is self-reported. PersonaMem 48% → 76% (+59% relative) is the headline number, but it’s Tencent’s own measurement with no independent reproduction published. Treat it as directional, not gospel.
- Framework support is finite. OpenClaw, Hermes, Claude Code, CodeBuddy, and direct SDK today. Broader cross-framework migration is roadmap, not shipping.
- Async processing lag. Wiki and CodeGraph build asynchronously — you import a repo and wait for it to reach “ready” status before it’s usable. Not instant.
- It’s a Tencent Cloud project. MIT license and full self-hosting defuse most lock-in fears, but some teams will still weigh the governance/supply-chain optics of the vendor. The code is open; audit it if that matters to you.
Should You Use It?
A quick decision guide:
- Solo dev, one agent, want persistent memory? You probably don’t need the governance layer. Cognee or Mem0 are lighter. But the one-command Docker deploy is easy enough that this isn’t a bad choice either.
- Small team, multiple agents, shared codebase? This is the sweet spot, and honestly the only OSS tool treating team-level ACLs as a first-class feature. Pilot it.
- Private-repo shop that lives in CodeGraph? Wait a beat, or plan to contribute the private-repo/SSH support — that’s the gap.
- Large regulated enterprise? Pilot, don’t standardize. The governance model is promising but private-repo CodeGraph and automated routing aren’t production-hardened yet.
FAQ
Is TencentDB Agent Memory free and open source?
Yes. It’s MIT-licensed and fully self-hosted, with three Docker images (multi-arch: linux/amd64 and linux/arm64). There’s no required cloud API or paid tier — you run it on your own infrastructure.
How is it different from Cognee, Mem0, or Supermemory? Those are excellent single-agent/single-user memory layers focused on storage and recall. TencentDB Agent Memory adds a governance layer: ownership, versioning, and ACL-based sharing (private/team/restricted/agent) so multiple agents across multiple people can share memory selectively. If you only need “one agent, persistent memory,” the others are simpler; if you need team-level access control, this is currently the only OSS option.
Does it work with Claude Code?
Yes — it’s a primary integration. The Memory Proxy exposes an Anthropic-compatible /claude-code/<spaceId>/v1/messages endpoint and uses Claude Code’s native AskUserQuestion tool for session setup. It also supports OpenClaw, Hermes, CodeBuddy, and direct SDK use, and speaks the OpenAI protocol for other clients.
Can it index my private repositories? Partially. CodeGraph currently prioritizes public HTTPS repos; private-repo support and SSH credentials are still being refined per the maintainers. If your workflow depends entirely on private-repo indexing, this is the limitation to watch before committing.
Is the 48% → 76% PersonaMem improvement trustworthy? It’s a self-reported figure from Tencent with no independent reproduction published yet. The layered L0→L3 distillation and budgeted retrieval are sound designs, but treat the specific number as directional until a third party reproduces it.
Sources
- TencentDB Agent Memory — GitHub repository & README (MIT license, v2.0.0 release notes, INSTALL.md, architecture docs)
- MarkTechPost: Tencent Cloud Open-Sources TencentDB Agent Memory v2.0 (deployment analysis, benchmark reporting)
- MarkTechPost: original v1 launch coverage (4-tier pipeline background)
- r/openclaw discussion thread (community reaction on reactive vs. automatic capture)
- Upstream credits:
codegraph(CodeGraph module), Hermes Agent (Skill machinery), Karpathy’s LLM Wiki gist (Wiki design)