TencentDB Agent Memory Adapts to the JEV Decision Model: Letting Agents Call on Team Experience as Needed

TencentDB Agent Memory Adapts to the JEV Decision Model: Letting Agents Call on Team Experience as Needed

TencentDB Agent Memory introduces a pluggable decision service that abstracts judgments such as "whether to recall, which candidate assets to select, and whether to trigger a memory update" into an independent interface, and provides a JEV integration example.

In a real-world Skill recall test, after integrating JEV, the input tokens that the main model repeatedly injected due to misses dropped from 24.96M to 15.04M, a reduction of nearly 40%; the task success rate remained stable at the same time, and the number of long, difficult SWE-bench Pro problems passed rose from 30% to 40%.

We want to reduce two types of waste in reusing team experience: existing experience is not called upon, so tasks have to be explored repeatedly; and irrelevant experience is brought into the context, increasing invocation overhead. One key link is judging when experience should participate in a task and when memory needs to be updated. This update separates these well-scoped judgments and hands them to the decision service, letting the main model continue to handle task analysis and execution.

1

Using JEV for judgments: recall selection and memory updates

In the Skill recall and memory update stages, JEV only handles well-scoped questions: once it determines that candidate assets need to be used, the system then enters the recall and loading process; once it determines that memory needs to be updated, it then triggers the corresponding generation process. Through this division of labor, the main LLM can devote more attention to task analysis and execution, reducing its consumption on high-frequency, fine-grained judgments such as "should I look this up?"

Specifically, JEV works at two online decision points:

● Recall side — whether to select, and which one to select.

Within the candidate scope permitted by permissions, the candidate numbers and descriptions are handed to JEV, and the selection is completed through a single structured judgment; once it is determined that they need to be used, the corresponding content is then read and loaded.

● Generation side — whether it is worth generating.

After each scenario memory (L2) update, the system needs to judge whether to regenerate the long-term profile and stable rule summary (L3). JEV compares the current L3 with the newly added L2 information and classifies it by priority into conflict, change in applicable boundary, new rule, information reinforcement, and no change: the first three trigger an immediate update, information reinforcement is deferred, and no change skips this L3 generation.

The decision service returns a structured judgment and confidence; when the judgment is abnormal, it can fall back to the original policy according to configuration.

Recall judgments serve the current task, while generation judgments serve memory maintenance. The independent judgment stage is responsible for selection and triggering, and the subsequent processes are responsible for content loading, generation, and task execution. When integrating other models, the effects of these two stages also need to be evaluated separately.

To evaluate the impact of the independent judgment stage on invocation overhead and task results, we ran two sets of tests.

Skill recall — to verify what "JEV replacing the main model in making selections" can bring, we compared main-model judgments and JEV judgments on 72 tasks from the same source:

● The input that the main model repeatedly injected due to misses dropped from 24.96M tokens to 15.04M, a reduction of about 9.9M — nearly ten million fewer tokens of redundant context, which directly corresponds to cost and latency;

● The task success rate was almost flat (66.7% → 65.3%, a difference of 1 problem); on a selected subset of long, difficult SWE-bench Pro problems, the number passed rose from 30% to 40% — indicating that more accurate recall did not sacrifice task quality.

Memory generation — to verify the effect of "JEV judging whether to trigger L3 regeneration," we compared it with a strategy of generating every time under 10 problems × 3 arms × 3 repetitions:

● The total cost of a complete 14-turn user conversation dropped by 13.8% — a direct saving from fewer invocations on the generation side;

● L3 generation invocations dropped by 39.7% — many scenarios that did not actually need regeneration were correctly skipped;

● After integrating JEV, the final semantic synchronization rate was 96.7% (100% being the ideal figure) — fewer invocations did not sacrifice memory synchronization quality, and this is a clear improvement over the current scheme's figure (86.7%);

● The JEV judgment cost accounted for only 0.72% of total cost, the immediate-update recall rate was 93.3%, and the binary classification accuracy was 85.1% — the judgment itself is nearly free, and the miss rate is also very low.

The two sets of tests revolve around the same design idea: separate well-scoped selection and trigger judgments, and let the main model continue to handle task analysis and execution. For team asset management, the value of the fast/slow division of labor lies in this: the fast path manages timing, and the slow path manages content — first judge whether experience needs to be called upon and whether memory needs to be updated, then enter the corresponding loading and generation processes, giving relevant experience a better chance to participate in tasks while reducing unnecessary invocations and context occupation.

