DEV Community: ellytan

When Should an Agent Use Team Experience? TencentDB Agent Memory Adds JEV Decision Support

ellytan — Tue, 13 Oct 2026 11:55:52 +0000

Open-source project: TencentDB Agent Memory

An agent can fail to use a team's existing experience in two opposite ways. It may overlook a useful method and repeat work the team has already done. Or it may load irrelevant memories into its context, increasing token use without helping the task.

TencentDB Agent Memory now supports a pluggable decision service for questions such as whether to recall a Skill, which candidate assets to select, and whether new task information warrants a memory update. The project includes an integration example using JEV. The decision service handles these narrow judgments; the main model remains responsible for analyzing and executing the task.

In one Skill-recall test, repeated input-token injection after failed matches fell from 24.96 million to 15.04 million with JEV, a reduction of about 40%. Task success was nearly unchanged: 66.7% with the main model making the selection versus 65.3% with JEV. On a selected set of longer, more difficult SWE-bench Pro tasks, the reported pass rate rose from 30% to 40%. These are results from the described evaluations, not a general performance guarantee.

Two decisions: what to recall and what to update

JEV is used at two points in the online workflow. Both decisions have a defined scope and a structured output, including a confidence value. If a decision fails, the system can fall back to its previous strategy according to configuration.

Recall: should an asset be used, and which one? Within the assets the agent is authorized to access, the system gives JEV candidate identifiers and descriptions. JEV selects the candidates in one structured decision. Only then does the system fetch and load their contents. The decision is about selection, not about doing the user's task.

Memory generation: is an update worth triggering? After scene memory (L2) is updated, the system checks whether it should regenerate long-term profiles and summaries of stable rules (L3). JEV compares the current L3 with the new L2 information and classifies the change in priority order: conflict, changed applicability boundary, new rule, reinforcement, or no change. The first three call for an immediate update. Reinforcement can be handled later; no change skips this round of L3 generation.

This separation gives the system a fast path for deciding when to act and a slower path for loading, generating, and using content. A different decision model can be connected through the same interface, but its recall and generation behavior should be evaluated separately.

What the initial tests show

The project ran two evaluations to examine token use, cost, and task outcomes.

For Skill recall, the comparison used 72 tasks from the same source, with either the main model or JEV making the selection:

Repeated input caused by unsuccessful matches fell from 24.96M to 15.04M tokens, about 9.92M fewer tokens or 39.7% less.
Task success changed from 66.7% to 65.3%, a difference of one task in this set.
On a selected subset of longer, more difficult SWE-bench Pro tasks, the reported pass rate changed from 30% to 40%. The source does not specify the size of that subset.

For memory generation, the comparison used 10 questions, three experimental arms, and three repetitions, measured over a complete 14-turn user conversation. Relative to a strategy that regenerates L3 every time:

Total cost fell 13.8%.
L3 generation calls fell 39.7%.
Final semantic synchronization reached 96.7%, compared with 86.7% for the current strategy in this test; 100% represents the ideal result for this measure.
JEV's decisions accounted for 0.72% of total cost. Immediate-update recall was 93.3%, and binary decision accuracy was 85.1%.

The results support testing a small decision step before expensive retrieval or regeneration. They do not mean that every deployment will get the same savings or quality. Different tasks, candidate descriptions, permissions, and models can change the outcome.

A decision is only as useful as the assets it can choose from

Imagine that a team completes a database change. The execution record and a step-by-step document exist, but months later another developer and a different agent take on a similar task. If the previous experience never enters the new agent's context, the team pays to rediscover part of the answer.

TencentDB Agent Memory manages four types of Memory Assets: Chat Memory for facts and preferences, Skills for repeatable methods, Wiki for structured documentation, and CodeGraph for code relationships. Skill is especially relevant here because it packages the conditions for using a method together with its steps, resources, and checks.

Extracting a Skill is not enough. A method that worked once may be unsafe to repeat in another environment. For a candidate asset to be useful to both people and a decision service, it should say at least:

Where it applies: the environment, version, and task conditions.
How to use it: reusable steps, parameters to fill in, and how to verify the result.
What supports it: evidence and outcomes, clearly separating verified from unverified claims.
Who can use it: personal, project, or team scope.
Who maintains it: source, owner, update history, and when to review it again.

These details help the decision service understand the candidate list, while giving people a basis for review. The path from an individual's experience to a team asset is not just extraction; it also involves checking, setting boundaries, and maintaining the result.

Close the loop between execution and maintenance

When an agent uses a Skill, its execution produces new records and outcomes. Those can improve the asset for the next task. The workflow has two connected parts:

Use experience during execution. Decide whether to recall an asset, filter candidates within the agent's permissions, load the relevant methods and information, and combine them with the current task state and tool results. The agent then carries out the task and records the outcome.
Maintain experience after execution. Turn execution records, feedback, documents, and human expertise into candidate improvements. Preserve applicability conditions and evidence; merge related knowledge, resolve conflicts, maintain versions, and test changes on representative tasks.

Feedback can also inform the decision policy itself. Teams can inspect cases where a Skill should have been recalled, where a memory update could have waited, or where an outdated asset was selected. Prompts and rules for the decision service can then be revised and evaluated. This changes an agent's behavior through external memory and routing without changing the main model's weights.

In TencentDB Agent Memory, Memory Hub provides a place to review Memory Assets, manage versions, and share or bind revised memories and Skills to the relevant agents. The aim is to make one task's outcome useful to the next person and the next agent.

Contribute and try other decision models

Agent memory is moving beyond storing conversation history and searching it by similarity. The more useful workflow is to capture experience from execution, review and version it, decide when it applies, assemble the right context, and feed results back into the assets and decision policy.

The decision-model integration is designed as an interface rather than a hard dependency on JEV. Developers can adapt other decision models and evaluate them against their own tasks, deployment constraints, and quality targets. If you are using Skill recall or memory updates in a real workflow, the project welcomes examples, feedback, and contributions.

Explore the project: TencentDB Agent Memory on GitHub

Original Chinese article: TencentDB Agent Memory 适配 JEV 决策模型：让 Agent 按需调用团队经验

Memory Strategies and the Entropy-Reduction Philosophy of Context Engineering

ellytan — Tue, 13 Oct 2026 07:17:56 +0000

Open-source project: TencentDB Agent Memory

Why does talking to AI so often feel like hard work?

With an old friend, a glance can be enough. With an AI assistant, the same request may require several paragraphs of explanation.

One useful way to understand this difference is through entropy: uncertainty about what a message means. A friend shares memories with you and can fill in what you leave unsaid. An AI assistant without that context faces many possible interpretations of even a simple phrase.

Context engineering helps bridge that gap. Instead of merely storing conversations, a layered memory system captures the situational information that would otherwise be lost. Drawing on Tencent Cloud's Memory engineering experience, this article explores how to reduce uncertainty before a model acts, moving from repeated clarification toward more precise execution.

1. Entropy reduction in context engineering: from formulas to intuition

1.1 A simple example: “Ask Li to meet us at the usual place”

Imagine that you are busy at work and say to a longtime colleague, without looking up: “Ask Li to come along. We'll meet at the usual place when it's time.”

Your colleague nods and gets on with it. You have not spelled out the details, but your shared history supplies them.

An AI assistant receiving the same request may have to ask several questions, or may make unsupported guesses:

Who is Li: the manager in your contacts, someone in the next department, or the intern who joined this week?
When is “when it's time”: nine tonight, ten tonight, or tomorrow morning?
Where is “the usual place”: a restaurant, a park, or the office lounge?

These are different levels of uncertainty. More plausible interpretations mean higher entropy; a clear, well-grounded interpretation means lower entropy.

In a familiar human relationship, shared memories, the current situation, and established habits resolve references such as “that thing” or “Wang.” Without those signals, the same instruction can represent thousands of combinations.

Context engineering acts as a translation layer: it turns the implicit, ambiguous expressions people naturally use into context a machine can work with.

1.2 Improve the input before changing the model

At a simplified mathematical level, a language-model application can be represented as:

y = f(x)

f is the trained model, with its parameters already set.
x is everything supplied to it: context in the broad sense.
y is the model's response.

For many applications, changing f frequently would be costly and risky. Much of the practical engineering work therefore goes into improving x:

The user's current question or instruction.
A system prompt defining the model's role and task.
Cross-session memory of what happened before.
Available tools and instructions for calling them.
Retrieved passages from external knowledge bases through RAG.

Selecting, ordering, filtering, and compressing these inputs is context engineering.

The paper Context Engineering 2.0: The Context of Context Engineering frames it as a systematic process for collecting, storing, managing, and using context to bridge the cognitive gap between people and machines.

Can the model understand what you mean when you speak casually? Can it identify the important evidence when a business system supplies a pile of logs? These questions concern how we prepare context as well as the model's capabilities.

1.3 Reduce uncertainty in three steps

The entropy-reduction perspective treats context engineering as a process of making information less ambiguous. Here, entropy refers to informational uncertainty, rather than a literal thermodynamic calculation.

People communicate through emotions, hints, omissions, assumed knowledge, and pauses. We leave many things unsaid because we expect the listener to fill them in. A machine receiving a token sequence cannot reliably reconstruct all of that missing context. Supplying an unfiltered stream of real-world information can leave it with too much noise and too little structure.

The process can be divided into three steps:

Collect: capture relevant signals from people and their environment without losing critical clues.
Organize and abstract: structure and compress the information, filtering out noise.
Use: select the small subset that matters to the current task and supply it to the model.

The earlier formula then becomes:

y = f(g(context))

Here, f is the language model, while g represents context-engineering strategies: knowledge retrieval, tool use, and the memory storage and retrieval methods discussed in this article.

1.4 A formal view of context

The paper describes a world of entities: users, applications, tools, environments, memory modules, and other objects. Each entity e has characterization information, written as Char(e): who a user is, what time it is, or how an application is configured.

For a particular interaction, select the relevant entity set E_rel and combine their characterization information:

C = ⋃ { Char(e) | e ∈ E_rel }

