Code read at commit badbd21 on 13 October 2026.
The guides and news pages that rank for TencentDB Agent Memory repeat three claims its source code does not support: that it builds memory without any model API, that it runs hybrid vector search out of the box, and that no conversation data leaves the machine. In the shipped setup, every memory layer above the raw transcript is written by a second language model whose example endpoint is DeepSeek's hosted API, and recall is BM25 keyword search because embeddings are switched off. The project itself is a self-hosted memory server that sits between your coding agent and its model as an API proxy, turns conversations into layered notes, and hands the agent a summary at the start of each session plus search endpoints it can call. It is MIT licensed, built by Tencent Cloud's database team, and had about 28,700 GitHub stars on 13 October 2026.
We read the repository at commit badbd21 (release 2.0.3-beta.1, pushed on 13 October 2026), following the write path, the read path and the proxy through the code itself, and we checked the result against the pages that rank for the project's name, including its README, its press release and the guides that rank alongside them. Code-level claims link to the file at commit badbd21. We build Maximem Synap, a managed memory service that competes with it; for one organisation's coding agents that must stay on its own machines, TencentDB Agent Memory is the better choice.
TencentDB Agent Memory runs four services in three containers, with an API proxy in front
TencentDB Agent Memory is four services shipped as three Docker containers. Memory-core (port 8420) holds the conversation memory pipeline, the skill store and the access-control service. Memory-hub combines the admin panel (port 8125) with a knowledge service (port 8424) that builds a Wiki from your documents and a code graph from your repositories. The proxy (port 8096) is an LLM API reverse proxy that speaks the Anthropic Messages, OpenAI Chat Completions and OpenAI Responses formats, which is how it plugs into Claude Code, Codex, CodeBuddy, WorkBuddy, Hermes Agent, OpenClaw and DeepSeek Harness without code changes: you point the agent's base URL at the proxy. The install template lists the ports, and building from source needs Node 22.16 or later.
Storage defaults to SQLite with FTS5 for keyword search and sqlite-vec for vectors, with Tencent Cloud VectorDB as an optional backend and MongoDB marked experimental. Nothing ties it to Tencent Cloud, although the built-in document and code importers target Tencent-internal tools (iWiki and Gongfeng). Its borrowings are credited openly: the code graph is the @colbymchenry/codegraph package wrapped as a service, the skill pipeline adapts code from Hermes Agent, and the Wiki follows Andrej Karpathy's LLM Wiki idea.
A second language model builds the memory, and tool output never reaches it
After each main turn the proxy sends memory-core the user's message (with harness wrappers stripped) and the assistant's text reply, and nothing else. Tool calls and tool results are not part of that write. For a coding agent this is the largest single design decision in the project, because the file paths, commands, stack traces and test output that a coding session actually turns on live in tool results, and the memory pipeline never sees them. A separate, opt-in skill pipeline does read tool calls, but only to draft reusable SKILL.md files, and nothing from it becomes a fact in memory.
Memory is built in four layers. Raw messages land as L0, stored as daily JSONL files and as SQLite rows indexed for keyword search. A language model then extracts L1 "atoms" from them: short, self-contained statements typed as persona, episodic or instruction memories, or as work facts, tasks, methods and artifacts when the code-mode prompt is selected. A tool-using agent rewrites up to 15 markdown "scene" files from those atoms as L2, and a second agent run keeps a single persona file as L3, capped at 2,000 characters (1,200 in code mode).
Building memory needs a language model. There is no rule-based or regex extractor in the code. If extraction is turned off, or no model is configured, the L1, L2 and L3 runs log a skip and return nothing, and the only memory left is the raw L0 transcript. The deployment template requires a memory model endpoint and uses DeepSeek's API as its example. Any OpenAI- or Anthropic-compatible endpoint works, including a local server such as Ollama or vLLM, but the shipped template does not do this for you.
Extraction fires every 5 turns, after 10 minutes of idle time, or on a warm-up schedule of 1, 2, 4 and 5 turns for a new session, and each run reads at most 10 new messages. A run makes one extraction call and up to one deduplication call. Scene updates run at most every 15 minutes per active session and the persona updates after every 50 new atoms or when the scene agent asks for it. A 20-turn session therefore costs roughly four to twelve extraction and deduplication calls plus one to three multi-step agent runs, none of which block the user's turn.
Changed facts are reconciled only within a session. For each new atom, memory-core pulls the five most similar existing atoms by keyword and vector search (there is no similarity threshold) and asks the model, in one batched call, whether to store, update, merge or skip. An update or merge hard-deletes the old rows and writes a new row with a higher version number; no pointer to the replaced fact survives at L1. The comparison is limited to the same session, so when a user says "we moved the API to v3" on Tuesday and "the API is on v2" was recorded the previous week, both atoms stay in L1 and both can come back from search. The scene layer does keep an evolution trail and a section for unresolved contradictions, which makes L2 the only layer that records change over time. Search applies no recency, validity or superseded filter either, so nothing in the read path prefers the newer of two conflicting atoms.
L0 and L1 are kept forever by default; the retention setting defaults to zero days, which means no cleanup.
The model has to search for memories itself, and search is keyword-only out of the box
At the start of a session the proxy writes a block into the system prompt containing the full L3 persona (truncated at 6,000 characters) and an index of L2 scene paths with 200-character summaries. That block is built once and cached for the session, so it does not disturb prompt caching after the first turn. The proxy also adds a text guide telling the model it can use its own shell tool to curl a set of read-only search endpoints on the proxy for L1 atoms, L0 conversations and full scene files.
Per-turn automatic recall, where relevant atoms are attached to every user message, exists in the code but is not registered; the comment beside it says it was retired because it broke the KV and prompt cache. So a specific fact reaches the model only when the model decides to search, writes a curl command, runs it through its tool loop and reads the result. That costs a full tool round trip, and an agent without a shell tool, or without network access to the proxy, cannot search at all.
Out of the box, search is BM25 keyword search only, although the code fuses BM25 and vector results by reciprocal rank fusion, with k set to 60, equal weights, five results by default and no reranker. The shipped Docker deployment sets the embedding provider to none, and the config loader turns a "local" embedding provider into "disabled" with a message asking for a remote one. GreenNode's integration write-up hit exactly this: hybrid recall returned an error without an embedding service, and they fell back to keyword search. BM25 also defaults to Chinese tokenisation; English deployments should set bm25.language: en.
If memory-core is unreachable, the proxy passes the original request through without memory, so the agent keeps working.
Conversation text leaves the machine through the memory model
The "fully local, nothing leaves the building" framing in several articles is half right. The storage is local and there is no vector database subscription. Telemetry to Langfuse, Opik, ClickHouse and Kafka is off by default and needs endpoints you supply. But in the shipped setup, conversation text goes to the memory model in batches of up to 10 messages for extraction, scene and persona summaries go to it for L2 and L3, and imported documents go to it in chunks of up to 12,000 characters to build the Wiki. If that endpoint is a hosted API, a second provider now receives your conversations alongside the one your agent already uses. The proxy also forwards every agent request to its upstream model, so the setup is only as local as that upstream.
For agent memory to be private in the sense the coverage implies, three things have to run on your own hardware: the memory model, the embedding model, and the agent's own model. TencentDB Agent Memory can run the memory model and the embedding model on your hardware (or run with embeddings off), and the agent's own model is your choice.
There is no PII handling of conversation content anywhere in the code. The only redaction we found masks API keys and tokens in logs. User text is stored exactly as written, sent unchanged to the memory model, and the persona layer exists to build a profile of the user. We found no encryption at rest for memory data, and while delete endpoints exist for conversations and atoms, there is no export-and-erase workflow for a data-subject request. Articles pitching the project for HIPAA or GDPR workloads are describing where the files sit; the code has no compliance feature.
Access control is enforced inside memory-core and thinner around it
Memory-core has a real access-control model, enforced on the server: assets are private to their owner (team admins included), shared with the team, restricted to named users, roles or agents, or bound to specific agents, and the permission checker fails closed.
Around memory-core, the services are looser. The memory-core gateway's bearer key is left empty in the deployment template, and in the default setup several read paths in the proxy and the knowledge service depend on network isolation, with no authentication check of their own. Keep all four services on a private network, and do not expose the proxy port beyond the machines that run your agents.
Neither the PersonaMem result nor the token savings can be reproduced from the repository
The README's one benchmark row, PersonaMem accuracy of 48% without the project and 76% with it (labelled as a 59% relative gain), compares against no memory and cannot be reproduced from the repository. The 48% is not another memory product's score, although at least one guide presents it as Mem0's, and (76 − 48) ÷ 48 is 58.3%. The repository contains no script, dataset split, model name or configuration for the run.
Token-saving figures of 30% to 61% that appear in several pages (from WideSearch, SWE-bench and AA-LCR runs on OpenClaw) come from the 1.x README. They are not in the current README, and the public git history starts after them, so there is nothing left in the repository to check them against.
Plan for a beta: no committed tests and four setup traps
The public git history begins at the 2.0.0-beta.1 release on 22 July 2026, so the 1.x code behind earlier coverage is not in the repository. No test files are committed, even though the package scripts refer to them, and the CI workflow checks that the package builds and runs no behavioural tests. Version labels disagree across the README (2.0.0), the roadmap (2.0.1-beta.1), the latest tag (2.0.3-beta.1) and the memory-core package (1.0.2-beta.1).
Plan for these four setup traps: embeddings off by default, Chinese keyword tokenisation by default, a team-and-agent picker that can interrupt the first turn of a session unless the team, agent and task headers are set, and an agent that needs a shell tool with network access to the proxy for any memory search. Teams on 1.x get a migration tool. For integrating from your own application there is an HTTP API for conversations, atoms, scenes, persona and skills; note that it has no endpoint to create a new atom directly, so new facts only enter L1 through model extraction. A separate context-offload feature for long sessions also ships, switched off by default.
Team memory, the Wiki and the code graph are the strongest part of the project
You create teams and agents in the panel, then give each agent a loadout of assets: a chat memory, a set of skills, a Wiki built from product documents, and a code graph for the repositories it works on. Cold start is handled by importing existing repositories, documents and past agent sessions. Skills are versioned, private by default and shared after review, so an agent does not run an unreviewed skill. The code graph answers callers, callees and impact questions before an agent edits code, which a conversation-memory product does not attempt. Asset routing to agents is still manual, and the code graph handles public HTTPS repositories best, both of which the README notes itself.
Seven of nine published claims do not hold against the code
| Claim in published coverage | What the code at commit badbd21 does |
|---|---|
| Builds memory with no model API | Needs a memory model for every layer above raw transcripts; the template's example is DeepSeek's API |
| Hybrid vector and keyword recall by default | Embeddings off in the shipped deploy; local embeddings disabled in config; recall is BM25 only |
| Recalls relevant memories before every turn | Per-turn recall retired to protect the prompt cache; the model must search through curl |
| Captures tool calls and their output | Captures the user message and the assistant's text; tool output only reaches the opt-in skill pipeline |
| Nothing leaves the machine | Conversation text goes to the memory model; requests go to the upstream model |
| Suitable for HIPAA or GDPR data | No PII handling, no encryption at rest, unlimited retention by default |
| PersonaMem 48% to 76% | No reproduction code; 48% is a no-memory baseline |
| Self-hosted, MIT, SQLite, no vector database subscription | Accurate |
| Team-level sharing with access control | Accurate, enforced in memory-core |
A proxy saves integration work and costs you control over what is remembered
Putting memory in the request path is what makes TencentDB Agent Memory zero-code, and it is a real advantage when you want the same memory behind several off-the-shelf agents. The cost is that the proxy sees every request, holds or forwards your model API keys, depends on the model choosing to search for anything beyond the session-start summary, and decides what to capture from the traffic it can parse, which here excludes tool output. SDK-based layers such as Mem0 and Zep ask for code changes, and in return your application decides exactly what is written and when context is fetched, with nothing intercepting the model call.
Maximem Synap scopes memory per customer, controls sensitive data, links changed facts and pre-fetches recall
Maximem Synap is a managed memory service your application calls from an SDK. It does not proxy your model calls, so your agent keeps talking to its model directly. The two products overlap on conversation memory and differ on almost everything around it.
| TencentDB Agent Memory | Maximem Synap | |
|---|---|---|
| Deployment | Self-hosted, three containers, MIT | Managed cloud; self-hosted and air-gapped for enterprise engagements |
| Integration | Base-URL proxy, no code | SDK (Python, TypeScript), REST, hosted MCP, 23 framework integrations |
| Scoping | Team, user, agent and task, with private, team, restricted and agent visibility | Client, customer and user, plus conversation, assigned when a memory is written; nested ladders as an extension |
| Sensitive data | None for content; secrets masked in logs | Detected per kind of data, with control over storage, whether the model provider sees it, and what each API key can reveal; payment details, keys and PINs never stored |
| Changing facts | Merge within a session; both kept across sessions | Old fact linked to its replacement; a poorer replacement does not overwrite a richer fact |
| Consolidation | Scene and persona rewrites on timers | Meditation every few hours, Nap daily, Sleep in quiet hours with consolidation and conscious forgetting |
| Recall | Model-issued curl search; BM25 by default | Context pre-fetched into an in-process cache while the conversation runs |
| Published accuracy | PersonaMem 48% to 76%, no reproduction code | 92% LongMemEval and 93.2% LoCoMo, reproduced on our open harness |
| Docs and code memory | Wiki and code graph | Not offered |
Synap assigns scope when a memory is written, not when it is read, and visibility flows one way: a user-scoped fetch can draw on customer-wide and client-wide memory, and a customer-scoped fetch never reaches into an individual user's memory. That is the property a B2B product needs when one deployment serves many customers. TencentDB Agent Memory scopes by team, user, agent and task, which fits one organisation's own teams and agents.
Synap finds sensitive values in the content it receives and applies the treatment you choose per category, including showing the model an alias in place of the real value, as described in the sensitive data guide. Seven field types, such as full card numbers, passwords and private keys, are never stored under any setting.
The 92% on LongMemEval is 460 of the 500 questions in LongMemEval_S; the 93.2% on LoCoMo covers categories 1 to 4 of locomo10 (1,540 questions) and excludes the adversarial category 5. Both use gpt-5-mini as the answer model and as the judge, both were published in arXiv 2607.21503 on 23 July 2026, and the harness and run outputs are public, with configuration on our evals page. We report the most-reproduced result across runs and have not yet published the run count or spread. In-conversation retrieval returns in under 15ms at P75 because reads are served from the cache Synap fills ahead of time inside your process; that is a different measurement from a cold search, and different again from TencentDB Agent Memory's recall, which includes a model tool round trip.
Choose TencentDB Agent Memory if you want everything on your own machines, your agents are coding agents with a shell tool, you want docs and code graphs alongside chat memory, and your users are your own team. Choose Synap if you are building a product that serves many customers, need sensitive-data controls a security reviewer can inspect, need facts to stay current across sessions, or need recall inside a latency budget such as a voice turn.
Test stale facts and tool-output facts before you commit
Replay 50 real conversations through the proxy as separate sessions, with one fact that changes between sessions and one fact that only ever appeared in tool output. Then ask questions with and without the entity's name, and count three things: answers that return the stale value, answers that miss the tool-output fact, and how many searches the model ran to answer. Run it once with embeddings off, as shipped, and once with an embedding server configured, and set bm25.language to match your users. If you are building a product for your own customers, run the stale-fact test first, since cross-session reconciliation is where the current pipeline is thinnest; if the agents are your team's coding agents, start with the tool-output test.
Frequently asked questions
Is TencentDB Agent Memory fully local?
The storage is local, but building memory needs a language model, and the shipped template points at a hosted API. It is fully local only if the memory model, any embedding model and the agent's own model all run on your hardware.
Does TencentDB Agent Memory need an LLM?
Yes, for every layer above the raw transcript. Without one it keeps L0 conversations and supports keyword search over them, and nothing else.
Does TencentDB Agent Memory use a vector database?
It supports sqlite-vec and Tencent Cloud VectorDB, but the shipped deployment turns embeddings off, so recall is BM25 keyword search until you configure a remote or self-hosted embedding endpoint.
Does TencentDB Agent Memory handle PII?
No. It masks API keys in logs and stores and forwards conversation content unchanged.
Is the PersonaMem result reproducible?
Not from the repository, which contains no evaluation code, data or configuration for it.
How is it different from Mem0?
TencentDB Agent Memory is a proxy that needs no code changes and adds team sharing, a Wiki and a code graph; Mem0 is an SDK your application calls, so your code decides what is stored and when it is fetched.
Is it the same as Tencent Cloud's "agent long-term memory" for PostgreSQL?
No. That Tencent Cloud document describes a pattern on TencentDB for PostgreSQL, a managed database product, and is unrelated to this open-source repository.
