TencentDB Agent Memory v2.0 Review: A Self-Hosted Team Memory Hub for AI Agents (2026)

TencentDB Agent Memory v2.0.0 (August 2026, MIT, 15.3k GitHub stars) is a self-hosted, team-level memory hub that turns conversations, docs, and code into four governed assets — Chat Memory, Skills, Wiki, and CodeGraph — shared across Claude Code, OpenClaw, Hermes, and CodeBuddy via a proxy layer. Tencent reports PersonaMem accuracy jumping 48% → 76% and token usage dropping 61.38% on WideSearch. One-command Docker deploy; panel on :8125. Skip it if you're a solo dev (Mem0 or plain memory files are lighter) or if you can't invest in memory-review governance — stale team memory scales mistakes as fast as knowledge.

By Rohit Raj — Founding Engineer · 10+ yrs MVP shipping · LinkedIn

For the past year my daily setup has been a hand-rolled version of exactly this product: a tree-sitter code graph served over MCP for structural code questions, a Karpathy-style LLM wiki for project knowledge, a skills directory for reusable workflows, and per-project memory files for preferences and decisions. It works — and every part of it is duct tape. Nothing syncs across machines, nothing has access control, and when a memory goes stale I find out the hard way, mid-task.

So when [TencentDB Agent Memory](https://github.com/TencentCloud/TencentDB-Agent-Memory) hit #1 on GitHub trending this week — 15.3k stars, 1.4k forks, MIT license — with the exact same four-asset decomposition (chat memory, skills, wiki, code graph) packaged as a governed, self-hosted team hub, I paid attention. This is not another vector database with a memory API stapled on. It is an opinionated answer to the question every team running coding agents hits around month three: why does every developer's agent relearn the same things, and why does nothing one agent learns transfer to the next?

The v2.0.0 release (August 2026, the first non-beta packaging) is what pushed it onto the trending page, adding the team layer: a Memory Hub control panel, ACL-scoped sharing, and framework loadouts for OpenClaw, Hermes, Claude Code, and CodeBuddy. Third-party coverage landed within days — explainx.ai's v2 walkthrough (August 3) and a sharp dev.to governance critique (August 4). What none of that coverage does is compare it against the tools you're probably already evaluating — Mem0, Zep, Letta — or tell you how to wire it up without poisoning your whole team's context. That's this post.

The core pipeline shipped back in May 2026 (covered then by MarkTechPost) as a single-user, four-tier memory system. v2.0.0 turns it into a team product. The concrete changes:

• Four first-class memory assets. *Chat Memory* (layered L0–L3: raw conversation → distilled personas, with L1 extraction triggered every 5 turns and persona generation every 50 new memories), *Skills* (reusable workflows extracted from agent sessions, with versioning and validation rules), *Wiki* (docs converted into linked knowledge pages), and *CodeGraph* (symbol/call-graph index with impact analysis).
• Memory Hub + ACL governance. A web panel (default localhost:8125) where assets are default-private, then shared at user, team, or per-agent scope via Fixed Binding + ACL. Different agents get different memory *loadouts* instead of one global context dump.
• Framework proxy. A translation layer so the same assets serve Claude Code, OpenClaw, Hermes, and CodeBuddy — the asset outlives whichever agent framework you happen to use this quarter.
• Symbolic short-term memory. Heavy tool logs get condensed into compact Mermaid representations instead of raw transcripts, which is where much of the token saving comes from.

The published numbers are aggressive: on WideSearch, pass rate 33% → 50% with tokens down 221.31M → 85.64M (−61.38%); on SWE-bench, 58.4% → 64.2% with tokens down 33.09%; on PersonaMem, long-horizon accuracy 48% → 76%. Standard caveat — these are the vendor's own benchmark runs, on their chosen harness. But the *shape* of the claim (structured memory beats context-stuffing on both accuracy and cost) matches what I see daily with my hand-rolled stack: my code-graph MCP answers "what calls X" in one sub-millisecond query where a grep-and-read loop burns thousands of tokens.

Retrieval is hybrid BM25 + vector with Reciprocal Rank Fusion, returning 5 items per search with a 5-second timeout by default — a sane "retrieve less, retrieve right" default rather than the top-20 context flood most RAG setups ship with.

Everything runs locally — Node.js v22.16+ under the hood, Docker for deployment. The quickstart is genuinely one command after clone:

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
./start-all.sh
# Memory Hub panel → http://localhost:8125

That brings up the three services: Memory Core (extraction + storage), Memory Hub (the team panel where you review, share, and scope assets), and the Proxy (what your agent frameworks actually talk to). Wiring an agent means pointing it at the proxy instead of calling your LLM provider directly — the proxy injects the right memory loadout for that agent's identity and captures new candidate memories from the session.

For a Claude Code team the flow looks like: run the hub on one box (a $10/month VPS or an office Mac mini is plenty — memory extraction is the only LLM-heavy step), register each developer's agent with its own identity, and use the panel to decide which assets are personal (your chat-memory personas) versus team-shared (the wiki pages, the skills, the code graph). Cold-start matters more than the demo suggests: v2 can bootstrap assets by importing existing codebases, docs, and past agent session logs, and you should do that *before* judging retrieval quality — a hub with three memories retrieves garbage regardless of architecture.

Two hands-on cautions from someone who runs the equivalent stack. First, memory extraction quality depends on the extractor model — budget for a real model on the extraction path, not a 3B afterthought, because a bad L1 distillation poisons every layer above it. Second, watch what enters chat memory: agent transcripts routinely contain API keys, internal URLs, and client names. A team-shared memory asset is a data-exfiltration surface if you don't review before promoting from private to shared. The README's ACL model gives you the knobs; it doesn't give you the review habit.

Three workflows where this beats both context-stuffing and per-user memory tools:

1. The second developer's first week. Solo, my duct-tape stack is fine — I *am* the memory. The moment a second person's agent works the same codebase, everything my agent learned (build quirks, the flaky test, why we pinned that dependency) is invisible to theirs. A shared wiki + code graph + skills loadout means developer #2's agent starts with the team's accumulated context on day one. This is the strongest concrete use case, and it's exactly the one per-user memory layers don't address.

2. Long-horizon client work across sessions. The PersonaMem number (48% → 76%) is about remembering *user-specific* facts across weeks of sessions. In client-project terms: which client prefers Tailwind over CSS modules, which insists on staging deploys before Friday, which decision was reversed in March. My memory files do this today at single-digit scale; they fall over at team scale because there's no conflict resolution — the hub's layered distillation (raw → persona) plus ownership scoping is the structural fix.

3. Token economics on agent-heavy CI. If you run agents in automation — nightly triage, scheduled content pipelines, autonomous fix loops — the −61.38% token reduction claim is the difference between a viable and a silly cloud bill. Symbolic short-term memory (Mermaid-condensed tool logs) attacks exactly the log-dump bloat that makes long agent runs expensive. My own scheduled pipelines re-derive project state every run; a persistent, queryable memory of "what happened last run" is the obvious upgrade, and it's what I'd build into any agent-heavy MVP from day one now.

The pattern across all three: the hub wins where memory needs to outlive one person, one session, or one framework. If your memory problem lives inside a single user's chat history, you're holding the wrong tool.

The comparison none of this week's coverage wrote. These four tools all say "agent memory" and solve four different problems:

The decision rule I'd give a team evaluating this week: Mem0 if you're adding "remember this user" to a product you're shipping — it's a library, lowest integration cost. Zep if your pain is facts changing over time and you need "what was true in March" — the temporal graph is genuinely differentiated. Letta if you want the agent itself to own and edit its memory as a first-class behavior, and you're willing to adopt its framework. TencentDB Agent Memory if the pain is *organizational* — multiple developers, multiple agent frameworks, knowledge that should compound instead of evaporating per-session. It's the only one of the four where "who can see this memory" is a designed-in question rather than an afterthought — and the only one that treats your codebase's structure as a memory asset.

Honest counter-position, because a 15.3k-star trending repo generates more FOMO than fit:

• You're solo. The hub's entire value is the team layer. Alone, Mem0 or even disciplined markdown memory files give you 80% of the benefit with none of the three-service operational footprint. I say this as the person whose duct-tape stack this product replaces: the duct tape is *fine* at n=1.
• You can't staff memory review. The dev.to critique is right about the trust gap: the system stores and shares; it does not adjudicate whether a memory is *correct*, *current*, or *contradicted* by a newer one. Whatever enters shared memory propagates to every agent with equal authority. A stale "we deploy from the main branch" memory is now a team-wide bug generator. If nobody owns curation, the hub amplifies noise with the same efficiency it amplifies knowledge.
• Your stack isn't in the loadout list. First-class support is OpenClaw, Hermes, Claude Code, CodeBuddy. Anything else means writing proxy glue — doable (it's MIT-licensed Node), but you've left the one-command path and entered maintainer territory.
• v2.0.0 is three months from beta. The core pipeline dates to May 2026; the *team* layer is weeks old. Multi-team ACL edge cases, upgrade paths, and data migration have not been battle-tested. I'd run it for a 2–10 person team today; I would not bet a 200-seat enterprise rollout on it this quarter.
• Compliance-sensitive shops need a DPA story first. It's self-hosted (good), but "agent transcripts become searchable team assets" is a sentence your security review needs to sign off on before, not after, adoption.

