Deconstructing TencentDB Agent Memory: How to Keep Agents Accurate Without Being Misled by Errors?

Agent memory is often underestimated; the real challenge is not just storing past interactions but ensuring they aid future decisions without introducing hidden risks. The author uses TencentDB Agent Memory as a concrete case study to illustrate how to structure memory handling in an LLM‑driven workflow.

Three Core Paths

The runtime loop is split into three distinct paths:

Write : Convert the current round’s results into traceable candidate memories.

Read : Narrow the scope based on the current task, rank candidates, and control injection.

Governance : Resolve conflicts, verify evidence, and decide whether a memory stays personal or becomes a shared team asset.

These paths operate at different speeds: raw evidence can be persisted immediately, refinement (L1) happens later, and governance is the slowest because it must handle provenance, conflicts, and promotion.

Four Object Types

Conversation Evidence : Original utterances, tool outputs, timestamps, and sources; read by debuggers and refiners.

Task State : Completed steps, current node, pending items, and failure points; consumed by the current and next agents.

Long‑term Memory : User preferences, project constraints, historical decisions; used by subsequent sessions.

Process Assets : Skills, runbooks, wikis, code relationships; shared among team members and multiple agents.

Policy information (permissions, compliance, budgets) is kept separate and should never be auto‑modified by memory.

L0‑L3 Hierarchy

The memory is organized into four layers:

L0 – Conversation : Raw dialogue and context for traceability.

L1 – Atom : Extracted facts, preferences, and constraints for execution.

L2 – Scenario : Project‑oriented memory blocks that restore work background.

L3 – Persona : Stable profiles and high‑level cognition that help agents initialize state.

Higher layers provide navigation, while lower layers supply evidence; promotion across layers requires explicit verification.

Write Process in Two Steps

First, the raw conversation is persisted instantly without any judgment. Second, an asynchronous model‑driven refinement turns the raw text into structured memory, which may take several seconds (e.g., a test showed a 6‑second delay before a memory card appeared).

Separating these steps ensures that a successful write response does not guarantee that L1/L2 are ready for recall.

Recall Strategies and Degradation

TencentDB Agent Memory supports three recall paths:

Keyword/BM25 – fast, low‑cost, but relies on literal overlap.

Vector – captures synonyms and cross‑language expressions when an embedding service is available.

Hybrid – runs both and merges results with Reciprocal Rank Fusion (RRF).

The default strategy is hybrid, but without an embedding service it falls back to keyword recall. Retrieval limits (max 5 results, 5‑second timeout) prevent blocking the conversation when the memory service is unavailable.

Conflict Resolution and Timeline

When a rule changes (e.g., switching from PostgreSQL to MySQL), the system must preserve both versions, record the change order, and let a human decide which is authoritative. The arbitration model only evaluates candidates that were recalled; unseen older memories are effectively invisible.

To support auditing, the author recommends storing fields such as source, scope, status, valid_from, supersedes, and evidence_ref.

Sharing and Ownership

Team‑level assets are categorized as:

Chat Memory – conversational experience and preferences.

Skill – verified operational procedures.

Wiki – documentation and knowledge graphs.

Code – repository links and impact analysis.

Each asset must expose its owner, version, status, visibility, and agent bindings before becoming a shared resource.

Long‑Task Traceability

For multi‑step tasks, the system records:

完整工具日志  →  refs/*.md 保存原文
执行步骤      →  JSONL 保留结构化节点
任务状态      →  Mermaid 任务画布
Agent 上下文  →  只注入轻量任务地图

These artifacts allow the agent to resume from a specific node, verify failures, and avoid losing critical context.

Practical Test Suite

The author proposes four test categories to validate an integration:

Write latency – time from raw persistence to searchable L1/L2/L3.

Recall quality – coverage of keyword, synonym, and cross‑language queries.

Update safety – ability to distinguish old vs. new rules and their provenance.

Failure degradation – behavior when embedding services time out or restart.

Sample commands to install and restart the plugin are provided:

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

Five Essential Questions

Where does this memory come from?

How many refinement, verification, and modification steps has it undergone?

Why is it being recalled in the current round?

When it conflicts with new information, which value is valid and who can modify it?

If the service is unavailable or the memory is wrong, how does the system continue and self‑correct?

Answering these ensures that a memory system not only stores information but also governs its influence on future decisions.

Overall, TencentDB Agent Memory is not a final solution but a concrete reference implementation that makes the provenance, lifecycle, and governance of agent memories observable, configurable, and auditable.