Why an Agent Memory System Is More Than a Chat Log
TencentDB Agent Memory is an open-source system for turning an Agent’s past work into reusable context and assets. The focus here is the distinction between storing conversation text and building a memory system that can preserve experience, retrieve it selectively, and govern who receives it. That distinction gives this series its practical question: when an Agent returns to a task, what should it inherit, from which source, through which boundary, and with what safeguards?
The repository is broad because that question is not solved by one database table. It involves a memory core, a knowledge service, a transparent request proxy, a human-facing control panel, and adapters for different Agent clients. The useful mental model is therefore not “an LLM with a bigger history.” It is a set of cooperating systems that convert work into several kinds of future help.
The problem is continuity, not storage
An Agent session often ends with more than a final answer. It may contain a decision about an old authentication module, a constraint that must not be broken, a sequence of commands that finally fixed a deployment, or a careful explanation of a codebase that took hours to build. If the next session begins with none of that, the user pays the same learning cost again. If every later Agent receives the entire transcript, the system has preserved information but not made it usable: irrelevant details compete with the current request, old context consumes the prompt budget, and private material may travel farther than intended.
TencentDB Agent Memory starts from the idea that information should become an asset when it can help the next Agent avoid reinventing work. Its own product description expresses the intended chain as existing information becoming reusable memory assets, which reduces turns and rework and can make results more stable. The important word is reusable. A transcript is a record of what happened. A reusable asset has a purpose, a scope, a way to find it, and rules about who may use it.
That changes what “remembering” means. Remembering a user’s stable preference is different from preserving the exact wording of an earlier message. Remembering a team’s release procedure is different from indexing the repository that procedure refers to. Each need has a different shape, and forcing all of them into a single chat-log abstraction makes the retrieval and governance problems harder.
Consider a small release investigation. The conversation may include a temporary command, a discarded hypothesis, the confirmed cause of an outage, and a decision to add a regression test. Treating the whole transcript as one memory makes those items equally prominent even though their future value differs. A useful system should preserve the raw exchange for verification, extract the confirmed cause and decision as structured facts, organize the broader release practice as a reusable procedure, and leave the repository’s exact dependency relationships to a code-oriented index. The point is not to keep less history at any cost. It is to give different information different jobs.
The system also treats continuity as selective. A later Agent should not automatically receive every fact known to every other Agent. Nor should a model have to read every document and every source file before starting. The design repeatedly separates a compact orientation layer from deeper material that can be searched or read on demand. That is why context cost and privacy are not side concerns: they determine whether accumulated experience improves the next turn or merely makes it heavier.
This is the repository’s central arrangement: the Proxy connects an Agent to the model and to stored capabilities; Core owns memory processing and metadata; Knowledge owns document and code understanding; and the Hub controls the relationships among users, teams, Agents, tasks, and assets. None of these parts is the whole product by itself.
Four different kinds of reuse
Chat Memory is the closest to what people ordinarily call memory. It preserves conversational context across sessions and can retain preferences, facts, decisions, and interaction history. In the implementation, conversation begins as raw L0 material and is progressively distilled into more structured levels. Chat Memory is useful when the question is about continuity: what was decided, what constraint was stated, or what background should the next Agent know before acting.
Skill captures a repeatable way of working. The repository describes a Skill as more than a prompt fragment: it can have versions, resource files, trigger boundaries, execution steps, and validation rules. Its future value is procedural. If a team has learned a dependable troubleshooting or release workflow, the goal is not merely to remember that the workflow happened, but to make the method available for another task and another Agent under controlled conditions.
Wiki turns documents into structured pages connected by links. It is reference knowledge about product documents, designs, or operating guidance. A Wiki can answer why a system was designed a certain way or where a concept is defined. It is not necessarily a rule the Agent must follow, and it does not replace the source material; it creates a navigable representation that can be searched and read when relevant.
CodeGraph indexes a codebase around symbols, files, calls, and impact paths. Its purpose is structural understanding. An Agent that asks “what calls this function?” or “what might this change affect?” needs relationships across files, not just text chunks containing a matching word. CodeGraph makes those relationships callable without requiring the Agent to reconstruct the entire repository from scratch.
These four assets overlap in use but not in role. A team’s decision may belong in Chat Memory; the proven method for applying that decision may become a Skill; the design document explaining its rationale belongs in Wiki; and the implementation’s dependency structure belongs in CodeGraph. A system that distinguishes them can choose a more appropriate retrieval path and give each asset a different lifecycle.
The distinction is also a distinction between kinds of authority. Chat Memory can remind an Agent that a decision was made, but the exact conversation remains the place to check wording and context. A Skill can tell an Agent how a team normally performs a task, but its version and owner determine whether it is still applicable. Wiki and CodeGraph can expose reference material, but neither should be confused with a current user instruction or a permission grant. The asset type says how to use the information; it does not automatically make the information correct.
The distinction also clarifies why automatic extraction cannot be the final authority. An extracted memory may need correction. A Skill may need a new version after its commands change. A Wiki may be processing or stale. A CodeGraph is an index of a repository state, not a guarantee that the working tree has not changed. Reuse requires structure and maintenance, not just accumulation.
The system behind the promise
The visible experience begins with an Agent client, but the client is only one boundary. MemoryCore is the memory and metadata core. It stores and processes the L0–L3 memory layers, registers knowledge and asset metadata, and exposes HTTP APIs and SDKs. It does not host or execute the Agent itself. MemoryKnowledge is separate because parsing documents, building Wiki pages, indexing code, and serving reference queries are different workloads from extracting experience out of conversation.
MemoryProxy is the access path for coding Agents that cannot be expected to integrate a new memory API directly. Instead of changing the client, the Proxy receives the ordinary OpenAI-compatible or Anthropic request, identifies the session and user, assembles the permitted context, forwards the request, and writes the completed interaction back. To the upstream model and client, the protocol remains the familiar one; around that protocol, the Proxy adds session initialization, injection, capture, authentication, and reporting.
MemoryPanel, also called the Hub in the repository’s product language, supplies the human control plane. It manages teams and Agents, associates tasks and assets, and applies ownership, visibility, and access rules. This matters because relevance alone is not permission. A memory can be highly relevant to a question and still be private, owned by another user, or unsuitable for the current Agent’s loadout.
The boundaries create different kinds of failure. If Core has captured a turn but the later L1 extraction has not run, the evidence exists while the structured memory is not ready. If retrieval succeeds but the session is not correctly identified, the right memory may still be withheld or the wrong context may be assembled. If the Proxy forwards an auxiliary compaction request through the ordinary path, implementation details from that request can pollute the memory stream. A system-level account of Agent Memory must therefore follow state and responsibility across services, not judge it only by whether the model returned an answer.
The major design tension now becomes visible. More inherited context can reduce repeated work, but more context also increases prompt cost and the chance of distraction or leakage. More automatic extraction can reduce manual curation, but it can also produce stale or mistaken derived views. More shared infrastructure can let many Agents use the same experience, but it introduces external storage, coordination, and failure dependencies. TencentDB Agent Memory addresses these tensions by using layers, bounded retrieval, explicit asset relationships, and separate control and data paths.
That is the scope of the subject this series examines. It will follow a turn from raw evidence through layered consolidation, then ask how recall decides what to expose. It will trace the Proxy request lifecycle, examine why a Team–Agent context matters, and distinguish executable Skills from reference knowledge. It will also compare local and service deployment and keep the system’s limits visible: a derived profile is not an infallible record, a successful request does not prove that extraction succeeded, and a repository snapshot with conflicting release notes should be read as an evolving implementation rather than a timeless specification.
The starting point, then, is not the question “where are the old messages?” It is “what kind of future work should this information support?” Once that question is answered, the rest of the architecture—layers, retrieval, tools, permissions, and loadouts—has a reason to exist.