In plain language, the context for a task combines its relevant entities with information describing their current state. Memory supplies a portion of that characterization that is particularly easy to lose and difficult to maintain over time.

1.5 Memory reduces uncertainty about people and time

Context also includes system instructions, tool results, and knowledge-base documents. Memory has a more specific role.

A knowledge base helps a model understand the world. Memory helps it understand a particular person and a particular ongoing task.

Its job is to turn large numbers of fragments about a person, a relationship, or a task into a small amount of ordered, reusable context. Without that history, each conversation starts with substantial uncertainty. With it, the assistant has a basis for interpreting what a short reply such as “Okay” refers to.

2. Memory as intent recognition and selective information supplementation

A powerful language model with no useful persistence can resemble an exceptionally capable colleague who keeps forgetting the conversation. Giving it a notebook helps, but a memory system needs to do more than save a few chat messages.

2.1 From a passive archive to an active context layer

Memory is often imagined as a warehouse: put the user's words in, then look them up later. In a context-engineering pipeline, it is a dynamic layer centered on people and long-running tasks.

It serves two purposes.

Reduce uncertainty about intent. Consider the shopkeeper downstairs who knows a regular customer's usual purchase. Without that history, the customer has to describe the exact product and accessories every time. With it, a nod may be enough. Memory maps an ambiguous signal to an intent grounded in prior interactions.

Supply missing background selectively. When discussing a code change, memory should not insert all 100,000 lines of a project into the prompt. That would contaminate the context. It might instead provide one timely reminder: “This module previously used OAuth 2.0 for authentication; preserve that behavior.”

Restraint matters. Supply the high-value background missing from the current decision; irrelevant additions are noise.

2.2 Five kinds of demand for memory

Requests for memory features can seem scattered. Look more closely, and they reveal five recurring needs.

Keep roles and instructions stable. An agent may lose its assigned persona or forget an initial constraint such as “Respond only in JSON” after many turns. Users want stable role definitions and critical constraints to persist, instead of repeatedly resetting the assistant's identity.

Build personalization and user profiles. In education, an AI tutor should recognize that a student has made the same sign error three times, rather than treating each wrong answer in isolation. In customer service, an assistant might remember a previous purchase and recognize when a replenishment could be useful. Such personalization must be explainable: understanding a user should not feel like intrusive surveillance.

Maintain continuity in long-running tasks. A coding session lasting several hours, or a complex support case, should not feel like starting over each time a new agent or representative takes over. Memory acts as a relay baton, carrying task state through collection, compression, and reuse.

Turn interactions into reusable assets. Enterprise customers see value in conversations, file changes, and other interactions. Recommendation systems extract patterns from structured clickstreams; memory systems must also work with unstructured text. They can use existing information to serve the user while extracting new profile information from the service process, creating a feedback loop.

Remember relationships as well as facts. Remembering “Your name is Bob” is different from remembering that Bob has recently been under pressure at work and may need encouragement. Relationship continuity depends on accumulated understanding of attitudes, emotions, and concerns, rather than isolated factual labels alone.

2.3 Memory's role in the pipeline

Memory reduces uncertainty on the human side of context engineering. It compresses fragments about a person, a relationship, and a task into structured context that can be reused, preparing the model to understand the user before it begins answering.

3. What Claude's chat and coding experiences suggest about memory

Some users find Claude particularly effective with complex context. Alongside the model's reasoning abilities, context-engineering choices provide a useful lens for examining that experience. Chat and coding applications emphasize different forms of memory.

3.1 Chat: continuity around people and conversations

Anthropic's chat search and memory documentation describes memory of professional context, ongoing work, communication preferences, and technical preferences. Project memory can keep one project's context separate from other projects and standalone conversations. Users can manage memory and use incognito chats that do not contribute to it.

Viewed through entropy reduction, conversational memory addresses three questions:

Who is speaking, and in what role: student, product manager, developer, or customer?
Which ongoing project or topic are we discussing, and what has already been agreed?
What style should this answer follow: explanatory prose, a formal proposal, a list, or code?

Project context, summaries, and editable memory provide continuity. Returning after several days to ask “Where did we leave off?” or “Continue in the same style” should not require rebuilding the entire background.

In this setting, memory primarily reduces uncertainty about people and ongoing narrative threads.

3.2 Coding: continuity around repositories and tasks

In Claude Code, the emphasis shifts toward the repository and the work underway.

Persistent instruction files such as CLAUDE.md describe project conventions, structure, boundaries, and quality expectations. Auto memory can retain useful lessons about commands, preferences, and workflows. These serve as project and working-environment context rather than a comprehensive personal profile. See Claude Code's memory documentation.

Coding memory addresses three kinds of uncertainty:

Repository structure and boundaries: important modules, dependencies, and generated directories that should not be edited.
Task progress: completed refactoring or debugging steps, rejected approaches, and current hypotheses.
Constraints: architectural rules, testing requirements, and security or compliance boundaries.

Context isolation also matters. Subagents can work in separate context windows with scoped tools and tasks, returning useful results to the main conversation. This reduces the burden of keeping every tool result and subtask detail in one large context.

3.3 The design lesson

Memory is a scenario-specific design problem:

Chatbots need intent memory, maintaining identity and conversational continuity.
Coding agents need state memory, maintaining task progress and handling system complexity.

The guiding question is which uncertainty causes the most damage in the current scenario. Is the assistant forgetting who the user is, or misunderstanding code dependencies? Recognizing that difference is more useful than simply increasing the amount stored.

4. “Attention before Attention”: storage and retrieval challenges

Building Tencent Cloud's Memory product has exposed many practical limits to the theoretical picture. Memory engineering involves allocating attention under constraints on compute and latency.

Self-attention determines what the model focuses on within its input. A memory system must first decide which information enters that input at all. This is “Attention before Attention”: a good selection helps the model, while a poor one can make memory itself the largest source of noise.

4.1 Storage: preserve details without losing structure

Personalization creates an incentive to capture user history. But merely storing more information, without a schema, increases uncertainty rather than producing usable memory.

Three failure modes are especially important.

Over-sparsity. A system records every conversational turn as an Event but loses the higher-level task structure. Retrieval then searches thousands of loosely related fragments. Without a coherent context chain, the model cannot reconstruct what happened. Storage needs a schema that retains relationships and task structure.

Over-abstraction. To save tokens and storage, a system compresses a hundred turns into a short conclusion. Intermediate evidence disappears. In coding or teaching, “The user tried this approach and it failed” may matter more than the final outcome. Losing that information causes the assistant to recommend failed approaches again. Summaries should retain the intermediate state needed to continue the task.

Isolated memories. An Event has no Scene ID or Task ID anchoring it to a situation. Retrieval may then bring a coding preference into a cooking conversation, or otherwise mix unrelated contexts. Group fragments into blocks with explicit situational boundaries. Isolation is fundamental to retrieval accuracy.

4.2 Retrieval: relevance, latency, and generalization

Retrieval is where many of the strongest business concerns appear. Practical systems face competing demands for quality, speed, and generalization.

Avoid context contamination. Enterprise users often prefer retrieving less information to retrieving something misleading. Bringing an obsolete price into a new quotation, for example, increases uncertainty and can corrupt the answer. Relevance alone is insufficient; memories must also be unambiguous in their applicability.

Avoid the vector-similarity trap. A strategy overly dependent on similarity to the current query can miss its deeper references. “That old problem again” may refer to a database deadlock discussed last Tuesday. Surface-level similarity does not resolve that reference. Memory needs situational reasoning and, for some questions, multi-hop retrieval.

Handle multi-hop retrieval within a latency budget. Valuable memories can be connected indirectly. Candidate retrieval, reranking, and a small agentic search process all add work. The engineering discussion here uses a 500 ms budget for the responsive retrieval path; fitting these operations into it is an architectural challenge. Deeper agentic searches may take longer.

Return information the model can use. Retrieval should not insert unexplained fragments from an old conversation. Results need concise wording, clear context, and enough background to explain why they matter now.

The goal is to select the few memories that reduce uncertainty in the current decision, within the available time.

4.3 What “Attention before Attention” means

Think of the model's attention as deciding whom to listen to in a room. Memory's attention decides who enters the room.

The source article illustrates the cost of attention using the quadratic O(N²) relationship of standard dense self-attention. A memory system works earlier in the pipeline, screening input before it reaches the model's finite context window.

Its job is to admit useful signals and keep out noise. The 500 ms figure is an engineering budget discussed in this design, rather than a universal latency guarantee for every retrieval operation.

5. Turning layered memory into an engineering architecture

Keeping complete information, retrieving precisely, reasoning deeply, and responding quickly create competing requirements. Adding a vector database alone does not resolve them.

The approach explored in Tencent Cloud's Memory engineering work uses information hierarchy: three storage layers and three retrieval paths, balancing preservation with efficient use.

5.1 Three storage layers: Event, Scene, and Record

The system progressively organizes information rather than simply dumping conversations into storage. Events retain details, MemoryBooks preserve task context, and Records capture dense, reusable information.

Event: the original evidence layer. This layer records who said or did what, and when, in chronological order. It avoids lossy compression of the original content and serves as the source of truth for higher layers. If a summary leaves out an important detail, the system can return to the original evidence.

Scene: the task and situation layer. Events are grouped by task or situation into MemoryBooks. A MemoryBook contains Scenes, such as “March 1, 2025 mathematics lesson: adding and subtracting fractions.” Each Scene links key source passages with intermediate conclusions.

Retrieval can then return both a statement and its situational background: which lesson it came from, or which project discussion established it. That structure helps prevent context from unrelated situations being mixed together.

Record: the long-term information layer. High-value information is extracted across MemoryBooks: user profiles, stable preferences, and important timeline events. Schemas can be customized for the business, such as learning progress in education or brand preferences in commerce.

This turns extensive interaction history into a compact, structured profile that supports intent interpretation at the start of a conversation.