The wiring the README doesn't cover — the same checklist I apply to production agent builds:

Gate the promote path, not the capture path. Let agents capture candidate memories freely (that's cheap and private-by-default), but make private → team-shared a human action in the Hub panel, ideally by a designated curator per asset type. This single rule converts the trust-gap critique from "fatal flaw" into "manageable review queue." Budget ~15 minutes per developer per week; the payoff is that shared memory stays load-bearing.

Add expiry metadata by convention. The system doesn't adjudicate staleness, so encode it: prefix wiki assets with a reviewed-date, and make anything untouched for 90 days a re-verification candidate before an agent trusts it. This mirrors how I handle my own memory files — recalled memories state what was true *when written*, and the agent re-verifies before acting.

Scrub before capture. Put a secrets filter on the proxy path (even a regex pass for key patterns, tokens, and client identifiers) so credentials never enter chat memory at L0. Retro-deleting from a layered, distilled memory store is much harder than never storing.

Back up the state, test the restore. Three services and their storage now hold your team's compounding knowledge. That's a new single point of failure. Snapshot the deploy volumes nightly and actually restore once — a memory hub you can't restore is a memory you'll re-pay to relearn.

Instrument retrieval hit-rate. Log which memories the proxy injects and whether sessions that retrieved them succeed more often. Tencent's WideSearch/SWE-bench deltas came from their harness; your team's number is the only one that matters, and without measuring you can't tell "the hub is helping" from "the hub is a very organized junk drawer."

The failure mode I'd watch hardest: memory poisoning at team scale. One confidently wrong distilled persona or one obsolete skill, shared team-wide, silently degrades every agent at once — the blast radius of bad context just went from one developer to the whole roster. Everything above is really one principle: treat shared memory like shared code. It gets review, ownership, expiry, backups, and metrics — or it gets incidents.

A team memory hub is infrastructure — the product is what your agents *do* with the compounding context. If you're building an AI-heavy MVP and want the agent architecture (memory, tooling, governance) done right the first time instead of retrofitted after the third incident, that's exactly what I ship: a working product in six weeks, with the boring-but-critical wiring — secrets hygiene, review gates, restore-tested state — included rather than discovered.

• 6-Week MVP Development — scope to shipped product, agent infrastructure included
• Hire a Founding Engineer (India) — senior product engineering, 10+ years, AI-native stack

Or start smaller: run ./start-all.sh on a spare box this weekend, import one codebase, and see what your agents stop re-learning.