In this piece
TencentDB Agent Memory: Is SQLite Enough for Your AI Agent?
Your agent starts a new session, and you explain the project constraints again. Persistent memory should spare you that work.
TencentDB Agent Memory can store persistent agent memory locally in SQLite. A separate managed vector service can therefore be optional for a bounded deployment. Memory extraction still needs a configured language model, and vector retrieval remains supported. The MemoryCore runtime documentation makes those dependencies explicit.
Source review: . This review covers documentation and configuration at fixed revisions. It contains no Wavect deployment measurements or independently reproduced benchmarks. The pilot below is a proposed evaluation.
Which TencentDB Agent Memory version are we discussing?
TencentDB Agent Memory has evolved from a plugin into a team Memory Hub. The token-saving claim comes from the earlier plugin documentation. The current Hub documentation describes shared Chat Memory, Skills, Wiki and CodeGraph assets.
| Scope | What to evaluate | Source snapshot |
|---|---|---|
| Plugin architecture | OpenClaw integration, optional short-term offloading and the original token table. | main, a3c2d860 |
| Team Memory Hub | Memory Core, Hub and proxy; reusable assets with team, user and agent access relationships. | feat/server_team, ecc01a54 |
Use installation instructions for your chosen revision; the earlier Mermaid offload design does not describe every current proxy integration.
Does TencentDB Agent Memory replace vector databases?
TencentDB Agent Memory can remove a separate vector service from some deployments while retaining vector search as an option. Its plugin configuration lists SQLite with sqlite-vec and Tencent Cloud VectorDB backends. Current standalone MemoryCore defaults to BM25 keyword retrieval with remote embeddings disabled.
The claim that China has killed the vector database industry goes beyond this evidence. Tencent offers a memory system with several storage and retrieval options. Avoiding a managed service for one workload says little about every distributed search system.
Memory organization is also a separate decision from database selection. An embedding index can store pointers to original text, and an application can add provenance, time and access controls around it. For another hierarchical approach, our OpenViking filesystem-memory review explains that product’s directory-based retrieval.
How does the L0-L3 memory pyramid work?
TencentDB’s four memory layers turn conversations into increasingly selective context: original dialogue, extracted atoms, scenario knowledge and a persona or core profile. Their usefulness depends on whether a derived statement still leads to its supporting evidence.
| Layer | Representation | Example to inspect |
|---|---|---|
| L0 Conversation | Original dialogue | On Monday, the user says Project Atlas can deploy on Friday. On Wednesday, the user cancels that permission. |
| L1 Atom | Extracted fact or constraint | The current constraint is that Friday deployment is no longer approved. |
| L2 Scenario | Project or situation context | The Atlas release notes should connect the cancellation to the affected release. |
| L3 Core / Persona | More durable profile | A general communication preference may belong here; a temporary release exception should not become a permanent personal trait. |
Ask the agent on Thursday whether it can deploy. Require the Wednesday correction and its source; retrieving both messages without resolving their order is insufficient. This is a proposed test, not an observed result.
The upper layers are derived interpretations. Retained source material makes them inspectable without guaranteeing accurate summaries or lossless retrieval. Some artifacts use Markdown; others are database records or JSONL.
What do Mermaid and node_id do with tool logs?
The earlier plugin design moves raw tool output into files, keeps step summaries in JSONL and retains a compact Mermaid task canvas in context. A node_id links a recorded step to deeper evidence through its result_ref. The agent can inspect that evidence without repeatedly reading every log.
A task canvas might record that the Atlas build failed. Before changing dependencies, the agent should retrieve the failed command’s output and check for a newer run. The label “build failed” helps navigation; diagnosis needs the error itself.
The reviewed plugin requires additional OpenClaw configuration for optional short-term offloading. Verify that it emits references and that the agent can retrieve their source material after restart.
Can the whole system run offline?
Local SQLite storage does not establish offline inference. The current deployment template configures a memory-building model and an agent-answering model. They can share an endpoint, but both paths need review, along with any enabled embeddings and external tools.
| Component | Relevant boundary | What to verify |
|---|---|---|
| Memory storage | SQLite and local files | The durable volume, file permissions and recovery procedure. |
| Memory extraction | MEMORY_LLM_* in the Hub deployment | The endpoint runs locally and completes extraction and aggregation. |
| Agent inference | PROXY_UPSTREAM_* | The proxy forwards to local inference, including any fallback path. |
| Retrieval | BM25 by default; embeddings when configured | Keyword retrieval works, and any embedding endpoint stays local. |
| Tools and startup | Your integration’s network behavior | Required models and dependencies are present; runtime tools do not need outside services. |
These variable groups come from the deployment environment template. A compatible local endpoint needs testing; this review does not establish extraction quality for a particular local model.
After provisioning, block outbound traffic and capture attempted connections. Start a conversation, wait for derived memory, restart, recall the changed Atlas instruction and retrieve its evidence. A health check alone is insufficient. For shared coding-tool memory through MCP, see our mcp-memory-service setup guide.
What do the 61% and PersonaMem results prove?
TencentDB’s headline figures describe two separate, workload-specific results. Its plugin benchmark table reports WideSearch/OpenClaw token usage and PersonaMem accuracy under a long-horizon evaluation setup. These upstream results do not establish your deployment’s savings.
| Measurement | Without / with memory | What follows |
|---|---|---|
| WideSearch tokens | 221.31 million / 85.64 million | About 61% fewer tokens in that reported evaluation. |
| PersonaMem accuracy | 48% / 76% | An increase of 28 percentage points on the reported personalization task. |
The printed token counts give (221.31 - 85.64) / 221.31 × 100 = 61.30%, rounded to two decimals. The README prints 61.38%. We therefore use “about 61%” and retain the inputs, rather than imply more precision than the table supports.
The PersonaMem research paper evaluates personalized responses against evolving user profiles. Its score is not a general measure of database correctness, source traceability or tenant isolation. Nor should the older token result be presented as a benchmark of the complete current Hub stack.
A cost comparison needs every model call: memory extraction, aggregation, agent inference, retries and deeper evidence reads, plus embedding and infrastructure costs. Measure cost per successfully completed task. Our AI-agent cost-per-action model covers that broader accounting boundary.
When should you keep SQLite or add a separate service?
We would start with local SQLite when one deployment can meet the application’s load and recovery targets. Evaluate separate storage or search infrastructure when measured contention, retrieval quality or availability requirements justify it. There is no universal record-count cutoff for this decision.
| Requirement | Local SQLite is worth piloting when | Evaluate another service when |
|---|---|---|
| Deployment | One controlled node owns the durable store. | Several nodes need independent, coordinated access and failover. |
| Write load | Capture and extraction stay within the latency budget under realistic concurrency. | Measured write contention or recovery behavior misses the target. |
| Retrieval | Keyword or configured local vector retrieval passes the application’s query set. | Measured search quality or latency requires a different index or serving design. |
| Operations | The team can own backup, restore, access boundaries and upgrades. | Its availability targets require operating capabilities the deployment does not provide. |
SQLite’s own deployment guidance distinguishes application-local storage from client/server workloads and notes the single-writer constraint per database file. That is a useful design boundary, not a TencentDB throughput measurement. A separate database also cannot fix a wrongly extracted preference by itself.
For Supermemory’s hosted or local API, see our Supermemory memory-lifecycle and deployment guide. Evaluate a switch using the same application tasks.
How would we evaluate memory before shipping?
We would compare runs with and without persistent memory using the same tasks, answer model, tools and scoring rules. Start with synthetic records and a fixed configuration. Let memory processing finish before scoring recall, then repeat tasks to measure variation and failures.
- Correction and scope: use the Atlas sequence above. Add a different project that still permits Friday deployment. Require the right instruction and source for each project.
- Evidence recovery: ask for an exact detail from an offloaded log, then repeat after restart. Record the source ID, whether the source exists and whether the answer matches it.
- Untrusted content: insert a tool log that asks the agent to ignore the user. Check that retrieved text remains evidence and cannot silently authorize actions.
- Isolation and deletion: query the same fact from another user or team. Then remove the test record and inspect derived memory, files and the intended retention path. A missing search hit alone does not prove complete removal.
- Failure and cost: interrupt extraction or a configured endpoint, observe the recovery, and measure total model usage, task success and p95 latency at the expected concurrent load.
Before running, require correct handling of the changed instruction, recoverable evidence, no cross-user disclosure in the test set, and an agreed cost and latency budget. These are proposed acceptance conditions.
Our recommendation
Use TencentDB Agent Memory as a candidate when local storage and inspectable memory solve a real workflow problem. Start with one workflow and prove that corrections survive a new session, evidence can be recovered and every configured model path fits your requirements. Add infrastructure when the measured workload requires it.
Wavect can help scope that architecture and evaluation through our AI development service. The first useful milestone is a repeatable decision on your own tasks: whether memory improves the outcome enough to justify the system that maintains it.
The upstream source is MIT licensed. Model inference, hardware and operating effort still belong in the estimate.