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 按需调用团队经验
Top comments (0)