TencentDB Agent Memory Review: Layered Memory for AI Agents, What the Benchmarks Really Show, and When to Use It

TencentDB Agent Memory is an open-source memory layer that lets coding and work agents remember project context, decisions and procedures across sessions, across agents and across a team. It works mainly by sitting between the agent and its model as a proxy, injecting relevant memories into each request and writing each turn back into a layered store. The design is sound and in places clever, especially its insistence that every summary keeps a path back to the raw evidence. The benchmark section is weaker than its 29,700 GitHub stars suggest. The headline "+51.52%" is one benchmark moving from 33% to 50%, no run counts or models are given, and two of the token savings do not recompute from the README's own table. Our view: the architecture is worth learning from and worth piloting for teams that repeat themselves to agents, as long as you review it like what it is, a service that reads every prompt your engineers send.

Two products under one name

The repository has two branches that describe two different products, which explains why screenshots of it disagree.

The main branch describes an OpenClaw and Hermes plugin built on "symbolic short-term memory plus layered long-term memory". In long tasks it offloads bulky tool output (search results, code, error traces) to files and keeps only a compact Mermaid graph of the task state in context, with node IDs the agent can use to fetch the full text. This is the README with the widely shared benchmark table.

The default branch, feat/server_team (v2), describes a team memory hub. A proxy fronts the agent's model calls, and four kinds of memory assets are managed in a web panel: Chat Memory (preferences, facts and decisions), Skills (versioned procedures with triggers and validation rules), a Wiki built from documents, and a CodeGraph built from repositories. Assets have owners, versions and visibility levels (private, team, restricted by user, role or agent ACL, and agent), and new memories are private by default. Its README keeps only one benchmark row. The changelog and roadmap place the current release around v2.0.x.

Both share the same long-term idea, so we cover the architecture once.

How it works

Architecture source: the team-branch README, which describes the proxy and shared memory service.

Layering. Raw conversation (L0) is kept intact. An asynchronous pipeline distills it into atomic facts, preferences and constraints (L1), scenario blocks around a project (L2) and a persona of stable patterns (L3). Upper layers are stored as human-readable Markdown, lower layers in a database for full-text search. Recall serves the compact upper layers by default and drills down with BM25 plus vector search, fused by reciprocal rank fusion, when a specific fact is needed. Results are capped by item count, characters per memory, total characters and a timeout (5 seconds by default in the recall code).

Traceability. Every upper-layer item keeps a path down to the evidence it came from. This is the part we would copy into any memory system. A summary you cannot trace back to its source is a rumor. When a persona fact turns out to be wrong, you need to find the conversation that produced it, and when a customer asks you to delete something, you need to remove it from every layer derived from it.

Assets, not just chat. Skills are distilled from successful conversations and tool calls, with versions and trigger boundaries. Wiki pages and CodeGraph indexes are exposed as tools (/v3/tools/list, /v3/tools/call) rather than pasted into context, so a document enters the prompt only when the agent asks for it. The acknowledgements say the CodeGraph module uses code from colbymchenry's codegraph project and the Skill module builds on Hermes Agent's.

Symbolic short-term memory (the main branch). Instead of keeping fifty tool outputs in the context window, the agent keeps a small graph of what it did and where each raw result was saved. Keep the pointer, not the payload. Mermaid is one way to encode that graph; the important design choice is that every node has an ID that retrieves the full text on demand, so compression never destroys information. This is the same principle behind file-based scratchpads in long-running coding agents, and it is a good one.

The benchmarks, recomputed

The main README reports four results "when integrated with OpenClaw". We recomputed every derived number from the table itself.

Benchmark source: the main-branch README. These plugin results are distinct from the newer team proxy described above.

Four observations.

The headline is relative and comes from one benchmark. "Improves pass rate by 51.52%" is WideSearch moving from 33% to 50%. The same plugin adds 5.8 points on SWE-bench and 3.5 on AA-LCR. A relative gain on a low base is a marketing number; points are the engineering number. Both are true. Only one tells you what changes for your users.

Two token figures do not match their table. WideSearch's reduction recomputes to 61.30%, not the 61.38% in the headline, and SWE-bench's to 31.63%, not 33.09%. These are small errors, and they matter because they suggest the table and the prose were computed from different runs or edited separately. When a headline number does not recompute from the table beside it, trust the table and ask which run produced the headline.

There is no sample size, variance or model. The README does not say how many tasks were run, how many times, with which model, or what the spread was. A 3.5-point gain on AA-LCR could be noise. The default branch now keeps only the PersonaMem row, also without setup.

The SWE-bench setup favors the plugin. The README says SWE-bench "runs 50 consecutive tasks per session to simulate the context-accumulation pressure of real-world long-horizon agents". That is a valid stress test of a memory system. It is also a baseline that carries fifty tasks of history in one session, which few production harnesses do without compaction. Some of the 31.63% token saving is the plugin doing what a basic context-reset policy would also do. The fair comparison is against a baseline with ordinary compaction.

None of this means the system does not work. It means the published evidence cannot tell you how much it will help you, and you will need your own measurement.

What a memory proxy does to your data and your bill

Routing every model call through a memory proxy has consequences that the README's "zero-code integration" undersells.

It reads everything. The proxy sees every prompt and response, including source code, stack traces and any secret an engineer pastes. By default the proxy configuration enables injection (skills, knowledge tools and memory blocks added to the system prompt) and extraction (each turn's user query and assistant reply written into L0). A memory proxy is a man-in-the-middle you chose. Review it like one.

It sends conversations to a second model. The deployment template has two sets of model settings: one for the proxy's upstream and one for the memory service's own summarization and embedding. They can be different providers. Your data-processing review must cover both.

It changes prompt caching. Recalled memory is injected into the system prompt, which is usually the stable prefix that prompt caching depends on. If the injected block changes from request to request, the cache misses and you pay full price for the whole prefix every call. The project's own configuration warns that a misconfigured multi-node deployment makes the upstream Anthropic cache miss every time. Put stable instructions first and the memory block after them, and measure your cache hit rate before and after.

It pulls latest images by default. The quick-start template uses :latest tags from Docker Hub, and the script reuses a local latest without checking for updates. Pin versions for anything beyond a laptop trial.

Pros and cons

When it is worth it

Good fits. Teams where several people and agents repeatedly explain the same architecture, conventions and decisions. Agencies and forward deployed teams working inside one customer's codebase for months, where the cost of re-teaching each new session is real. Support and operations agents that need stable facts about a customer across conversations.

Poor fits. Single developers with one agent, where a well-kept AGENTS.md or project notes file does most of the job for nothing. Fast-changing facts, where a stale memory confidently injected is worse than none. Regulated data, until the proxy, the memory model's provider and retention have been reviewed.

How we would pilot it. Run it for two weeks on one team, private memories only. Measure three things: tokens per completed task, the share of sessions where someone re-explained context the memory should have supplied, and how often an injected memory was wrong or stale. Promote memories to team scope only after a person reviews them, add a delete path that reaches every layer, and compare against the cheapest alternative, a curated project notes file plus the agent's built-in compaction. If the proxy does not beat that by a clear margin, the notes file wins.

For FDEs, memory design is now a regular interview topic: what to store, at what granularity, how to retrieve it, how to keep it from going stale and how to delete it. The layered model here is a good reference answer. Read our agent memory concept, the post on how context engineering replaced prompt engineering, and practice with our RAG and agent questions.