The source architecture also depicts situation recognition, scenario-based extraction and merge policies, and multiple indexes: temporal, semantic, and graph-oriented. Retrieval has both a fast candidate-selection and ranking path and an agentic path that plans, searches, reflects, and constructs an answer.

5.2 Three retrieval paths: from recent context to deeper history

Current conversation: use recent Events. The most recent turns can be supplied directly to the context window. This preserves the immediate exchange and reduces the need to repeat requirements within a short conversation.

Task context: reactivate a MemoryBook. When a task spans turns or days, a Session ID or Task ID identifies its continuing context. The MemoryBook carries progress forward.

An important technique is asynchronous prefetching. Before the next question arrives, the system may use the current situation to load likely relevant material. Entering a student's final-exam review, for example, can trigger retrieval of earlier mistakes. Moving work out of the immediate request path helps meet a tight response budget.

Long-term records: combine a fast path with deeper agentic search. Vector and keyword retrieval can quickly select relevant Records, such as a preferred form of address or a dietary restriction.

More complex requests, such as “What was I doing on this day last year?” or “Summarize my coding style over the past month,” may need several retrieval and reasoning steps. A small internal agent can search iteratively and connect evidence. This path takes longer but addresses questions a single retrieval pass cannot resolve.

5.3 Observations from internal evaluation

The source article reports three outcomes from internal evaluation of this layered approach.

Temporal recall. On time-sensitive questions such as “What was I doing on this day last year?”, the reported accuracy was approximately 45% using the base Qwen3-coder model and 88% after adding layered Memory. These are results reported for that internal evaluation; the article does not supply a public benchmark protocol or sample size, so they should not be generalized into an accuracy guarantee.

Less repetition in long-running work. In coding and teaching scenarios, users needed to repeat requirements and constraints less often. Memory helped preserve the task's structure across sessions spanning multiple days.

More stable personas and continuity. Role drift and breaks between sessions were reduced. Memory acted as persistent support for an agent's assigned role instead of a collection of disconnected fragments.

These observations concern the design and evaluation described in the original article, not a benchmark claim for every deployment of the open-source project linked here.

6. From memory engineering to digital presence

Stepping back from implementation, context engineering raises broader questions about how people and machines share understanding.

6.1 Who will perform entropy reduction?

Context Engineering 2.0 sketches a possible shift in responsibility as machine intelligence develops.

Today, engineers build scaffolding around models: memory systems, knowledge bases, tools, prompts, and storage strategies that filter noise and supply context. In the paper's prospective CE 3.0 and CE 4.0 stages, more capable machines could increasingly perceive, infer, and construct context themselves.

Memory could then become an active part of attention: discovering useful connections in large amounts of history, including connections people have not explicitly identified. This is a proposed direction of development, rather than a feature available in all current systems.

6.2 Digital presence: a structured representation of a person

An ambitious vision for context engineering is “digital presence.” A well-designed memory system can represent aspects of a user's knowledge, habits, decision-making style, and emotional preferences, rather than merely retaining logs.

Such a representation gives an assistant a basis for understanding the user over time. Interactions can feel continuous instead of a series of disconnected computations. The value comes from being understood, rather than from storage alone.

6.3 A question beyond engineering

When designing memory hierarchies and reducing uncertainty for a machine, we are trying to make interactions smoother and more useful. At a longer time scale, we may also be constructing a computational form of self-narrative: a stable representation of “who I am.”

How do we make machines useful while preserving a person's freedom to change, remain open-ended, and resist being reduced to a fixed profile? That may become a central philosophical question for future context engineering.

7. Three questions to ask before building a memory system

7.1 Which uncertainty matters most?

Resources are finite. Identify the main business problem before trying to solve every form of uncertainty at once.

Intent uncertainty. The model struggles with user identity or implicit needs and repeatedly asks for clarification. Optimize for understanding who the user is, their preferences, and what the current message implies. Relevant scenarios include personal assistants, companionship applications, and personalized recommendation agents.

Knowledge uncertainty. Documents, logs, and databases contain extensive information, but retrieval returns noise or fails to locate the useful passage. Optimize for supplying the evidence the current task actually needs. Examples include enterprise search, document question answering, and support knowledge bases.

Process uncertainty. In a long task, the assistant forgets initial constraints or loses track of its progress. Optimize for stable task state and forward movement. Coding assistants, AI tutors, and complex ticket workflows are typical examples.

7.2 Does the architecture address the key engineering questions?

Hierarchy. Distinguish raw Events, task or Scene context, and long-term profiles. A flat store makes retrieval harder to organize; use layered storage and retrieval where the use case calls for it.

Namespaces and isolation. Keep users, projects, and business lines appropriately separated. Preventing cross-user and cross-project contamination is essential to both security and retrieval accuracy.

Storage versus use. Separate frequently needed context from infrequent detail. Core role definitions and critical constraints should be readily available; historical conversation detail belongs in a MemoryBook or another retrievable store until it is needed.

Monitoring and feedback. Capture and correct mistaken memories. When a user identifies an error, the system should use that signal to update the relevant information instead of allowing it to accumulate and be reused.

7.3 Can you explain the business value?

“We are adding vector storage” describes an implementation. “We are reducing uncertainty in this workflow” describes a user benefit:

Teachers do not have to repeatedly reconstruct each student's learning history.
Support representatives can take over a transferred case without rereading every earlier ticket.
Users do not have to restate their identity and requirements every few turns.

Building the underlying system from scratch takes substantial work. Tencent Cloud's Memory product offers a practical reference for the layered approach discussed here: MemoryBooks maintain task continuity, long-term profiles accumulate preferences, and fast retrieval works alongside deeper agentic search.

The aim is to reduce repeated infrastructure work so teams can focus on the value of their applications. For the cloud product discussed in the original article, see the Tencent Cloud Memory documentation.

Open-source project: TencentDB Agent Memory

Source: Original Chinese article

How to Make Your First Open-Source Contribution: TencentDB Agent Memory

ellytan — Mon, 12 Oct 2026 08:27:08 +0000

Open-source project: TencentDB Agent Memory

When preparing to contribute to open source for the first time, many people head straight for the source code. The more files they open, the more questions they have: Do I need to understand the entire project? Does a contribution have to involve code? Would fixing a small issue really matter?

My advice is to start with a problem you can explain, verify, and follow through on.

I care more about whether a contribution helps someone else continue the work. A reproducible bug report, an integration example that actually runs, or a proposal that explains its tradeoffs can move a project forward. Lines of code are a poor measure of contribution value.

Using TencentDB Agent Memory as an example, this article explains how to turn an intention to participate into concrete collaboration. The project's Community Contribution and Collaboration Guide describes participation routes, branch purposes, and community responsibilities. It is a useful starting point.

Use the project and find a real problem

TencentDB Agent Memory is an open-source memory project for AI agents. It offers personal and team memory, helping agents preserve, organize, and reuse conversations, task experience, documentation, and code. Team memory centers on four asset types: Chat Memory, Skill, Wiki, and CodeGraph, with sharing, access control, and agent-specific asset assignments.

There are many ways to explore it. Connect an agent client you already use, import a project document, create a team, or use the SDK to write and retrieve a memory. Completing one real workflow is a good way to discover a concrete contribution opportunity.

Does an integration tutorial explain all its prerequisites? Does an error message help a user identify the cause? Does an example run in the environment specified by the documentation? These are useful questions to investigate, rather than claims that the project already has those problems.

You do not need to begin by changing the core algorithms. Reproduction steps, checks of English and Chinese documentation, and integration validation can all be meaningful contributions. The project's definition of a Contributor includes code, documentation, reproduction, tests, practical use cases, and useful review feedback.

Check the branch and scope before choosing a task

Branch selection matters in this repository. According to the current contribution guide:

main focuses on personal memory through plugin integrations for OpenClaw and Hermes.
feat/server focuses on personal memory through standalone services, HTTP APIs, and SDKs.
feat/server_team focuses on team memory, asset collaboration, access control, Memory Hub, and Proxy capabilities.

The current default development branch is feat/server_team, and PRs should normally target it. Use main or feat/server only when maintainers direct your change there. For work on personal memory or changes spanning several branches, confirm the scope in the related issue first. Always check the latest guidance when you start, because development arrangements can change.

Next, look through the issues:

good first issue identifies tasks suitable for newcomers, with a clear scope and acceptance criteria.
help wanted invites community collaboration and usually requires some project familiarity.
need-reproduction calls for minimal examples, environment comparisons, or validation results.
need-design means the design still needs agreement; proposals and tradeoff analysis are useful here.

A label is an entry point. The full discussion determines what needs to happen. Before taking a task, I would read the expected behavior, acceptance criteria, existing proposals, and any participation restrictions, then check whether someone is already working on it.

For example, you could leave a comment like this:

I'd like to help with this issue. I'll first reproduce it using the reported version and environment, confirm the scope, and propose a change. For now, I plan to address the configuration instructions in the integration documentation. If the investigation points to a code change, I'll discuss it here first. Is another contributor already working on this?

That gives maintainers more to work with than simply saying "I'll do it." It also helps other contributors see which work is underway.

Write an issue someone else can follow

A useful issue lets someone who has never seen your environment understand the problem.

Search existing issues and PRs before opening a new one. If the same problem is already being discussed, add your environment differences or reproduction results to that thread.

For a new issue, include the project branch and version, agent client, deployment method, actual behavior, expected behavior, and reproduction steps. If you can identify the affected area, name it: MemoryCore, MemoryProxy, MemoryKnowledge, MemoryPanel, an SDK, or deployment scripts.

Write the steps so someone else can follow them. If the problem only occurs with a particular configuration, explain what differs from a working setup. If you cannot reproduce it consistently, report the conditions you have tried.

If you do not know which module is responsible, describe the use case first. When a template field does not apply to your client, enter "Not applicable" and explain your actual environment rather than forcing it into an OpenClaw-specific field.

Remove API keys, application credentials, and other sensitive information before posting logs or screenshots. Report security vulnerabilities privately to agentmemory@tencent.com, following the project guide.

Take a small change from fork to pull request

