Add a second or third coding agent to a team's workflow and a specific waste shows up fast: every new session re-explains the same project context, re-reads the same docs, and rediscovers a workflow that already worked last week. TencentDB Agent Memory, built by Tencent Cloud, is aimed squarely at that waste — not memory for a single agent's own conversation history, but a shared, governed memory layer an entire team of agents and humans can draw from, so what one agent learns doesn't die with its session.
The problem is easy to underestimate. One agent forgetting context is an annoyance; five agents forgetting it, each burning tokens and human attention to rebuild the same picture, is a real cost that grows with every agent you add. Shared memory also raises a harder question than retrieval: who is allowed to see what, and which version of a fact is current.
This article explains TencentDB Agent Memory's four memory asset types, how its layered L0 to L3 memory works, why governance sits at the centre of the design, what its published benchmark shows, how cold-start import and agent connections work, how it differs from standard RAG, and what to check before adopting it.
Four Kinds of Memory, Not One
The core design decision is refusing to treat "memory" as one undifferentiated pile of past conversations. Four distinct asset types get automatically extracted from actual work:
| Asset | What it captures |
|---|---|
| Chat Memory | Preferences, decisions, and interaction history, extracted in layers across sessions |
| Skill | A reusable SOP distilled from a task that actually worked — versioned, with trigger conditions and verification rules |
| Wiki | Documents turned into structured, linked pages — explicitly inspired by the practice of building a navigable knowledge base rather than a flat document dump |
| CodeGraph | An index of a repository's symbols, files, and call relationships, so an agent can check the impact of a change before making it |
Treating these as four separate, first-class asset types rather than one memory blob is what makes the system genuinely useful across different kinds of work — a Skill and a Wiki page serve completely different retrieval needs, and collapsing them into one undifferentiated memory store is exactly the pattern that makes most "AI memory" features shallow in practice.
Memory That Grows in Layers, Not Flat Records
Chat Memory specifically doesn't get stored as one flat log. Conversations are saved raw as L0, then an async pipeline refines them upward: L1 extracts atomic facts, preferences, and events; L2 organizes knowledge around specific projects or scenarios; L3 synthesizes long-term profiles and stable patterns. Retrieval mirrors that structure — L2/L3 give a fast context bootstrap for the common case, and the system falls back to BM25 plus vector retrieval with reciprocal rank fusion against L1/L0 when a specific fact actually needs verifying, with results capped by item count, character budget, and timeout so memory can't quietly overwhelm the context window. That's a meaningfully more deliberate design than dumping recent history into a prompt and hoping relevance sorts itself out.
Governance Is the Actual Product, Not an Add-On
The Memory Hub is explicitly built as a control panel, not a passive log viewer. Assets are owned by a Team or Agent, tracked by version and status, and governed by three visibility tiers — private, team, and restricted, the last enforced through a full user/role/agent ACL — plus a separate "Agent Loadout" mechanism that lets an operator decide which specific assets a given agent is equipped with and at what priority. That's the part worth taking seriously for any real team deployment: shared memory without access control just means every agent can read everything, which is a real information-boundary problem the moment agents are working across clients, projects, or sensitivity levels. Fixed Binding plus ACL narrows what's retrievable before a query even runs, rather than filtering after the fact.
A Real Benchmark, Not Just a Feature List
Tencent publishes a concrete result rather than only a feature list: on PersonaMem, a benchmark specifically testing whether an agent correctly understands and applies user information after extended interaction, scores went from 48% without the system to 76% with it enabled — a 59% relative improvement. That's a specific, falsifiable claim rather than marketing language, and it's the kind of benchmark worth re-running against your own workload before trusting it wholesale, the same way you'd treat any vendor-published number.
Cold Start: Importing What Already Exists
The system is explicitly built around the idea that a new agent's first task is usually re-learning a project that's already been learned once. Rather than starting every new agent or team from a blank memory store, the Hub accepts three kinds of import and turns each into the matching asset type automatically: existing codebases get indexed into CodeGraph, relevant documents and files get turned into structured Wiki pages, and past agent conversation sessions get mined for reusable Skills and Chat Memory. The framing in Tencent's own documentation is direct about the goal — stop retraining every agent from scratch, and give it the save file instead. That's a meaningfully different starting posture than most memory tooling, which typically only starts capturing value going forward from the moment it's installed.
What a Team Actually Looks Like in Practice
Tencent's documentation illustrates the team-ownership model with a concrete example worth understanding on its own terms: a one-person company assembling a small squad of role-scoped agents — a Scout for research and market opportunities, a Builder for writing code and shipping product, a Reviewer for testing and catching issues, and an Agent Memory role for preserving what the team learns — with a human setting goals and making decisions. The point of the example isn't the specific roles; it's the "recruit first, then equip" pattern underneath it: each agent gets bound to a different loadout of memory assets — the Reviewer gets historical incident Chat Memory, project CodeGraph, and a release-checklist Skill, while the Scout gets user-interview Chat Memory, market-research Wiki, and a competitive-analysis Skill — so a growing team of agents doesn't all read from the same undifferentiated pile — the same separation-of-roles idea behind most multi-agent system designs. That's the ACL and Agent Loadout machinery described above, applied to an actual scenario instead of described abstractly.
How This Differs From Standard RAG
It's worth being precise about what problem this solves that a standard retrieval-augmented-generation setup doesn't, since "AI memory" gets used loosely enough to mean very different things. Plain chat history and standard RAG both answer "what can be found" reasonably well, but neither tracks ownership, versioning, or who's allowed to see what, and neither distills a workflow that worked into something reusable — RAG chunk-retrieves against documents, it doesn't turn a document into a structured, linked Wiki page, and it doesn't turn code into a call-graph an agent can run impact analysis against before editing. TencentDB Agent Memory's four-asset model is built specifically to answer the questions plain retrieval leaves open: which version of a fact is current, which agent is equipped with it, and whether it's private, team-visible, or restricted by ACL.
Benefits of TencentDB Agent Memory
The design choices above add up to a handful of practical benefits for teams running more than one agent. Most of them come from treating memory as shared, governed infrastructure rather than a per-session feature.
Less time and money spent rebuilding context
When every new session starts from zero, agents re-read the same docs and re-learn the same project conventions, and humans re-explain them. Bootstrapping each session from L2 and L3 memory and matched Skills cuts that repetition. The saving shows up as fewer tokens spent on context gathering and less human time spent briefing agents on things the team already knows.
Workflows that survive the session
A procedure that worked once, such as a release checklist or a debugging sequence, normally lives only in the transcript where it happened. Distilling it into a versioned Skill with trigger conditions and verification rules means other agents can reuse it, and a human can review and improve it like any other team document.
Sharing without leaking
Private, team, and restricted visibility, plus per-agent loadouts, let a team share knowledge widely where that is safe and narrowly where it is not. An agent working for one client or project does not see another's memory, because binding and permissions narrow retrieval before the query runs rather than filtering results afterwards.
Safer code changes
CodeGraph gives an agent a map of symbols, files, and call relationships, so it can check what a change will affect before making it. That is a different capability from finding similar text in a repository, and it reduces the class of errors where an agent edits one function without realising what depends on it.
Context that stays within budget
Layered retrieval with item, character, and timeout caps keeps memory from flooding the context window. Agents get the most relevant, refined knowledge first and only drop down to raw records when a specific fact needs checking, which keeps prompts focused and costs predictable. It also reduces the risk of an agent being distracted by loosely related history that happens to share keywords with the current task.
TencentDB Agent Memory Use Cases
The platform is built for teams, so its strongest use cases involve several agents, several people, or both. These are the situations where it fits most naturally.
Multi-agent software teams
A team running separate agents for building, reviewing, and researching wants each one to start with the right context. The builder draws on the project CodeGraph and coding Skills, the reviewer on incident history and release checklists, and the researcher on market Wiki pages. Each works from relevant knowledge rather than a shared, undifferentiated pile, and improvements one agent makes to a Skill benefit the others.
Onboarding new agents onto existing projects
Adding an agent to a mature project usually means it spends its first sessions rediscovering what everyone already knows. Importing the repository into CodeGraph, documents into Wiki, and past sessions into Skills and Chat Memory gives it a starting point built from accumulated experience. The new agent becomes useful sooner, and humans spend less time on briefing.
Agencies and consultancies serving several clients
Firms using agents across multiple client engagements need strict boundaries between them. Restricted visibility and per-agent loadouts keep each client's memory scoped to the agents working on that account, while genuinely shared knowledge, such as internal coding standards, stays team-visible. That lets the firm reuse its general expertise across accounts without risking one client's details surfacing in another client's work.
Turning ad hoc wins into team procedures
Teams often find that one agent session solved a recurring problem well, then lose the approach. Distilling that session into a reviewed Skill makes the procedure reusable and versioned. Over time, the Skill library becomes a living record of how the team actually works, useful to new human team members as well as to agents.
Mixing existing coding agents with shared memory
Teams already using tools such as Claude Code can route them through the Memory Proxy instead of building custom integrations. Each developer's agent receives scoped team memory on every turn, so individual tools gain shared context without changing how developers work day to day. Because authentication is per user, each developer still sees only what their role allows.
How Agents Actually Connect to It
A Memory Proxy component is what lets an existing coding agent — Claude Code and others — use team memory without a bespoke integration: it speaks both Anthropic and OpenAI-compatible protocols, walks a user through selecting a team/agent/task on first use, and then injects the relevant L2/L3 memory, matched skills, and wiki or code-graph context directly into the system prompt on every turn, authenticated per-user so asset visibility stays scoped correctly. Deployment is a three-container Docker setup (memory-core, memory-hub, memory-proxy) with a single start-all.sh script, and official SDKs ship for both TypeScript and Python.
What to Weigh Before Adopting It
- This is genuinely for teams, not solo use. The entire design — ACLs, team ownership, agent loadouts — assumes more than one agent or person is sharing memory. A single-agent setup won't see the actual value this architecture is built for.
- CodeGraph currently favors public HTTPS repos. Private repository and SSH credential support is explicitly still being refined per the project's own notes — worth checking current status before depending on it for a private codebase.
- Wiki and CodeGraph build asynchronously. Assets aren't instantly ready after ingestion; plan for processing time before an agent can actually query newly indexed docs or code.
- License terms are worth reading directly — GitHub's automated license detection flags this as a non-standard license despite an MIT badge in the README, which is worth resolving by reading the actual
LICENSEfile rather than trusting either signal alone.
Common Agent Memory Mistakes
Shared memory systems fail in predictable ways when teams adopt them quickly. These mistakes apply to TencentDB Agent Memory and to most comparable platforms.
Making everything team-visible by default
It is tempting to share every asset with every agent so nothing is missed. That recreates the information-boundary problem the governance layer exists to solve, and it fills each agent's context with knowledge irrelevant to its task. Start restrictive and widen visibility deliberately, one asset type or team at a time, so you can see whether broader sharing actually helps.
Accepting distilled Skills without review
A Skill extracted from a session that only appeared to succeed will spread a flawed procedure to every agent equipped with it. Because Skills are versioned and reusable, mistakes travel further than they would in a single transcript. Have a person review new Skills before they enter shared loadouts.
Treating memory as write-once
Projects change, decisions get reversed, and documentation goes stale. Memory that is never pruned or updated will confidently surface outdated facts. Use versioning and status tracking actively, retire assets that no longer apply, and schedule re-syncs for code and documents.
Trusting the headline benchmark
The published PersonaMem improvement is a useful signal, but it measures one kind of task. Teams that adopt on the strength of that number without testing on their own workloads may find the gains smaller, or concentrated in areas they care less about. A short side-by-side test on real tasks gives a far better basis for the decision.
Adopting it for a single agent
The architecture's value comes from sharing across agents and people. A solo agent gets most of the overhead, including containers, governance, and import pipelines, with little of the benefit. Simpler memory approaches, such as a project notes file or a small vector store, usually fit single-agent setups better until a second agent or teammate joins.
TencentDB Agent Memory Best Practices
Teams that get value from a shared memory hub tend to follow a consistent set of practices.
- Design visibility before importing anything. Decide which assets are private, team-wide, or restricted, and which agents should be equipped with what, before bulk-importing code and documents. Changing permissions after agents have already been reading broadly is harder than starting narrow.
- Start with one team and one project. Import a single repository, its key documents, and recent sessions, then measure whether agents need less briefing and make fewer repeated mistakes before expanding to other teams.
- Review Skills like code. Treat distilled procedures as team assets with an owner, a review step, and a version history. A Skill that will be loaded into many agents deserves the same scrutiny as a shared library.
- Schedule re-syncs and pruning. Keep CodeGraph and Wiki aligned with the current repository and docs, and retire memory that no longer reflects how the team works. Assign someone to own this, or it will not happen.
- Benchmark on your own tasks. Compare agent performance with and without the hub on representative work before rolling it out widely, and repeat the comparison after major upgrades.
- Plan for asynchronous builds. Allow time for Wiki and CodeGraph processing after imports, and avoid depending on newly ingested assets immediately. Tell users when indexing is still running so they do not assume the agent has context it lacks.
- Confirm licensing and repository support. Read the actual LICENSE file and check the current status of private-repository indexing before committing a production codebase. Both are moving targets in a fast-changing project.
- Monitor what gets injected. Periodically inspect the context the Memory Proxy adds to prompts, so you can spot irrelevant or stale memory before it degrades agent output or inflates token costs.
Practical Takeaway
TencentDB Agent Memory is a serious answer to a problem that gets worse, not better, as teams add more agents: without a shared, governed memory layer, every new agent session starts from zero and every team member's context lives in their own head. The layered memory model and asset-based governance are the parts most worth studying even independent of adopting the whole platform — they're a real, transferable pattern for anyone building agent memory systems or team-shared knowledge graphs from scratch.
Teams building shared memory, knowledge-graph retrieval, or governed multi-agent infrastructure can get hands-on architecture help from Woyce Technologies.
FAQ
What is TencentDB Agent Memory?
TencentDB Agent Memory is an open-source memory hub from Tencent Cloud for teams of AI agents. It extracts four types of reusable memory assets, namely Chat Memory, Skill, Wiki, and CodeGraph, from a team's conversations, documents, and code, then shares them across multiple agents with ownership, versioning, and access control. The goal is that knowledge one agent gains in a session becomes available to the rest of the team instead of disappearing when that session ends.
How is this different from a single agent's chat history?
A single agent's chat history belongs to one conversation and usually disappears or gets truncated when the session ends. TencentDB Agent Memory is built for teams: assets are owned, versioned, and access-controlled at the team or agent level, and they can be shared across multiple agents and frameworks. It also refines raw conversations into facts, project knowledge, and long-term profiles rather than keeping a flat transcript.
What are the four memory asset types?
Chat Memory holds layered conversation history, preferences, and decisions. Skill captures reusable, versioned task procedures distilled from work that succeeded, with trigger conditions and verification rules. Wiki turns documents into structured, linked pages. CodeGraph indexes a codebase's symbols, files, and call relationships so an agent can analyse the impact of a change before making it. Each type serves a different retrieval need, which is why they are kept separate.
How does access control work?
Assets have three visibility tiers: private, team, and restricted. Restricted assets are enforced through a full user, role, and agent access-control list. On top of that, an "Agent Loadout" system lets an operator decide which specific assets each agent is equipped with and at what priority. Because binding and permissions narrow what is retrievable before a query runs, an agent working for one project or client doesn't see another's memory.
Can I connect Claude Code to TencentDB Agent Memory?
Yes. A Memory Proxy component speaks both Anthropic and OpenAI-compatible API protocols, so existing coding agents can route through it without a custom integration. On first use it asks the user to select a team, agent, and task, then injects relevant L2 and L3 memory, matched skills, and wiki or code-graph context into the system prompt on each turn, authenticated per user so visibility rules still apply.
Is TencentDB Agent Memory free to use?
It is open source and self-hostable through a three-container Docker deployment, so there is no licence fee to run it on your own infrastructure. You still pay for the servers, storage, and model API calls involved. License terms are worth confirming directly from the repository's LICENSE file, since GitHub's automated detection and the README's displayed badge don't fully agree.
How is this different from a standard RAG setup?
Standard RAG answers "what can be found" through chunk retrieval against documents. TencentDB Agent Memory also tracks who owns an asset, which version is current, and which agent is allowed to use it — plus it distills conversations into reusable Skills and code into a queryable call-graph, neither of which a typical RAG pipeline over raw documents does on its own.
Can I import an existing codebase and document set instead of starting from zero?
Yes — this is the system's stated "cold start" design. Existing repositories can be imported directly into CodeGraph, documents and files into Wiki, and past agent conversation sessions get mined automatically for Skills and Chat Memory, so a new agent team can start from accumulated experience rather than an empty memory store.
What's new in the current release?
Version 2.0.0, published August 2026, added forced Skill archiving so key procedures aren't lost, scheduled automatic CodeGraph re-sync after a repository changes, bilingual English and Chinese support in the Memory Hub panel, and expanded asset-management tools for system administrators. Check the repository's release notes before deploying, since the project is moving quickly and features such as private-repository CodeGraph support are still being refined.
Conclusion
Adding agents to a team multiplies a quiet cost: each new session rediscovers context that another agent already worked out. TencentDB Agent Memory treats that as a shared-infrastructure problem rather than a feature of any single agent, turning conversations, documents, and code into owned, versioned assets that a whole team can draw from.
Its most transferable ideas are the separation of memory into distinct asset types, the layered refinement of raw conversations into facts and profiles, and governance that decides what an agent can see before retrieval happens. Those patterns are worth studying even if you never deploy the platform.
Weigh the caveats before adopting it. It is designed for teams rather than solo agents, some features such as private-repository indexing are still maturing, assets build asynchronously, and the licence should be confirmed from the source. Re-run the published benchmark against your own workload instead of relying on the headline number.
If you're designing shared memory or governed multi-agent infrastructure for your own team, our AI agent development team can help you choose an architecture and integrate it with the agents you already run.