TencentDB Agent Memory is Tencent's open-source memory hub for AI agents, a self-hosted stack that turns your chat history, documents and codebases into reusable memory assets your coding agent loads at the start of every session. It is the hottest repository on GitHub today, adding roughly 1,900 stars in a single day on top of more than 15,000 total, on the back of the v2.0.0 release that landed on August 3, 2026. Setup is a Docker job: about fifteen minutes from clone to a running panel, assuming you already have an OpenAI-compatible API key to point it at.

  • One script boots all three services: Memory Core, Memory Hub and the Proxy, on ports 8420, 8125 and 8096.
  • Coding agents connect by swapping their API base URL for the local proxy, so Claude Code, CodeBuddy, OpenClaw and Hermes all work without a plugin.
  • Memory is stored as four asset types with real ownership and access control: Chat Memory, Skill, Wiki and CodeGraph.
  • MIT licensed, no external API dependency beyond the LLM endpoint you supply, and every asset is private by default until you share it.
How TencentDB Agent Memory sits between a coding agent and its modelCoding agents such as Claude Code, CodeBuddy, OpenClaw and Hermes send requests to a local proxy on port 8096. The proxy authenticates the user key, asks which team and agent the session belongs to, and injects memory before forwarding upstream. Memory Core on 8420, the Knowledge service on 8424 and the Memory Hub panel on 8125 store four asset types: Chat Memory, Skill, Wiki and CodeGraph. CODING AGENTS PROXY :8096 MEMORY SERVICES Claude Code CodeBuddy OpenClaw Hermes, OpenAI API auth: user key pick team, agent inject memory forward upstream Memory Core :8420 Knowledge service :8424 Memory Hub panel :8125 SQLite plus vector search MEMORY ASSETS, GOVERNED IN THE HUB Chat Memoryfacts, prefs Skillreusable how-to Wikidocs, link graph CodeGraphsymbols, callers Raw chat lands at L0, workers distil L1 atoms, L2 scenes, L3 persona Each agent gets the loadout its ACL allows, not the whole database genztech.blog
Fig 1 Nothing plugs into your agent. The proxy sits in front of the model, authenticates you, works out which agent identity this session belongs to, and blends the right memory into the system prompt on the way past.

What is TencentDB Agent Memory and why is it trending?

It is a self-hosted memory layer for AI agents, MIT licensed, that answers a question most memory tools skip: not just what can be recalled, but who is allowed to use it, which version is current, and which agent should receive it. Tencent open-sourced the first version in May 2026 as a layered memory pipeline. What pushed it to the top of trending this week is v2.0.0, published August 3, which turned a single-agent plugin into a team hub with users, teams, agents, review workflow and access control lists.

RelatedOpenCut Setup: Self-Host the Free CapCut Alternative

The mental model is a save file. Conversations are stored raw as L0, then background workers distil them upward: L1 atoms are individual facts and constraints, L2 scenarios group them by project, L3 is a stable persona. Retrieval starts at L2 and L3, falling back to BM25 plus vector search when a specific fact is needed, with hard caps on item count, characters and timeout so memory does not eat the context window it exists to save. The published benchmark is PersonaMem: 48 percent without it, 76 percent with it. Treat that as a vendor number until someone outside Tencent reproduces it.

How do you install the full stack on macOS or Linux?

The recommended path boots all three services in one command. You need Docker (Docker Desktop, colima or OrbStack) and bash. The deploy README lists macOS and Linux only, so on Windows run this inside WSL2 with Docker Desktop's WSL backend, not PowerShell.

# 1) Fetch the scripts
git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images

# 2) Prepare .env (fill in real LLM values)
cp .env.example .env
$EDITOR .env

# 3) Dry-run validation, includes a live LLM probe
./verify.sh

# 4) One-shot boot
./start-all.sh

The .env file wants two independent sets of credentials, and this is the step people get wrong. The MEMORY_LLM_ trio is what the memory and knowledge services call internally for embedding, summarising and wiki ingest. The PROXY_UPSTREAM_ trio is the model your agent actually talks to. They can point at the same provider or different ones, and a cheap OpenAI-compatible endpoint on the memory side is the sensible split.

On first boot the script creates an admin user and writes a random 32-character key to ./.admin-key. Four ports come up: 8420 Memory Core, 8125 panel, 8424 knowledge, 8096 proxy. Open http://localhost:8125, log in with the sk-mem- key, and create at least one Team and one Agent before going further. Memory attaches to a team, agent and task triple, and an empty picker later is almost always this step being skipped.