Suppose you want to improve an integration document and have already agreed on the scope in an issue. The following example uses Git Bash or another Bash environment. For exact development requirements, follow the repository's contributing guide.

Fork the repository on GitHub, clone your fork, and add the original repository as upstream:

# Replace YOUR_GITHUB_USERNAME with your GitHub username.
git clone https://github.com/YOUR_GITHUB_USERNAME/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory

git remote add upstream https://github.com/TencentCloud/TencentDB-Agent-Memory.git
git fetch upstream
git switch -c docs/clarify-setup upstream/feat/server_team

Here, origin points to your fork, while upstream points to the original project. Base your working branch on the branch you intend to target, so unrelated development tracks do not get mixed into one PR.

Make and validate the change. For documentation, check commands, paths, parameters, and examples. For code, run the tests described by the affected module. Add tests for new features; for a bug fix, prioritize a regression test that reproduces the problem.

Prepare the environment according to your scope. The main service modules use Node.js 22.16.0 or later. Changes to the Python SDK or relevant migration scripts require Python 3.9 or later. Docker is needed when building images or running the full local service stack. Consult the module documentation for dependencies and startup commands rather than assuming every directory has the same development scripts.

Commit using the project's Conventional Commits format. For example, if you changed INSTALL_CN.md:

git add INSTALL_CN.md
git commit -s -m "docs(docs): clarify setup prerequisites"
git push -u origin docs/clarify-setup

Every commit needs a DCO sign-off. The -s option adds a Signed-off-by line using your current Git identity, so check your configured name and email first. This sign-off is different from a GPG cryptographic signature.

Create a PR on GitHub with the original repository as the base repository, normally feat/server_team as the base branch, and your fork's working branch as the compare branch.

Make the change understandable and verifiable

Before submitting a PR, I would ask: Can someone seeing this change for the first time understand what it solves and how to check it?

The project's PR template asks for a description, related issue, change type, self-test checklist, and additional notes. Filling in the sections is the beginning; the description should provide enough evidence for a reviewer to assess the change.

For a documentation update, explain which prerequisite was missing, what you added, whether you verified the procedure, and which environments remain untested. For changes across modules, identify the primary area, related modules, and interfaces that need coordination.

Report only the validation you actually completed. A successful Linux check does not establish that every operating system works. Editing documentation does not itself verify the underlying code behavior. Clearly stating what you have not checked is more useful than ticking unsupported boxes.

After submission, follow up on CI and review. Feedback may concern compatibility, interface conventions, test coverage, or maintenance costs. Update the change and validation results where appropriate. If you disagree, explain the evidence and tradeoffs so the discussion stays focused on the problem.

The project aims to provide an initial issue response within 24 hours. That is not a promise to resolve the problem or merge a PR in that time. The reviewer accepting a PR communicates the first-review timeline according to its scope. An authorized maintainer or Committer makes the final merge decision.

Keep participating after the first contribution

After completing a small task, you could add tests, help reproduce a related issue, or learn more about other discussions in the same module. Staying with one area is a useful way to build understanding.

TencentDB Agent Memory defines three community roles: Contributor, Reviewer, and Committer. A first meaningful contribution can establish you as a Contributor, and it need not involve code. Reviewer and Committer responsibilities require sustained participation, relevant project understanding, and invitation or explicit authorization from maintainers. They are not titles automatically awarded after a fixed number of PRs.

The project also recognizes contributions. Merged changes from external contributors are credited in the corresponding Release Notes with PR links. First merged PRs and impactful contributions may be featured in community updates. Contributors may have opportunities for exclusive merchandise, mentor matching, and community speaking, subject to the guide and subsequent announcements.

I would treat these opportunities as outcomes of continued collaboration. Open-source work gives you practice in describing problems, controlling scope, explaining technical decisions, and leaving work that another person can continue.

The same responsibility applies when using AI assistance. Tools can help you read code, draft tests, or organize documentation, but you need to understand the submitted change and remain responsible for its quality. Reviewers need a contributor who can explain and verify the work.

If you are ready to begin, open the contribution guide, choose a workflow you can understand, and find a problem you are willing to follow through on. Even without a code change, a solid reproduction record or validation result can help the project move forward.

Project: TencentDB Agent Memory

Community entry point: Contribution and Collaboration Guide #1639

Development and submission requirements: CONTRIBUTING.md

Switching Agents Without Starting Over: TencentDB Agent Memory Adds DeepSeek Harness Support

ellytan — Fri, 09 Oct 2026 11:56:43 +0000

Author: Tencent Cloud Database Team (腾讯云数据库团队)

Open-source project: TencentDB Agent Memory

Completing a task with an AI agent often produces more useful knowledge than the final deliverable captures.

Writing a technical article requires agreement on product terminology, feature boundaries, the intended audience, and how claims should be expressed. Fixing a bug requires understanding business constraints, the investigation process, and which approaches have already been tried. When the task is finished, that knowledge is scattered across conversations, documents, and code. Switch clients, start a new session, or hand the work to another agent, and someone has to explain it all again.

Agents are getting faster at executing tasks. Transferring experience still takes human time.

TencentDB Agent Memory has added support for the DeepSeek Harness (DSH) desktop client to help connect that handoff. Developers can associate existing memory assets with a DSH session within their authorized access scope, reusing project context, business constraints, and task methods accumulated by other connected agents.

The integration gives a team's existing experience another place to be used. It also raises a practical question: when tools keep changing, how can that experience stay with the team?

From a conversation to assets the next task can use

A long conversation can contain confirmed facts, tentative guesses, rejected approaches, and a method that eventually worked. Before another agent can take over, that material needs to be organized.

TencentDB Agent Memory uses Memory Hub to manage four types of assets:

Chat Memory preserves information and experience from conversations, helping subsequent tasks retain project context, business constraints, and earlier decisions.
Skill captures reusable task methods, including checks and workflows that have already worked.
LLM-Wiki organizes document knowledge, giving tasks access to product information, designs, and specifications.
CodeGraph represents code relationships, helping agents understand code structure, dependencies, and engineering context.

Assets can be associated with designated agents. Memory Hub manages their ownership, versions, and visibility. Developers can also import existing documents, code repositories, and historical sessions to give a new agent an initial body of knowledge and experience.

Decoupling assets from a specific agent framework makes it possible to reuse the same accumulated knowledge across connected tools. Clients provide the working interface, while the team continues to maintain its own assets.

A technical writing example: handing agreed guidance to the next agent

The mechanism applies to development work and suggests a way to organize collaboration on technical content.

Consider an article explaining how to integrate a new release. Research gathers official documentation. Drafting establishes what the product supports. Review corrects wording that could mislead readers. That work remains useful when the team later creates a tutorial, translates the article, or writes about another update.

A team could organize assets around that workflow as follows:

A research agent gets access to product documentation and confirmed information, keeping supporting sources available as it gathers material.
A writing agent gets terminology guidelines, audience context, and the article production workflow, reducing the need to establish the same guidance again.
A review agent gets feature boundaries, previous review comments, and a checklist, helping it check whether claims go beyond confirmed capabilities.

This is an illustrative application scenario. Its practical results need to be evaluated in real tasks. Writing guidelines can be organized as document knowledge, and a review process that works can be captured as a Skill. If an article discusses a code implementation, the relevant CodeGraph can be associated as well.

Different roles need different assets. Research material, drafting constraints, and review records should be assigned according to the task so irrelevant information does not crowd the context.

With the DSH desktop integration, users can associate those existing assets from a new working interface and build on earlier work in the next task.

Connecting the DSH desktop client to team memory

This integration uses the Memory proxy service. Before entering settings in the desktop client, prepare:

A Memory proxy service with the DSH model upstream configured and session initialization enabled.
A user_key for application use.
The complete DSH integration endpoint supplied by your deployment.

Once those prerequisites are ready, configure the desktop client in three steps.

Step 1: Configure the model connection. Open DSH's Settings → Models and edit the DeepSeek (deepseek-official) card. Enter the application user_key supplied by your platform. Expand Custom Settings within the card, enter the complete integration endpoint, and save. The labels here are English translations of the controls described in the Chinese setup guide; their wording may differ in your client.

Step 2: Start a new conversation. Send a message using the configured model to enter the session initialization flow.

Step 3: Associate team assets as needed. Choose whether to associate team assets for the current task, then follow the initialization prompts. Asset organization, visibility, and agent associations can be managed in Memory Hub.

After configuring the client, use a narrowly scoped task to check the connection. For example, check whether a new session can use the associated project context, then whether it follows an established business constraint. This makes it easier to determine whether the assets are actually available to the current work.

For deployment and full configuration details, see the installation guide or its Chinese version.

Reusing experience requires clear boundaries

Reuse across tools depends on two conditions: the assets are ready, and the current agent is authorized to use them.

Teams therefore need to maintain asset ownership, versions, and visibility. Personal drafts, client information, and shared team guidelines may require different access boundaries. Updated product rules also need to be distinguished from older conclusions.

Team leads need to decide which experience can be shared, which assets belong with each role, and how outdated material should be updated. Users need to check that the proxy service, model upstream, and asset-sharing scope fit the work they are doing.

Memory can supply historical evidence and reusable methods. Final deliverables still need review. Release descriptions and integration tutorials, in particular, should reflect the current documentation, and their instructions should be checked in the target environment.

Keeping work moving when tools change

Alongside DSH, TencentDB Agent Memory provides integration support for clients including Claude Code, CodeBuddy, Codex, WorkBuddy, OpenCode, Hermes, and OpenClaw. Each client has its own configuration documentation.

As work spreads across IDEs, command-line tools, and desktop applications, teams will switch agents more often. Preserving experience as assets that can be managed and associated with agents may reduce the cost of repeatedly explaining context and rediscovering methods at each transition.

The DSH desktop integration adds another entry point to that approach. The next questions are practical: can the same experience be used correctly in a new task, and can it be expanded and corrected after use?

Let each task leave behind experience that the next task can use.

Open-source project: TencentDB Agent Memory

Release history: CHANGELOG

Building Team Memory for AI Agents

