How the System Retrieves Less but the Right Things
For TencentDB Agent Memory, retrieval is the point where accumulated experience either becomes useful help or becomes noise. The specific problem is how to choose among exact conversation history, structured memories, scene-level context, and callable knowledge without flooding the next prompt. Understanding that choice lets the reader decide not only which search method fits a question, but also which information should be injected immediately and which should remain behind a tool boundary.
A memory system has two ways to fail. It can fail to find something that matters, or it can find too much and make the model less reliable. The repository addresses both by combining different ranking signals, filtering by identity, and treating prompt space as a limited budget. Search is not the last step. The result still has to be placed in a context where the Agent can distinguish a stable orientation from a current-turn hint and from material it should actively verify.
Search is a combination of signals, not a truth detector
Imagine a user asks, “How did we handle the login timeout last time?” The exact phrase may never have appeared in the stored memory. The earlier conversation may have said “the authentication endpoint was taking too long,” while the structured L1 record may describe a decision to keep the old module and add a regression test. A keyword search can recover “login” and “timeout.” A vector search can recognize that “authentication latency” is related even when the wording differs. Neither signal alone is enough for every question.
TencentDB Agent Memory therefore exposes keyword, embedding, and hybrid retrieval strategies. Keyword retrieval uses full-text search and BM25-style ranking. Its strength is lexical precision: names, identifiers, unusual terms, and exact phrases survive paraphrase poorly but are easy for a keyword index to recognize. Embedding retrieval represents text as vectors and compares semantic proximity. Its strength is that a query can find related wording rather than only matching the same words. The repository treats these as capabilities of a store, not assumptions that every backend must satisfy.
When both paths are available, the system runs them in parallel. It then combines their ranked lists with Reciprocal Rank Fusion, or RRF. The idea is simple: a record that appears near the top of both lists receives support from both signals, while a record that appears in only one list can still remain eligible. The implementation uses rank contributions rather than trying to compare a BM25 score and a cosine-similarity score as though they were measured on the same scale.
That distinction is important. RRF combines evidence about retrieval position, not evidence about truth. If a stale memory uses the same terms as the user’s query, keyword search may rank it highly. If an incorrect derived sentence is semantically close to the query, vector search may rank it highly. Fusion can make the ranking more robust to one weak signal; it cannot validate the underlying claim. The Agent still needs the raw conversation or a trusted reference when the exact decision matters.
Some stores provide a native hybrid search that combines dense and sparse signals in one backend call. When that capability exists, the shared recall helper uses it before requesting a client-side embedding. This avoids doing redundant work and allows a service-side vector database to own the combination. When native hybrid is not available, the two local legs run independently. If the embedding provider is missing or fails, the FTS leg can still return results. If FTS is unavailable but embeddings work, the vector leg remains usable. If neither capability exists, the system returns an empty result with an explanatory status rather than pretending that an unranked scan is equivalent to recall.
The fallback behavior protects the request path, but it changes what the user should expect. A keyword-only deployment may be good at exact project names and terms while missing paraphrases. A vector-only deployment may find conceptual neighbors while being less precise about identifiers. A search response that succeeds is therefore not enough to infer that the preferred strategy ran. The effective strategy is part of the result and should be visible to diagnostics and operations.
Identity filtering is applied alongside ranking, not after the Agent has already received a broad candidate set. L0 and L1 records carry session, team, user, Agent, and optional task dimensions. Store methods accept isolation filters, and the SQLite implementation rechecks the returned metadata against those filters. This matters both for privacy and for relevance. A technically similar memory from another Agent can be the wrong answer even if it scores better than a weaker but authorized record. The retrieval problem is not “which text is nearest?” but “which authorized text is nearest within the current context?”
The same logic applies to conflict detection during L1 extraction. There, candidate recall is scoped to the relevant session or isolation filter before an LLM decides whether a new candidate should be stored, updated, merged, or skipped. Search used for user recall can span the records relevant to a broader Agent context, but deduplication must not silently compare unrelated tenants. The shared retrieval helper makes the ranking mechanism reusable while leaving the isolation decision with its caller.
L0 and L1 also answer different questions. L0 search returns individual conversation messages with their roles, session identifiers, timestamps, and recorded text. It is the right surface when the user asks for exact wording, a timeline, or the context surrounding a decision. L1 search returns structured records with types, priorities, scenes, versions, and update information. It is more economical when the question concerns a preference, an event, a rule, or a distilled work fact. A good retrieval policy does not use L1 as a substitute for L0 when the distinction between what was said and what was inferred matters.
The practical rule is to search at the level of the question. “What did I say?” points toward L0. “What do we know about this constraint?” points toward L1. “Which part of the project does this belong to?” may begin with the L2 scene index. “What does the design document say?” belongs to Wiki, while “which function calls this?” belongs to CodeGraph. The ranking mechanism helps locate candidates; the asset type tells the Agent how to interpret them.
The sequence shows that a search result is a candidate in a larger flow. Fusion comes before context assembly, and authorization is not a decorative label added after injection. The final response may rely on material that was already injected, or the Agent may use a tool to obtain detail that was deliberately not placed in the initial prompt.
Prompt space is divided by volatility and cost
Once candidates have been found, TencentDB Agent Memory does not inject every scene and every record. It divides context into stable and dynamic channels. L3 persona or team-level operating memory changes relatively infrequently, so it can be appended to the system prompt as a stable orientation. L2 is represented primarily by scene navigation: paths and summaries tell the Agent what scenes exist without paying to include every scene body. L1 matches are dynamic because they depend on the current user query, so they are placed near the current user turn rather than mixed into the stable system prefix.
This arrangement solves two problems at once. First, it protects the prompt budget. A dozen full scene documents can consume space before the Agent has understood the current request. A list of paths and summaries offers a map; the Agent can read one scene when its details become relevant. Second, it protects prompt-cache locality. Provider-side prompt caching works best when a large prefix remains unchanged. If the current query changes only the L1 matches, the system can keep the persona, scene index, and tool instructions in the stable region instead of invalidating the whole prefix on every turn.
The distinction is not merely about where strings are concatenated. It changes the Agent’s behavior. Stable context answers, “What background should I carry into this session?” Dynamic context answers, “Which stored facts look relevant to this question?” A tool answers, “What deeper evidence should I fetch because the current material is not enough?” Collapsing these channels would make a transient search hit look like a permanent rule, or force the model to process detail it may never use.
The Proxy’s profile injector applies the same strategy in a team setting. It can include the current Agent’s L3 content and a bounded list of L2 scenes, while grouping memories from the current Agent and limited imported Agent contexts separately. L1 recall is merged by relevance and labeled by origin. That label helps preserve provenance at the point of use: a fact from an imported Agent’s memory is not silently presented as though it came from the current Agent’s own history.
The deeper material remains callable. The memory tools guide distinguishes structured L1 search from raw L0 conversation search and from reading an identified scene. The knowledge tools guide uses a two-step pattern: the Agent discovers the available tools for a Wiki or CodeGraph resource, then calls the selected read-only operation. The system exposes capability and navigation first, content second. This is especially valuable for code and documents, where the cost of loading an entire repository or design corpus would overwhelm the question being answered.
There is a trade-off in asking the Agent to fetch detail on demand. The model must recognize when the summary is insufficient, formulate a useful query, and follow the tool’s instructions. If it does not, the system may have relevant information but the answer may still be incomplete. Directly injecting everything avoids that dependence at the price of more tokens, more distraction, and less control over what the model treats as immediately salient. TencentDB Agent Memory chooses a mixed strategy rather than claiming that one side is universally better.
Budgets also require truncation and bounded search. The recall path limits the number of L1 results, caps the amount of stable profile material, and gives the Agent a finite number of search attempts in its usage guide. These limits prevent a difficult query from turning into an unbounded retrieval loop. They also make “not found” meaningful enough to act on: after the permitted searches produce no result, the Agent should say that the memory was not located rather than inventing an answer.
A query can still be relevant and not appear in the injected snippets. The score threshold, result cap, scene index, or isolation scope may exclude it, and the embedding may not yet exist because indexing is asynchronous. This is why the injected context includes an explicit path to deeper search. The initial prompt is a bounded starting point, not a claim that the model has seen the complete memory store.
That boundary is also why derived layers must remain distinguishable from evidence. L3 is useful for rapid orientation, but it is the most compressed representation. L2 gives a more coherent narrative, but it is still a generated scene. L1 gives a targeted structured statement, but it is an extracted record. L0 gives the closest available conversation evidence, subject to capture sanitization. Retrieval should move downward when precision, chronology, or verification matters.
A useful operational test is to ask two questions about any recalled item: Why did this item enter the context? and What would I read if it might be wrong? The first question concerns ranking, filters, and budgets. The second concerns the next evidence surface—another L1 query, the original L0 messages, an L2 scene, or an external Wiki/CodeGraph reference. A system that can answer both is more trustworthy than one that merely reports a similarity score.
The design’s central achievement is therefore restraint with an escape hatch. It retrieves a small, scoped set of candidates, puts stable and dynamic material in different places, and leaves deeper evidence accessible through tools. Its central limitation follows from the same design: relevance ranking is not truth, on-demand depth depends on Agent behavior, and a degraded backend can change the effective strategy. The next question is how this carefully assembled context survives the trip through real Agent clients and returns as durable experience after the model answers.