TencentDB Agent Memory Guide: Test Local Memory with OpenClaw

The most frustrating part of a long-running side project is often not the model's intelligence. It is having to explain the architecture, preferences, and current progress every time the agent starts over. Meanwhile, a manually maintained MEMORY.md keeps growing. TencentDB Agent Memory aims to solve this problem, but the phrase “local memory” is easy to misread. This guide is based on the official documentation. I did not install the product while writing it, so I will not present vendor tests as first-hand results.

First, check whether you meet the entry bar. This is for readers who already self-host OpenClaw or Hermes, or who are willing to maintain a Gateway. If you only use the standard ChatGPT, Claude, or Notion interfaces and do not manage your own agent runtime, this plugin is not currently a low-friction memory tool for you.

TL;DR

• SQLite by default means memory data can stay on your machine. It does not mean extraction and search never call an external model.
• The key difference is its L0-to-L3 memory hierarchy and the traceable path from a Persona back to the original conversation, not simply another vector database.
• Start with an isolated agent, SQLite, and keyword search. Consider embeddings or a cloud backend only after cross-session recall proves useful.
• If your tasks are short, usage is infrequent, or MEMORY.md already works, another stateful service is unlikely to be worth maintaining.

What Does “Local” Actually Mean?

TencentDB Agent Memory's local mode uses SQLite plus sqlite-vec as the memory backend. That answers where the data is stored, not which content a model processes. Long-term memory extraction still requires an LLM, and whether embeddings leave the device depends on your configuration.

Before installing anything, split the data flow into four stages. That gives you a much clearer risk picture than a “local-first” label.

Stage	Content processed	Default or optional destination	Question to ask before installation
Conversation capture	Raw conversation	Local L0 files and SQLite	Is customer data allowed to be captured?
Memory extraction	Conversation converted into Atom, Scenario, and Persona records	OpenClaw host model or a separately configured LLM	Is the model a remote API, and what text is sent?
Memory storage	Layered memories and indexes	SQLite by default, with TCVDB as an option	Where are the data path, permissions, and backups?
Memory recall	Keyword, embedding, or hybrid queries	Local keyword search or the configured embedding provider	Does query text leave the device?

If any part of that flow is unacceptable, do not test with real customer content. Start with a non-sensitive side project. It is the cheapest risk control available.

More Than a Chat Log: How L0 to L3 Works

The official design divides memory into four layers. L0 contains raw conversations. L1 contains self-contained atomic memories. L2 organizes related memories into scenarios, and L3 forms a Persona. Higher layers give the agent quick context, while lower layers retain the evidence trail.

Layer	Main content	Best suited for	Most common risk
L0 Conversation	Raw conversations	Reconstructing context and tracing evidence	Sensitive information is retained in full
L1 Atom	A single preference, fact, or decision	Technical choices and stable preferences	Incorrect extraction or stale information
L2 Scenario	A group of related situations	Project workflows and recurring contexts	Separate contexts are merged incorrectly
L3 Persona	High-level user profile	Long-term collaboration patterns	Bias is hardened into “this is who you are”

Traceability is the useful part. When an agent insists that you prefer a particular framework, you should be able to move from Persona to Scenario, then Atom, and finally the original Conversation. That lets you determine whether the source was misread, the summary was wrong, or the information is simply outdated. Plain Markdown is easier to inspect manually, but you must manage loading and updates yourself. A four-layer pipeline automates more of that work while adding state that must be governed.

If you are still choosing a memory approach, start with this overview of AI agent memory architecture before enabling automatic capture.

Who Should Install It, and Who Is Better Off with MEMORY.md?

