How Much Structure Should Agentic Graph Memory Build for Text Retrieval?

As agentic systems run longer and reason over larger evidence collections, simple context-window memory becomes insufficient. Knowledge-graph (KG) memory is a natural response, but existing KG-for-retrieval systems are difficult to compare because they vary construction assumptions, retrievers, reader models, metrics, and cost accounting. This paper studies KG construction as a \emph{structure-boundary} problem, i.e., how much structure should be materialized before retrieval, and how much reasoning should be deferred to retrieval-time traversal, embeddings, and the reader LLM?

We evaluate this question in a normalized multi-hop retrieval setting across a spectrum of construction choices: heavy event/schema-rich KG construction, lightweight entity-centric construction, prompt / model-optimized extraction, Wikidata-aligned construction, token-free graph construction, and flat compiled-wiki/context baselines. The main result is that both extremes fail in different ways. Heavy construction can spend most of the token budget on abstractions that the downstream retrieval stack does not use, while graph-free or nearly graph-free baselines lose reliable multi-hop evidence composition. In our validated setting, an entity-centric construction with prompt/model optimization improves answer quality over the full high-structure baseline while reducing construction cost by more than an order of magnitude; with a stronger reader, the same lightweight graph supports further gains.

This work's contribution is therefore not a new universal KG algorithm, but an empirical recipe for setting the structure boundary: compare against both low- and high-structure baselines, keep retrieval and reader stacks fixed when testing construction choices, report quality--cost frontiers, and require each added layer of graph structure to improve downstream utility.