ellytan — Fri, 09 Oct 2026 06:55:12 +0000

Open-source project: TencentDB Agent Memory

Author: Tencent Cloud Database Team (腾讯云数据库团队)

As agents become deeply embedded in software development, the most immediate change is speed: writing code, fixing bugs, calling tools, and executing workflows all become noticeably faster. But real team collaboration is revealing another bottleneck. Models are gaining execution capacity faster than teams are gaining collaboration bandwidth.

What slows delivery is often not whether a piece of code can be generated. It is whether the next person, agent, or session can accurately inherit why a task was approached a certain way, which alternatives were tried, which pitfalls have already been encountered, and which constraints must be respected.

This is the problem TencentDB is addressing with Agent Memory: enabling a team's useful context to enter the development runtime in a form that can be understood, invoked, and governed.

1. Why teams need memory now

In a traditional development workflow, a task might take several days, so spending half a day aligning on its background may not seem particularly expensive. When agents compress execution into half a day or less, however, the background scattered across handoffs, meetings, documents, and chat histories becomes a larger source of wasted effort.

The problem is not a lack of records.

Most teams already have plenty of code, documentation, discussions, and meeting conclusions. What they lack is context that the next task can use directly. Code shows the result without necessarily explaining the reasoning behind it. Documents record conclusions reached at a particular point, but may not establish whether those conclusions still hold in the current version. Collaboration produces extensive discussion without consistently preserving reusable grounds for judgment.

What teams lose is the reasoning, constraints, and evidence behind their history. This is why TencentDB frames the problem as collaboration bandwidth: too little context can be correctly understood and directly applied to a task per unit of time.

Team memory should therefore reduce three costly forms of repetition:

Repeated explanation: the same background must be explained to different people and agents.
Repeated trial and error: a new task encounters pitfalls that someone else has already worked through.
Repeated decision-making: conclusions that should have been preserved have to be discussed again.

As development shifts from individuals completing tasks to people working with multiple agents, team memory will increasingly become a foundational capability.

2. Team memory is more than long-term chat storage

Team memory is easily mistaken for storing more conversations. From an engineering perspective, that is far from sufficient.

TencentDB makes a clear distinction: personal memory supports continuity; team memory supports the transfer of knowledge and experience.

Personal memory asks whether a person and their agent can continue the current task in the next session. Team memory asks whether the team can preserve earlier judgments and methods after a change of person, agent, or framework. The difference extends beyond the size of the sharing scope: the system serves the team as a whole.

Team memory must consequently function as an asset system. Information belongs in the team asset layer when it can actually be used in a subsequent task and provide reusable value.

TencentDB identifies four core requirements:

Understandable: structured representations that agents can consume directly, rather than piles of raw long-form text.
Orchestratable: assets can be combined according to the task, role, and stage of work, rather than inserted statically into context.
Portable: assets belong to the team rather than to a particular agent framework or tool.
Governable: provenance, versions, permissions, approvals, and rollbacks are traceable.

Team memory is therefore a team asset system organized around task execution at runtime.

3. Four foundational capabilities and a unified asset catalog

To bring team memory into development workflows, TencentDB starts with four foundational capabilities:

Memory: preserves background, constraints, historical decisions, and task conclusions.
Skill: captures validated methods, checks, and execution paths.
Wiki: reads and interprets the documentation landscape.
CodeGraph: interprets code structure, dependencies, and engineering context.

Together, these capabilities span requirements review, solution design, implementation, bug fixing, delivery, and retrospectives. The unified asset catalog connecting them is especially important.

Without a shared model, Memory, Skill, Wiki, and CodeGraph would become four disconnected stores. A migration to another agent framework or a change in the team's toolchain could force the assets to be rebuilt.

TencentDB therefore defines a common asset model that describes the essential information associated with each team asset:

Which team, repository, task, and role it belongs to.
What source evidence supports it, who created it, who reviewed it, and who is responsible for it.
Its current version and lifecycle state, including any time-to-live (TTL).
Its permission boundaries, which roles can see it, and which agents can use it.
Which requests have retrieved it and which tasks have benefited from it.

A consistent representation makes it possible to move and reuse assets across agents, tools, and projects.

4. Runtime orchestration is the critical step

Many memory systems begin with retrieval and concatenation: a user submits a request, the system retrieves semantically similar material from a knowledge base, and that material is appended to the current context. This can look effective in a demonstration, but problems become more apparent in extended development workflows.

Semantic similarity does not establish task relevance.

A bug-fixing task may have little practical connection to a design document that happens to look similar in text. Success may instead depend on constraints, previously rejected approaches, version limitations, and historical evidence. Similarity-based retrieval alone can introduce noise while missing the information that matters most.

TencentDB changes the sequence from “retrieve, then concatenate” to “plan, then retrieve.”

At runtime, the system first identifies the team, repository, role, and task type. It determines whether the work involves bug fixing, review, solution design, or delivery. It then creates an asset plan for the task: what must be injected, what should be queried on demand, and what must be pinned to a particular version. Finally, token budgets, security boundaries, and confidence requirements determine the injection strategy.

Context is a runtime product. It must be assembled dynamically around the task's goal, rather than filled with everything that might be useful.

5. Proxy + Core: making memory infrastructure

TencentDB separates the architecture into two key components: Proxy and Memory Core.

Proxy is the orchestration layer for team assets at runtime. Positioned between user requests and the target model, it handles asset planning, context injection, security policies, cost control, trace observability, and routing governance. Users route their model requests through Proxy, giving the system a unified runtime entry point.

This separation has two benefits.

First, team assets are independent of a specific agent framework. New clients, different development tools, and evolving agent harnesses can reuse the same asset system as long as they use the shared protocol.

Second, runtime logic and data-plane logic remain separate. Proxy is stateless, while authoritative asset records, versions, permission relationships, and retrieval histories reside in Memory Core. Replacing a runtime component does not erase the team's assets.

Memory Core provides a unified data plane. Different asset types can use different indexes and processing methods while remaining part of the same authoritative team asset model. Synchronous paths stay as lightweight as possible. Asynchronous paths handle extraction, organization, candidate generation, vector processing, and state transitions, minimizing the extent to which memory extraction blocks the main workflow.

From a database product perspective, this architecture gives team memory the properties of infrastructure: a unified entry point and data plane, versioning and auditing, permissions and lifecycle management, and mechanisms for graceful degradation and recovery.

6. What should become a team asset?

A usable memory system must decide what is worth retaining.

Writing every piece of process data directly into shared storage would accumulate noise and could spread incorrect experience across the team. TencentDB therefore emphasizes lightweight, asynchronous capture into a candidate state. Developers should not have to complete a form after every task.

Four types of information are particularly valuable as team assets:

Established conclusions and explicitly rejected approaches.
Constraints, prohibited actions, and mandatory workflow rules.
Diagnostic conclusions, reproduction steps, and valuable troubleshooting experience.
Validated methods, checks, and execution paths that can become Skills.

Routine process chatter, repeated confirmations, temporary debugging output, intermediate guesses, and personal preferences with no shared value should stay out of the shared team asset layer.

All candidate assets must pass three gates:

Structure: represent information in fields that support retrieval, selective inclusion, and governance.
Provenance: retain a path back to the original session, evidence, and responsible person.
Veto: low-confidence candidates do not take effect directly; they enter a state requiring review or rollback.

The principle is straightforward: an omission is preferable to an incorrect asset.

Once memory enters the runtime, agents can amplify its effects quickly. An incorrect shared asset can cause more damage than a few missing historical records.

7. Governance must operate at runtime

Once team memory enters production, governance must extend into execution.

In TencentDB's design, permissions, quality, lifecycle state, confidence, evidence retention, and cost budgets apply throughout capture, retrieval, injection, and write-back.

Permission isolation determines who can read or write an asset and which agents can use it. Quality control prevents incorrect experience from being amplified again. Lifecycle management prevents outdated conclusions from entering current tasks. Evidence retention records which context a delivery used and which asset versions were retrieved. Budget controls prevent the memory system from increasing context costs without restraint.

Runtime governance is what makes team memory suitable for production development. Without it, the system remains a knowledge-management interface rather than infrastructure for everyday collaboration.

8. From task assistance to organizational development capability

Team memory's value extends beyond making an individual agent more capable.

TencentDB envisions a gradual progression:

Support individual tasks. Supply the background, constraints, code relationships, and methods needed for the current task, reducing repeated explanation and repeated mistakes.
Reuse team workflows. Turn frequent scenarios such as reviews, incidents, and handoffs into stable assets and standard methods.
Build an asset network across projects. With a shared identity, permissions, and governance model, move rules, methods, and conclusions across repositories and teams.
Support organizational decision-making. Use historical evidence, asset retrieval records, and delivery outcomes to support long-term risk identification, reuse of architectural decisions, and ongoing strategy improvement.

The goal is for each completed task to add something useful to the organization. Tasks leave factual records. Governance turns those records into assets. Workflows reuse the assets. The outcomes of that reuse then improve rules, budgets, and gates, creating a continuous development feedback loop.

9. Conclusion

As agents become part of the infrastructure for team collaboration, the role of databases and data infrastructure is changing.

The question is expanding beyond whether data can be stored and retrieved. Enterprises also need to know whether historical experience can be used by the appropriate person or agent, for the appropriate task, within the appropriate boundaries.

TencentDB's work on Agent Memory follows this direction: turning development history into assets that operate at runtime, and moving memory capabilities toward a more stable, governable infrastructure layer.

The goal of team memory is for every task to leave the organization with something the next task can build on.

Open-source project: TencentDB Agent Memory

Make Each Mistake Only Once: Team Memory in Practice with TencentDB Agent Memory

ellytan — Thu, 08 Oct 2026 09:10:43 +0000

GitHub: TencentDB Agent Memory

As execution becomes abundant, how should organizations rebuild the flow of information and the inheritance of experience?

Coding agents are rapidly expanding what one person can accomplish. But the bottlenecks in enterprise development do not disappear automatically. Once a task crosses people, sessions, code branches, and permission boundaries, the scarce resource is often no longer code generation. It is the bandwidth of collaboration.