Start by separating three approaches. OpenClaw built-in memory indexes MEMORY.md and memory/*.md, with keyword, vector, and hybrid search. TencentDB Agent Memory adds conversation capture and the L0-to-L3 extraction pipeline. Both may use SQLite, but they solve different problems.

Approach	How memories are created	Search	Main maintenance work	Best suited for
Manual MEMORY.md	Written and edited by a person	Read directly by the agent or indexed by the host	Maintain the text and loading rules	Small memory sets where full control matters
OpenClaw built-in memory	Indexes MEMORY.md and memory/*.md	Keyword, vector, hybrid	Manage files, embedding provider, and index	Existing Markdown memory that mainly needs better search
TencentDB Agent Memory	Captures conversations and extracts L0 to L3 automatically	Keyword, embedding, hybrid	Manage extraction, scheduling, layered data, backups, and versions	Repeated cross-session context with a need to trace memory sources

Your situation	Recommendation	Why
You repeat the same project context several times a week	Run a trial	The recurring cost is clear and improvement is measurable
Long sessions often lose early decisions under context pressure	Run a trial	Layered memory may be easier to manage than reloading the full history
You need to trace a preference back to its original conversation	Run a trial	The traceability chain directly matches the requirement
A task ends after one or two sessions	Hold off	The database and scheduling overhead is unlikely to pay back
A short MEMORY.md already works reliably	Keep it simple	It is readable, versionable, and has fewer failure modes
You cannot manage backups, permissions, and periodic checks	Do not use production data	Long-term memory accumulates, and unmanaged data only postpones the problem

GitHub popularity is not an adoption threshold. The numbers that matter are how many times you repeat context each week and whether you are willing to own backups, deletion, upgrades, and correction of bad memories.

A Minimal OpenClaw Trial Without Installing Everything at Once

The shortest OpenClaw path in the current official documentation is to install the npm plugin, restart the Gateway, and enable memory-tencentdb. Before publication, I cross-checked the package name against the official README and npm page. OpenClaw and the plugin both change, so read the current README and CHANGELOG before running these commands.

openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
openclaw gateway restart

Next, edit ~/.openclaw/openclaw.json, the location specified in the official README. With only enabled: true, the official schema defaults the recall strategy to hybrid, while the embedding provider defaults to none. That is not the pure keyword baseline used here, so set both fields explicitly for the first trial:

{
  "memory-tencentdb": {
    "enabled": true,
    "config": {
      "recall": {
        "strategy": "keyword"
      },
      "embedding": {
        "provider": "none"
      }
    }
  }
}

Limit the first trial to three choices: a test profile, the default SQLite backend, and explicit keyword search with embeddings disabled. Short-term offload, TCVDB, and remote embeddings all add variables. Add them only after basic writes and recall are stable.

After restarting the Gateway, first confirm that a new session loads the plugin, then run the cross-session test below. OpenClaw's log commands and output format may vary by version, and the official README currently does not provide one universal load-check command. If the plugin does not appear in startup results or captures nothing, consult the matching README, manifest, and Issues. Do not use memory-tencentdb-ctl health, which belongs to the standalone or Hermes path, as an OpenClaw acceptance command.

Version compatibility is a practical hazard. When rechecked on October 3, 2026, npm latest was 1.0.3. The official 1.0.3 release notes say it fixes an OpenClaw 9.5 install race that could omit enabled, plus sqlite-vec loading failures caused by the newer package layout. If you are moving from 1.0.1, back up your data, pin 1.0.3, and confirm after restart that the plugin is enabled and has not degraded to non-vector search. Do not paste patch commands from an old tutorial into a new environment.

Five Acceptance Steps to Prove Cross-Session Memory Works

“Plugin enabled” only proves that loading succeeded. It does not prove that capture, extraction, aggregation, and recall all work. Test with a non-sensitive fact that is easy to judge, such as: “The release branch for this test project is pilot-release, and every merge requires a dry run first.”

1. Write: State the project rule clearly to the test agent, and record the time and session.
2. Wait for extraction: Wait for the L1 pipeline according to your settings. Check logs or readable memory files instead of guessing when it finished.
3. Recall in a new session: Ask only, “What should happen before merging this project?” Do not put the answer in the question.
4. Trace the evidence: Find the Atom and original conversation behind the recalled result, then confirm that both content and source are correct.
5. Correct and disable: Deliberately change the rule and verify that the old information can be identified. Disable capture and confirm that it no longer continues.

Record five fields for every test: correct recall, missed recall, false recall, wait time, and number of manual corrections. A single success tells you little because you cannot know whether recall is stable or merely matched a keyword by chance.

Keyword or Embeddings? Decide with Your Own Ten Questions

Keyword search remains available without embeddings. The OpenClaw plugin manifest lists keyword, embedding, and hybrid recall strategies, and states that embedding.provider: "none" disables vector search. The BM25 fallback and embedding-disable commands in the official CTL documentation apply to the standalone or Hermes path, not directly to OpenClaw. This gives you a low-complexity baseline.

Prepare ten questions, but do not repeat the original wording in all ten. Keep the original keywords in five questions. Paraphrase the other five, such as replacing “release branch” with “Which branch should changes be merged into before production?” Record:

• Whether the correct answer appears in the top five
• Whether rules from another project are retrieved
• Query latency
• Any additional API cost
• Whether query content is sent to an external provider

If keyword search is already reliable, there is no reason to enable embeddings just to make the setup feel “more AI.” Test hybrid only when semantic paraphrases keep failing and you accept the added data flow and cost. The official documentation did not let me confirm whether every embedding configuration change requires rebuilding an existing index, so follow the documentation and migration prompts for the version you installed.

Production Risk Map: Wrong, Full, or Leaked Memories

Long-term memory is not a set-and-forget feature. It continually collects data and feeds model-generated extractions into later conversations. Before using it in production, check at least these six items:

1. Retention: Understand what the default l0l1RetentionDays means and whether it matches your retention policy.
2. Recall budget: Use maxCharsPerMemory and maxTotalRecallChars to limit each injection so memories do not fill the context window.
3. Agent isolation: Use excludeAgents to exclude test, evaluation, and sensitive agents that should not be captured or recalled.
4. Backup and rollback: Back up the data directory and configuration, then verify restoration from a copy rather than merely checking that files were copied.
5. Gateway security: If you use a standalone Gateway, review its bind address, authentication, CORS, and credential permissions.
6. Human review: Periodically inspect Persona and Scenario records, delete stale preferences, and investigate conclusions with no source.

The official CHANGELOG has documented fixes involving scene rollback, cleaner safeguards, recall character budgets, Bearer authentication, and OpenClaw compatibility. Those fixes are useful transparency. They also show why state cleanup and network boundaries should not be left to defaults.

Three other boundaries cannot be inferred from feature names. The official schema confirms that the plugin captures conversations, calls the host LLM, and uses either local SQLite or a remote service depending on configuration. It does not promise workspace sandboxing or prove that ordinary users can see only their own memories. Its fields and CHANGELOG provide clues about timeouts, warning logs, backups, and rollback, but do not prove that every interruption is automatically retried, checkpointed, or protected from duplicate writes. If you require an audit trail, record-level export, or verifiable deletion, test all three before production. Keep the system limited to a non-sensitive isolated agent if any test fails.

How to Read the Official Benchmarks and Run Your Own A/B Test

The official npm page lists long-session tests using WideSearch, SWE-bench, AA-LCR, and PersonaMem, and explicitly distinguishes them from single-turn tasks. These are vendor-reported results. There is not enough independent reproduction evidence for me to extrapolate them into a claim about how many tokens your project will save.

The benchmark is more useful as a test design. Keep the model, task set, temperature, and starting data fixed, then run with the plugin off and on. Compare at least total tokens, task success rate, false recall, manual corrections, and operating cost. Lower token use does not count as savings if you spend more time correcting bad memories.

The real adoption evidence is greater reliability on the same tasks in your own environment. Vendor numbers can justify a test, but they cannot decide whether production use is right for you.

Final Decision: Keep, Expand, or Roll Back

After a two-week trial, choose one of three paths:

• Keep: Cross-session recall is consistent, false memories are traceable and correctable, and you genuinely repeat less context.
• Expand: Keyword search clearly misses paraphrases and the data transfer and cost are acceptable, so you test embeddings. Evaluate TCVDB only when multi-user or capacity needs are clear.
• Roll back: Disable the plugin if bad memories are difficult to govern, repeated explanations do not decrease, or backup and upgrade costs outweigh the benefit. Return to clean Markdown memory.

To roll back, first back up the current configuration and memory data. Set memory-tencentdb.enabled to false in ~/.openclaw/openclaw.json, restart the Gateway, and open a new session to confirm that capture and recall have stopped. Decide whether to uninstall only after disabling the plugin. The official documentation does not provide a universal migration that converts existing layered memories into MEMORY.md, and there is not enough evidence to recommend deleting one fixed SQLite path. Do not clear data before backup and disablement are verified.

If you already run long tasks in OpenClaw, try it for two weeks on one non-sensitive side project. If your work is short-lived or you only chat occasionally, a readable, versionable MEMORY.md is probably the steadier choice. The value of a memory system is not how much it remembers. It is knowing what it stored and being able to retrace the path when it gets something wrong.