Reference Knowledge and the Price of Scale

TencentDB Agent Memory has two remaining questions after memory and Skills are in place: where should an Agent look when it needs reference knowledge about documents or code, and what infrastructure is justified when one local process becomes a shared service? This chapter answers both by contrasting Wiki and CodeGraph with conversational assets, then comparing standalone simplicity with service-mode coordination. The goal is a conditional choice, not a universal winner.

The distinction matters because reference knowledge and accumulated experience fail differently. A memory records what a person or team learned in interaction. A Skill captures how to perform a repeatable procedure. A Wiki and a CodeGraph describe an external body of material that may change independently of the conversation. Their retrieval paths should expose enough structure for the Agent to navigate, but not assume that a generated index is the same thing as the current source.

Reference knowledge has a different job

A Wiki begins with documents, not with an Agent’s personal history. MemoryKnowledge can receive source files, ask an LLM to extract structured pages, add frontmatter and source attribution, and organize the pages with links. The current ingestion design separates candidate generation from commitment: source extraction can happen in parallel, while merging candidate pages into the Wiki remains serial. This separation prevents several simultaneous interpretations of one source from writing over one another unpredictably.

The two-stage ingestion path first analyzes a source chunk and then generates structured page blocks from that analysis. A lower-cost single-stage path is also supported. Long sources can be split into bounded chunks. Generated paths are normalized from page type and title when possible, and structural files such as the Wiki index or schema are protected from being overwritten by ordinary content. Source attribution is retained so a page can point back to the file that contributed it.

The resulting Wiki is not merely a directory of Markdown pages. Each Wiki has a search index and a graph built from page links. BM25 search provides lexical seeds. If the question needs related concepts rather than only the first matching page, graph search can walk link edges for a bounded number of hops while decaying the score at each hop. A hard cap on visited nodes keeps a dense graph from turning one query into an uncontrolled traversal. The graph is therefore a controlled expansion of a ranked starting set, not a claim that every connected page is equally relevant.

This design serves questions such as “why was this interface designed this way?” or “what did the operating guidance say about the release process?” Search can identify a page, and a page read can provide the full explanation. The Wiki’s source and page layers remain distinct: the generated structure improves navigation, but the original files are still the material that gave the page its content.

CodeGraph starts from a repository and answers a different class of question. Its index organizes symbols, files, and relationships such as callers, callees, and potential impact paths.