This article explains how TencentDB Agent Memory turns task trajectories, project knowledge, code structure, and working methods into governed memory assets. We discuss what we learned from 2,600 sessions, real Redis development cases, and developer interviews, and how those findings changed our product design. In a related-case evaluation using SWE-bench tasks, learning from earlier cases increased completion from 60% to 80%. In a separate set of 50 exceptionally long, difficult tasks, memory reduced cost by about 19% while also improving success. These are scoped experimental results, with limitations discussed below.

1. Execution is growing faster than collaboration bandwidth

While building Agent Memory, we kept seeing the same contrast: models were becoming stronger and individuals could move faster with an agent, yet delivery slowed when work entered a setting with multiple people, agents, and projects. The issue was less often whether code could be generated and more often whether information could be inherited accurately across people, sessions, branches, and permission domains.

A person and their agent usually share the same immediate task context: the goal, what has already been tried, and why an approach was abandoned. When another person or agent takes over, the handoff may contain only a conclusion, a file, or a diff. The recipient sees the result without the background, constraints, and reasoning that produced it. The information exists, but the task still has to be understood from scratch.

Organizations usually do not need more messages. They need usable context that the right person or agent can understand and apply within the correct permission boundary. AI lowers execution costs, but it does not automatically increase that bandwidth. Faster execution can make the costs of lost context, repeated exploration, and branch conflicts more visible.

1.1 What the one-person company reveals

Here, a one-person company, or OPC, means an AI-native organizational model: one principal decision-maker works with multiple agents, delegating research, development, content, and operations while retaining responsibility for goals, judgment, and acceptance.

Agents are expanding the range of tasks an individual can execute. METR's measurements of frontier models suggest that, for self-contained tasks primarily in software engineering, machine learning, and cybersecurity, the task duration associated with a 50% success probability has historically doubled roughly every seven months. Anthropic's privacy-preserving analysis of approximately 400,000 Claude Code sessions also reported that coding-agent activity in GitHub projects had more than doubled since late 2025, with the users in that analysis averaging about 20 hours per week. One vendor's data cannot represent an entire industry, but it suggests that agents are becoming a persistent work interface for some users.

OPC efficiency also comes from fewer handoffs, fewer organizational barriers, and concentrated goals. In Carta's startup sample, about 36% of companies founded in 2025 had a solo founder, up from 31% in 2024. This does not establish that mature one-person companies are already widespread. It does point to a useful research question: as individuals gain access to more execution capacity, how much work can be done with fewer interpersonal interfaces?

The OPC does not eliminate collaboration. It turns much of it into collaboration between one person and several agents sharing context. It illustrates one possible upper bound for AI-native execution, but enterprises cannot simply copy the model.

1.2 Enterprise scale adds boundaries

An enterprise differs from an OPC in more than headcount. A real team must manage roles, project isolation, branches and versions, data security, and accountability. A useful approximation is:

Collaboration cost ≈ number of handoffs × cost per handoff + conflict-resolution cost + permission and compliance cost.

This is not a financial model. It separates three questions that are often conflated: Can the information be found? Can it be understood? Is its use authorized? Meetings, messages, and documents are not bandwidth in themselves. Information becomes effective context only when it is complete, trustworthy, applicable to the current version, and usable in the task.

The most dangerous conflicts may be small differences between branches. Two deployment skills can look almost identical, yet one reads config/prod/ while another branch uses conf/prod/. Two test procedures may adjust the same parameter, but one multiplies it by 0.5 and the other by 2. A system that selects the “best” asset solely by semantic similarity can execute a plausible workflow in the wrong directory or environment and even cause an outage.

Our operational definition is therefore stricter:

Collaboration bandwidth is the amount of effective context that the relevant person or agent can correctly understand and directly use per unit of time, within the appropriate permission boundary.

1.3 From an “AI GitHub” to a three-layer organization

A talk by Analemma founder Sun Tianxiang, published by Sequoia China, proposed an organizational metaphor: people work with high cohesion in their own branches and merge at suitable moments. Another person's agent can understand the work trajectory, so the team does not need to repeat trials that have already been validated.

The proposed AI-native organization has three layers: management and resource allocation at the top, people and AI working together in the middle, and a shared foundation of skills, trajectories, and supporting infrastructure at the bottom.

We find the direction useful, but enterprise implementation must include the mechanisms that make GitHub collaboration work: versions, permissions, review, merging, conflict resolution, and rollback. Raw trajectories may contain credentials, customer data, failed attempts, and unconfirmed judgments. Visibility does not make a conclusion trustworthy or appropriate for everyone to see.

Our interpretation is: the upper layer governs information boundaries; the middle layer carries real tasks; the lower layer preserves organizational assets that can be inherited. Together, they form a path from tasks to assets and back to tasks.

1.4 Why specifications matter

Spec-driven development offers a related signal. As agents implement faster, more effort shifts from writing code to expressing intent, constraints, plans, and acceptance criteria accurately—and preserving that task state.

GitHub Spec Kit organizes work as:

Specify → Plan → Tasks → Implement

Requirements and constraints → technical design → executable tasks → implementation and validation

A specification is treated as an evolving shared source of truth, rather than a static document completed before development. Agents amplify the cost of ambiguity: one missing boundary can produce an entire incorrect implementation, while unclear acceptance criteria move rework into design review and code review.

Specifications make intentions machine-readable, move constraints out of chat, preserve task state across sessions and agents, and give reviewers an explicit contract instead of forcing them to infer everything from a diff.

But a specification primarily serves the current task. It does not automatically explain whether a similar problem occurred before, why a historical approach was abandoned, which module experienced a related failure, whether a rule conflicts with another branch, or whether the current task may access that information. Nor does it inherently manage provenance, freshness, versions, and negative feedback.

Specifications make one task's state expressible. Team memory makes validated task state inheritable. The former demonstrates the need for structured context; the latter adds reuse across tasks and enterprise governance.

2. How TencentDB Agent Memory is structured

2.1 The goal is fewer wrong turns in the next task

We define team memory as turning the background, knowledge, code relationships, and methods produced by real tasks into agent assets that can be retrieved, combined, traced, authorized, and continuously updated—and then assembled as needed for future tasks.

This is more than retaining every chat or adding a vector index to a knowledge base. Traditional RAG emphasizes what can be found in a corpus. Team memory must also answer who owns information, which version it applies to, who may use it, which agent should receive it, and how it should be corrected after use. It manages the lifecycle from creation and abstraction to review, use, and retirement.

Memory Hub handles governance and scheduling. A Memory Pack enters the task context shared by a person and an agent. Four types of Memory Asset form the shared foundation. Rather than putting everything into one giant knowledge pool and expecting the agent to find the right information, we keep complete assets in the pool and assemble only what the current identity, task, and permissions require.

The asset pool holds the complete record. The current task receives what is relevant.

2.2 Four asset types preserve four kinds of state

Chat Memory preserves background, constraints, decisions, preferences, and historical interactions. It answers why a judgment was made and which approaches have already been tried, restoring task state without repeated explanation.
Wiki preserves product knowledge, architecture, standards, runbooks, and established conclusions. It provides stable facts and design constraints.
CodeGraph preserves symbols, files, calls, dependencies, and impact paths. It helps determine which modules a change may affect.
Skill preserves repeatable methods, tool calls, boundaries, and validation rules. It makes a verified workflow reusable.

These are not four unrelated document directories. A debugging task may recover historical context from Chat Memory, read architectural constraints from Wiki, identify the impact surface through CodeGraph, and use a Skill to investigate and validate the fix.

They also enter the task at different levels of detail. Chat Memory has layers from raw conversation to stable understanding; Wiki, CodeGraph, and Skill use summaries, bindings, and tool entry points for progressive access.

2.3 Narrow the boundary before searching for relevance

A flat memory pool forces raw records, abstract conclusions, fixed rules, and temporary context to compete for attention. The most similar result may not be the most reliable, nor applicable to the current identity, branch, or task. We therefore separate how memory is formed from how assets are assembled.

Content layers: from evidence to stable understanding

Chat Memory uses an L0 → L1 → L2 → L3 pipeline. Each layer distills the previous one without replacing it:

L0 Conversation: original conversations, timestamps, and full context. High fidelity, low density; useful for checking exact statements and recovering evidence.
L1 Atom: facts, constraints, decisions, events, and instructions. Atomic and structured; useful for precise retrieval of actionable information.
L2 Scenario: memory blocks organized around a project or scenario. Denser context for quickly resuming a category of work.
L3 Core / Persona: stable patterns, long-term profiles, and higher-level understanding. Highly abstracted and updated less frequently; useful for entering the user and team context.

L2 and L3 can establish context quickly. When a task needs specific facts, keyword search, vector retrieval, and source anchors lead back to L1 and L0. The upper layers reduce reading; the lower layers protect against distortion through repeated summarization.

Routing layers: from identity to a context bundle

Identity and scope: establish Team, User, Agent, Task, project, visibility, and ACL. Unauthorized assets never enter the candidate pool; they are not retrieved first and removed later.
Fixed bindings: explicitly attached role rules, task constraints, Wiki resources, and required Skills enter the assembly scope directly. An incidental similarity ranking must not displace organizational requirements.
Dynamic retrieval: within the authorized scope, retrieve additional Memory, Skill, Wiki, and CodeGraph candidates relevant to the task and request intent.
Relevance fusion: use exact retrieval such as BM25 for error codes, filenames, and symbols, and vector retrieval for intent, failure patterns, and similar tasks. Combine them with reciprocal rank fusion, or RRF.
Context assembly: build a Memory Pack according to role, priority, binding, version, and token budget. Asset versions can be pinned for a task to avoid inconsistent rules during execution.

Progressive disclosure: expose the entry point first