How do you point Claude Code at your team memory?

There is no plugin to install. You redirect the agent's API base URL at the local proxy and use your memory user key as the auth token:

# route Claude Code through the proxy
export ANTHROPIC_BASE_URL=http://127.0.0.1:8096/claude-code/default
export ANTHROPIC_AUTH_TOKEN="$(cat ./.admin-key)"
claude --model <whatever PROXY_UPSTREAM_MODEL is set to>

The trailing default is the memory instance ID and stays default on a local deploy. On the first turn of every new session the proxy uses Claude Code's native question tool to walk you through three picks: team, agent, then an optional task. Every turn after that gets that agent's L2 and L3 memory, skills and knowledge injected into the system prompt, while raw dialogue lands in Memory Core's SQLite store. The binding is per session, so switching agent mid-work means starting a fresh one. To confirm the pipeline is doing work rather than just proxying:

curl -s http://localhost:8420/health | jq .services.pipelineWorker

Expect tasksConsumed and tasksCompleted to climb as you talk. CodeBuddy uses the same proxy on a /codebuddy/default path via ~/.codebuddy/models.json; OpenClaw and Hermes use their own config files plus x-team-id, x-agent-id and x-task-id headers. If Memory Core already runs elsewhere, the panel ships as its own image: docker pull docker.io/agentmemory/memory-hub:latest.

How does it compare with Mem0, Zep and Letta?

TraitTencentDB Agent MemoryMem0ZepLetta
ShapeSelf-hosted memory hub plus proxyMemory layer SDKTemporal knowledge graph serviceStateful agent runtime
Unit of memoryTeam, agent and taskUser or agentUser and session graphAgent memory blocks
Docs and code as assetsWiki plus CodeGraph built inBring your ownBring your ownBring your own
How agents connectAPI base URL swap, no SDKSDK calls in your appSDK or API callsRun agents on the runtime
Sharing controlsPrivate, team and ACL built inApp-levelApp-levelApp-level

The table is qualitative on purpose, because these tools are not competing for the same slot. Mem0 bolts personalisation onto an app you are writing; Zep is strongest when facts change over time; Letta is a runtime, not a bolt-on. TencentDB Agent Memory is the only one whose primary unit is a team rather than a user, and the only one treating a codebase as a first-class memory asset. For a solo developer it is heavier than you need. For four agents all relearning the same repo, that weight is the point.

RelatedSuperpowers Setup: Give Your AI Coding Agent a Real Workflow

What are the gotchas before you rely on it?

Five worth knowing. First, this is a Docker stack with an LLM bill attached: the memory side calls your model to embed and summarise in the background, so a cheap endpoint there is the difference between a hobby deploy and a surprise invoice. Second, Wiki and CodeGraph build asynchronously, so an import that looks broken is often just working. Third, CodeGraph currently prioritises public HTTPS repositories, with private repos and SSH credentials still being refined, an awkward limit for exactly the teams this targets. Fourth, memory routing is manual: automatic routing is still on the roadmap. Fifth, Hermes and OpenClaw need x-task-id and a hand-managed x-conversation-id today, both of which the project says become optional next release.

One more, less technical. The proxy sits in front of every prompt your agent sends. It is MIT licensed and self-hosted, so nothing forces traffic anywhere you did not configure, but a component that rewrites system prompts deserves a source read rather than trust.

What to watch · 2026
  • Automatic memory routing. Manual binding is the friction ceiling right now. Whether the hub can decide what an agent needs without a human picking is the difference between a control panel and a chore.
  • Private repo support in CodeGraph. The public-HTTPS-only limit blocks the enterprise teams the governance features are clearly built for.
  • Independent PersonaMem numbers. A 48 to 76 percent jump is a big claim. Reproduction by someone outside Tencent is what turns it into evidence.

Our take

The interesting design decision here is not the memory pipeline, which resembles what everyone else in this space converged on this year. It is the proxy. By intercepting at the API boundary instead of shipping an SDK or a plugin, the project sidesteps the integration problem that has kept agent memory stuck in demos: you never modify the agent, and swapping frameworks costs a config line rather than a rewrite.

The second bet is that memory is a permissions problem, not a storage problem. Ownership, versions, visibility tiers and agent bindings decide whether a memory system survives contact with a second person, and most open-source memory tools skip all of it. Roughly 1,900 stars in a day suggests plenty of teams already learned that the expensive way.

Primary sources

Original analysis by GenZTech. Tool documentation: TencentCloud/TencentDB-Agent-Memory on GitHub.