However, judging "when to use it" is only one part of experience reuse. For the decision service to make effective choices, the candidate assets themselves also need clear applicable conditions, verification evidence, and sharing boundaries.

2

Making experience a reusable asset

Suppose the team completes a database change: an execution record has been left behind, and the processing steps have been organized into a document. Some time later, another member takes on a similar task with a new Agent. If this experience does not enter the current context, the Agent will still search for materials and sort through the steps again, and the member will also need to explain the background once more.

The team has already invested time in this work, yet the next task still bears part of the repeated cost. Task handoffs, member changes, and multi-Agent collaboration all amplify this repetition.

For experience to be truly reused, it must first be organized into assets that are easy to find and use. TencentDB Agent Memory brings Chat Memory, Skill, Wiki, and CodeGraph under unified Memory Assets management — carrying four types of assets respectively: facts and preferences, operational methods, structured documents, and code relationships.

Among them, Skill is the focus of this update, because operational methods in repetitive tasks are an important part of team experience. Skill organizes applicable conditions, execution steps, verification methods, and required resources together, helping the person taking over judge whether to adopt it.

However, after a Skill is distilled, the team still needs to know what verification it has undergone and the scope within which it can be used. Otherwise, a past successful operation may be directly copied in a different environment. From the perspective of organizational efficiency, the chain of "organize — review — share" is exactly the key step that turns individual experience into team assets.

To clarify the applicable scope of assets and support subsequent review and maintenance, it is recommended to fill in at least five types of information:

Applicable conditions: what environment, version, and task it targets

Steps and variables: which sequences can be reused, which parameters need to be filled in, and how to verify results

This information helps the team judge whether the experience applies, provides clearer candidate descriptions for the decision service, and leaves a basis for subsequent revisions.

3

Experience invocation and asset maintenance form a closed loop

After an Agent uses a Skill to execute a task, it leaves new execution records and results. This feedback can be used to revise existing assets, connecting one task with the next.

● Task execution (letting experience participate in action): judge whether recall is needed based on the goal and current work state, filter materials and methods within the permitted scope, and then assemble context combining rules, tool results, and other information. Execution results update the work state, and the task continues.

● Experience accumulation and maintenance (letting tasks leave reusable assets): organize candidate content from execution records, result feedback, documents, and human experience, retaining applicable conditions and evidence; merge, handle conflicts, maintain versions, and verify changes as needed.

Result feedback provides the basis for continued improvement: task feedback is organized into reflection text for the next round, and Agent behavior is adjusted by updating external memory without modifying model weights. For a team memory system, the more concrete current work is to retain results, revise assets, and verify changes through representative tasks.

The judgment strategy itself can also continue to iterate. In the future, teams can adjust judgment prompts and rules based on execution feedback, testing which scenarios should be recalled and which updates can be deferred. Experience assets and the mechanisms for invoking and maintaining them can all be incorporated into continuous evaluation and revision.

This kind of iteration needs to be based on traceable execution feedback and continuously maintained experience assets. In TencentDB Agent Memory, experience assets are managed uniformly in the form of Memory Assets: teams review content and maintain versions through Memory Hub, and share and bind revised memories and Skills to relevant Agents, turning execution feedback into experience usable for subsequent tasks and providing a basis for adjusting judgment strategies.

4

Build together

The change we are watching is Memory moving beyond preserving history toward connecting experience accumulation, context assembly, and capability improvement. The memory layer provides persistent information and method assets; recall and context scheduling mechanisms determine when they participate in tasks; and evaluation then tests whether this experience has brought improvement.

Previously, building Agent memory followed a straightforward idea: extract chat records into facts, write them into a vector database, and retrieve them by similarity when needed — memory was about storing history and looking up history. But now it is different: starting from the execution process, experience, memories, and Skills are distilled, then organized, de-conflicted, and version-managed, the content to be used is routed out by task, assembled into context and handed to the Agent for execution, and finally the results are fed back for continued updating.

The most critical change in this chain is that Memory has gone from "digging through history" to an intermediate layer between Agent capability evolution and context scheduling. Experience accumulated by one person can truly be reused by the next person and the next Agent, rather than explaining everything from scratch whenever someone changes.

—— People define goals and boundaries and decide which experience is worth promoting; the memory layer is responsible for making that experience appear precisely when needed.

You are welcome to share your experience using Skill recall in the project, provide real task cases, and tell us which decision models you would like to integrate.

The integration of decision models has already been abstracted. Developers who wish to use other decision models can implement adaptation themselves based on this interface layer; teams can choose models based on task characteristics, deployment environment, and evaluation results.