Assembly does not mean copying every selected asset into the prompt. Chat Memory can expose a scenario summary before retrieving an original turn. A Skill can expose its name, trigger conditions, and purpose before loading its full procedure and resources. Wiki and CodeGraph initially expose resource names, summaries, and tool entry points. An agent discovers capabilities through /v3/tools/list and retrieves pages, source code, callers, or impact paths through /v3/tools/call.

The prompt explains what is available and why it might help. Tool calls provide details when needed. Result counts, individual lengths, total characters, and timeouts also constrain the process. The goal is a reliable starting point with as little context as necessary.

2.4 Assets belong to the team and are assembled per task

Personal memory preserves continuity between a person and their agent. Team memory preserves organizational experience. Assets therefore need to belong to the Team rather than to a particular agent. Experience trapped in one account, conversation format, or framework cache is closer to a private cache than a team asset.

Framework independence is about ownership and continuity, not just compatibility. Chat Memory, Wiki, CodeGraph, and Skill use a common asset model carrying source, owner, scope, version, ACL, evidence, and state. Different agents read and write through gateways, HTTP APIs, SDKs, or tool interfaces. The agent decides how to plan and execute; Memory lets it start from what the team already knows.

This does not mean giving every agent the same content. Bug fixes may need historical failures, CodeGraph, and troubleshooting Skills. Requirements analysis may need Wiki, Chat Memory, and business constraints. The team owns the complete pool; each role and task receives the relevant subset.

The infrastructure connects all three organizational layers without making business decisions for managers or imposing one agent workflow.

2.5 Turn task outcomes into organizational assets

Raw chat contains evidence, temporary guesses, repetition, and invalidated approaches. Treating an entire trajectory as long-term memory can increase noise and conflict as retrieval grows.

We divide asset formation into four steps:

Segment evidence: split sessions, documents, and repositories into identifiable tasks, turns, pages, symbols, and commits, rather than preserving only a summary.
Extract candidates: identify context, decisions, rules, code relationships, procedures, failed paths, and validation results as candidate Atoms or Skills.
Bind scope: attach Owner, Team, Repo, Branch, Path, Version, Time, ACL, and source evidence. These fields matter as much as the text.
Promote after validation: keep unverified trajectories as low-weight background. Promote content toward stable scenario memory or shared Skills when tests, commits, or human review support it.

At task completion, new context, judgments, relationships, validation methods, and negative feedback become candidates that return to Memory Hub after review. The aim is to retain what was learned, avoid restarting after a handoff, and begin the next task from a saved state.

An asset is a combination of evidence, abstraction, scope, and validation status. Its test is whether it reduces uncertainty in the next task.

2.6 Cold start without waiting years

Teams should not have to wait years for memory to accumulate. Historical sessions can seed Chat Memory and Skills, existing documents can seed Wiki, and repositories can seed CodeGraph. New tasks continuously add evidence.

The infrastructure first captures information the team already has, then lets new tasks validate, correct, and extend it. The purpose is to help the team start from zero less often.

2.7 A worked example: resuming a coding task with memory

Consider a real code path in the TencentDB Agent Memory repository. Knowledge Service exposes Wiki and CodeGraph tools through /v3/tools/list and executes read-only queries through /v3/tools/call. We can use the addition of a CodeGraph impact query to illustrate how an internal coding task could resume with memory.

The modules, interfaces, and constraints below come from the repository. The task narrative is an engineering reconstruction to explain the workflow, not a verbatim account of one person's work or a particular commit. It makes no additional claim about measured efficiency.

The external short name impact must enter the read-only allowlist and map through toCodeGraphToolName() to codegraph_impact. MemoryKnowledge/src/routes/code-graph.ts must register the direct query route from the same tool list and validate fields such as symbol and depth. Execution then passes through MemoryKnowledge/src/engines/code/bridge.ts to the CodeGraph engine.

If the mapping is omitted, the agent may discover the tool but receive a 403 unknown tool error when calling it. If a separate interface bypasses the shared route, it may omit x-tdai-service-id isolation, parameter allowlisting, or ready-state handling. A locally correct change can still leave the system incomplete.

A fresh session must reconstruct these relationships. Finding CODE_GRAPH_TOOLS by filename does not immediately reveal all the team's existing constraints:

Agents may call query tools; management operations such as create, delete, and sync must not enter the tool allowlist.
External short names such as impact map consistently to internal names such as codegraph_impact.
service_id comes from the x-tdai-service-id request header. Resource-ID queries still require tenant constraints, and cross-tenant access returns 404.
Queries return safe empty results until CodeGraph reaches ready status, rather than using an incomplete index.
Tool definitions, direct routes, unified tool routes, and the MCP surface must remain consistent.

These facts are distributed across interface designs, READMEs, historical sessions about multitenancy, code comments, type constraints, and earlier tool extensions such as search, explore, and callers. A task-specific Memory Pack brings them together:

Chat Memory: the decision to separate external short names from the internal codegraph_ prefix and keep one source of truth for registration. This helps prevent updating the description but forgetting the execution mapping.
Wiki: the progressive-disclosure protocol and the boundary between agent-accessible queries and management operations. This helps prevent accidental exposure of sync or delete.
CodeGraph: the createToolsRoutes → executeCodeGraphTool → toCodeGraphToolName → executeTool path, plus the direct route's dependency on shared constants. This helps prevent missing a route or bridge outside the current file.
Skill: a checklist covering schema, allowlist, mapping, tenant isolation, state branches, type checks, and regression cases. This helps prevent happy-path-only validation.

Before editing code, the agent should then produce a repository-level plan:

Add impact(symbol, depth) to the definitions in routes/tools.ts and confirm its read-only allowlist entry.
Reuse CODEGRAPH_QUERY_TOOL_NAMES so the unified entry point and routes/code-graph.ts register the same set.
Check that toCodeGraphToolName("impact") produces codegraph_impact and reaches the engine through bridge.ts.
Preserve x-tdai-service-id and resource-ownership checks; code_graph_id alone must not permit cross-tenant reads.
Test required symbol, depth bounds, unknown-tool 403, cross-tenant 404, safe non-ready behavior, and normal results.
If Panel, SDK, or MCP exposes the capability directly, update types and documentation according to the same contract.

The intended change in the development experience is concrete. At task start, the agent recovers the shared protocol and historical decisions instead of searching thousands of lines for an entry point. During impact analysis, it sees registration, routing, mapping, isolation, and testing instead of “add one item to an array.” Implementation follows shared constants and constraints. Review covers invalid input, index state, and tenant boundaries as well as the happy path. Finally, the implementation path and validation checklist become a reusable Skill for future extensions.

Memory does not replace debugging when a new engine bug has no relevant history. If a historical rule is obsolete, versions, provenance, and test results must support downranking or withdrawing it.

3. What we learned from 2,600 sessions

3.1 Separate related information from reusable experience

Our Task-only analysis asked a specific question:

Before a bottleneck occurred, did earlier tasks already contain actionable experience that could have prevented or reduced it?

We split 2,600 original sessions into 5,081 tasks. A long session often contains several goals, so session-level similarity can confuse “same repository” or “same user” with a useful problem relationship.

Candidate relationships combined semantic vectors; overlapping files, directories, and symbols; errors and traps; action sequences and artifacts; time; and strong anchors. The first pass produced 48,114 candidate pairs. Filtering retained 23,134 for a stricter second review, independent reclassification, and checks against original-turn evidence.

A relationship broadens retrieval; it does not prove that experience is useful. A high-confidence conclusion must point back to the original text and use only information available before the bottleneck.

3.2 What the 38% result actually means

In an early stratified sample, only 38% of same_problem labels were correct as that exact relationship type, although 95% of those pairs had some concrete relationship. For reusable_sop, exact-type correctness was 62%, while 96% had a concrete relationship.

This does not mean that 38% of knowledge is reusable. It means models can find related tasks more easily than they can distinguish the same work item, the same problem, and a transferable procedure. A relationship is not the same as reuse, and reuse does not imply that something can be executed directly.

After stricter review, independent classification, and machine-verifiable anchors, we retained 22,361 canonical relations. Only 42 same_work_item, 135 same_problem, and 54 reusable_sop relations remained strong. The other 22,130 became related_context “Shadow” relations used only for retrieval.

Sampled precision for the three strong types was 95.24%, 69.00%, and 83.33%, respectively. The same_problem sample fell one example short of the predefined 70% threshold. We retained that as a known risk instead of adjusting the definition until it passed.

The resulting funnel was:

2,600 original sessions: a session is not necessarily one task.
5,081 tasks: organize memory around goals and evidence.
48,114 initial candidate relations: broad retrieval finds clues but includes substantial noise.
22,361 canonical relations: verify time and source evidence.
231 strong relations: high-confidence assets should be selective and reliable.
22,130 Shadow relations: background can aid discovery without directly driving execution.

This changed our asset strategy. “Keep” and “delete” are insufficient states. The system needs strong assets, weak hints, and background references, with promotion, downranking, and withdrawal as evidence changes.

3.3 Which losses should memory address first?

We identified 2,203 bottlenecks. At least one appeared in 1,644 of 5,081 tasks, or 32.36%, and in 1,264 of 2,600 sessions, or 48.62%.

Logical rework: 1,350. Reversing or redoing a design, implementation, or interpretation.
Missing context: 269. Needing repository, business, or historical background.
Intent mismatch: 230. Moving away from the goal or acceptance criteria.
Repeated failure: 145. Retrying an already unsuccessful path.
Lost state: 74. Failing to resume after a session, person, or agent change.
Quality iteration: 65. Requiring several revisions to reach the expected quality.
Task decomposition: 50. Failing to turn a goal into executable steps.
Missing external knowledge: 20. Needing facts or rules outside the current context.

An independent-prompt audit of positive samples achieved 84% precision, 84% accuracy in locating the target turn, and 82% accuracy in locating the causal turn. The zero-window miss rate was approximately 6.5%. Both the production analysis and the audit were model-based, not human gold-standard annotation. These are quality indicators for an internal automated analysis, not general industry findings.

The useful signal is that 1,350 logical-rework cases far outnumbered the 269 missing-context cases. Team memory cannot stop at document retrieval. It must preserve reasoning, failed approaches, applicability conditions, and validation methods; otherwise an agent can find relevant material and still repeat the same reasoning error.

4. Developer interviews and real Redis cases

4.1 Design and review can cost more than code generation

We interviewed seven developers using AI coding tools across complex system design, maintenance, automated testing, large features, and incident handling. The account here omits identifying details about people, projects, and incidents and focuses on shared patterns.

First, design and code review often take more time than writing code. Review requires recovering requirements, understanding tradeoffs, checking impact, and identifying violations of historical constraints. A final diff explains what changed but not all the reasons behind it. This is why a task's Memory Pack combines specifications, Chat Memory, and CodeGraph.

Second, fewer people may collaborate continuously on the same small task. One person often owns a component or coordinates multiple agents, with synchronization concentrated at design review, interface agreements, and merging. Fewer live handoffs shift context-recovery work into review and maintenance. Team memory should allow cohesive work to merge safely when needed, rather than demand constant synchronization.

Third, restoring state across sessions remains a consistent pain point. In established codebases, the missing information is often “why”: why a compatibility branch exists, which incident produced a condition, or whether an apparently redundant check is still necessary. Code graphs and current documentation do not necessarily contain these answers.

Fourth, freshness, provenance, version, and visibility into retrieval determine trust. Developers want to know why a memory was used, which task it came from, whether it applies to the current branch, and how to correct it. Silent injection of plausible text makes it difficult to distinguish model judgment from established team knowledge.

Fifth, memory and deterministic tools have different roles. Memory supplies risks, context, and historical methods before a task. Scripts, tests, and checklists validate results afterward. Neither replaces the other.

The interviews also changed our product sequence: demonstrate immediate personal and project value before relying on future team benefits. Contributions are harder to sustain if they help only an unknown colleague encountering a similar problem later. Restoring the contributor's own state, reducing review explanation, or improving a specification creates an immediate reason to contribute.

4.2 Use real Redis tasks to refine asset selection

Public benchmarks help control variables, but do not capture every project boundary, issue-tracker convention, path difference, and time constraint. Alongside the 5,081 historical tasks and 22,361 relations, we selected 35 real Redis TAPD test tasks to build a historical-task retrieval and asset-selection environment.

This was not another completion-rate benchmark. It asked whether we could find earlier tasks that were valid in time, relevant to the project, and backed by traceable evidence, then distinguish executable experience from weaker hints and background.

The process included broad judgment of candidates, strict second review, verbatim source verification, audits of stratified negatives and out-of-scope candidates, recovery of suspected misses, and deterministic anchoring with unique TAPD IDs.

The results were:

35 target test tasks.
12,574 primary candidate pairs.
57 final related pairs.
18 target tasks with at least one final relation.
54 historical tasks across 45 historical sessions.
32 strong relations, 10 weak relations, and 15 background references.
0 non-Redis candidates and 0 time-invalid candidates in the final set.

The environment helped refine engineering boundaries rather than simply maximize retrieval volume:

Scope must be precise. The same repository does not imply the same branch, path, configuration, or environment. Issue identity, version, and time belong in scope.
Strong and background relations have different uses. Strong assets can inform plans and Skills; weak relations should carry caution; Shadow relations aid discovery without automatically driving execution.
Future information must not leak backward. A later fix cannot become “historical experience” for an earlier target task.
Every conclusion must return to its source. Cluster labels and model summaries are indexes; original turns, issues, code, and validation results remain the evidence.
Negative examples matter. Similar-looking but inapplicable cases help define when an asset should not trigger.

Enterprise memory is difficult because applicability must be established carefully. Semantic similarity is an entry point. Project boundaries, chronology, evidence, and validation determine whether an experience can be acted on.

5. Evaluation: learn from earlier cases, test on later ones

The number of memories stored or Skills generated does not establish value. The relevant question is whether an agent can learn from completed tasks and perform better on subsequent related work.

5.1 Experience inheritance on SWE-bench tasks

SWE-bench Original contains 2,294 real GitHub issue/PR tasks from 12 popular Python repositories. SWE-bench Verified contains 500 tasks that software engineers confirmed to be solvable.

Our evaluation modeled the gradual accumulation of team experience rather than supplying a collection of manually written answers. Three constraints mattered:

Transfer experience only between tasks in the same repository or with a genuine relationship.
Respect chronological order: a later case cannot receive its own answer or information from future cases.
Use task tests to determine success rather than asking the model whether memory helped.

In this related-case evaluation, team memory increased task completion from 60% to 80%: an absolute gain of 20 percentage points, or about 33.3% relative improvement. This is the combined result of the four asset types, not an isolated score for each asset type.

5.2 Exceptionally long and difficult tasks

We selected 50 of the most difficult SWE-bench cases and combined them into a continuous sequence of long problems within one session. The purpose was to examine experience inheritance, information retrieval, and goal consistency during exceptionally long work.

The reported success rate without team memory was 17%, at a cost of $887.64. With team memory, the reported success rate rose to 20%, while cost fell to $717.78. Total tool-call turns also declined by nearly 19%.

5.3 What these results do—and do not—establish

The results support a specific finding: assets formed from earlier tasks can help agents complete later, related software-engineering tasks. This is consistent with the direction of research such as Agent Workflow Memory: historical trajectories can contain reusable workflows, not merely logs.

They do not mean that deploying memory improves every development task by 20 percentage points. Results depend on case selection, the baseline agent, model version, asset extraction, retrieval settings, repetition count, and statistical interval. Before broadening the claim, we need a fixed evaluation subset, reported sample sizes and confidence intervals, separate measurements of helpful, neutral, and harmful transfer, and more testing across repositories, versions, and longer time spans.

SWE-bench and the Redis environment play different roles. Executable tests measure final task completion. Real project cases refine applicability, evidence chains, and confidence levels. One asks whether memory helps; the other asks how to avoid using it incorrectly in a real team.

6. Team memory is also a governance system

6.1 Six design principles

1. Preserve state that others can inherit. Personal memory supports continuity; team memory supports inheritance. After a change of person, session, or agent, goals, constraints, decisions, and unfinished state should remain available.

2. Judge assets by the uncertainty they remove from the next task. An asset earns promotion by reducing wrong turns, restoring necessary background, clarifying code impact, or enabling deterministic validation. Memory count is not a success metric.

3. Preserve both abstraction and evidence. Upper layers offer usable conclusions, rules, and procedures. Lower layers retain tasks, original turns, issues, commits, tests, and versions. Abstraction without evidence is difficult to trust; evidence without abstraction requires rereading all the history.

4. Make assets composable and assemble them per task. A task receives Chat Memory, Wiki, CodeGraph, and Skills relevant to its goal, role, project, and permissions. Atomicity means a clear trigger, one responsibility, and independent validation—not endlessly splitting knowledge into smaller fragments.

5. Give memory a lifecycle. Assets need creation, review, publication, forks, merges, downranking, pinning, expiration, and deletion. Human negative feedback must affect future routing instead of relying on the model to make a better judgment next time.

6. Decouple memory from models and agent frameworks. Models and workflows change quickly. Organizational experience should survive account, session, and framework migrations.

6.2 Six engineering challenges in shared memory

Conflict: similar assets may prescribe different actions for different branches, paths, or environments. Scope filtering, version priority, conflict detection, and, when needed, human review must resolve the difference.

Freshness: an interface upgrade, configuration migration, or business-rule change can invalidate a once-correct conclusion. Assets need valid_from, valid_to, last-validation time, and code-version information.

Permissions: sharing does not mean visibility to everyone. Identity and ACL filtering must precede relevance retrieval, following least-privilege principles and the basic requirements of zero-trust architecture.

Provenance: users should be able to inspect which asset an agent used, where it came from, and which planning step it influenced. Evidence chains support review, audit, and correction.

Negative feedback: incorrect, outdated, or mistakenly retrieved assets need flags, downranking, and withdrawal, with feedback informing the trigger conditions of related assets.

Cost: more context is not automatically better. Retrieval and assembly must balance usefulness, tokens, latency, and exposure of private information.

Team memory therefore needs more than retrieval. Like a code repository, it needs versions, branches, permissions, review, merging, and rollback. Without governance, increasing information bandwidth can also accelerate the spread of incorrect information.

Conclusion: make experience available before the next mistake

The OPC shows what can happen when goals, responsibility, and context are concentrated: one person and multiple agents can execute efficiently. Enterprises cannot eliminate information boundaries, and complete transparency of every trajectory is not the goal. They need effective context to move across people, sessions, agents, and projects under permission, version, and evidence constraints.

When that bandwidth is low, a mistake becomes a temporary fix in one task. Incident background stays in chat, an incorrect assumption remains in someone's head, and the root cause appears only indirectly in a diff. The next person and agent cannot access the experience before execution, so the organization repeats investigation, trial, and rework.

Team memory makes the background, failed path, root cause, fix, applicable version, permissions, and validation method inheritable. It delivers the appropriate parts to the appropriate person or agent when a similar task begins. The gain is in the reach, clarity, and usability of experience—not message volume.

Our work follows this chain: internal task analysis shows that related context is much more common than reliably reusable experience; interviews place design, review, and state recovery at the center; real Redis cases demand finer scope, chronology, and confidence levels; and the scoped SWE-bench result of 60% → 80% provides initial evidence that earlier experience can affect later outcomes.

“Make each mistake only once” is an aspiration, not an absolute promise about organizational behavior. When effective context can flow safely and accurately, each task can contribute something the next task inherits.

This work is still exploratory. Asset boundaries, conflict handling, updates, and assembly across agents need real tasks to expose their limitations. Internal data and benchmarks provide a starting point. The practical test is whether the system reduces repeated explanation, lost state, repeated trial and error, and gaps in inherited experience.

If your team struggles to resume work across sessions, trace historical decisions, avoid repeating investigations, recover design-review context, or govern knowledge across people and agents, we welcome real use cases, issues, and contributions.

Try the project, open an issue, or contribute a pull request: TencentDB Agent Memory on GitHub.