# The Living Context Engine, Defined: Three Properties That Separate It From RAG > A Living Context Engine is not a faster RAG pipeline. It is a different category — defined by intelligent decay, relational structure, and a closed feedback loop. This is the precise definition, with the architectural properties that follow. - **Category**: Theory - **Read time**: 12 min read - **Date**: May 14, 2026 - **Author**: Feather DB Engineering (Engineering Team) - **URL**: https://getfeather.store/theory/living-context-engine-defined --- # The Living Context Engine, Defined: Three Properties That Separate It From RAG *Theory · Living Context Engine Series · May 2026* --- ## The Category Problem "Living context engine" is becoming a buzzword. Every vector DB, every RAG framework, every memory plugin is starting to claim the label. Most of them are using it wrong. The term refers to a specific architectural category — not a marketing layer over a static retrieval pipeline. A Living Context Engine is a memory layer with three properties. If a system has all three, it is one. If it has two of them, it is something less. The properties are observable in the architecture, not the documentation. ## Property 1: Intelligent Decay A Living Context Engine ranks context by a composite score that includes recency and recall frequency, not similarity alone. Concretely: - Every node carries decay state (insertion time, recall count, importance). - Retrieval applies a scoring function that blends similarity with a recency curve modulated by recall frequency. - Stale, never-recalled context naturally falls in rank; frequently-recalled context stays present. The architectural test: *does the same query at month 0 and month 12 return different results, even if the corpus has not changed?* If yes, the system has intelligent decay. If no, it is a static index pretending to be a living one. ## Property 2: Relational Structure A Living Context Engine stores typed relationships between context nodes and uses those relationships at retrieval time. Concretely: - Edges are first-class — they have types and payloads, not just IDs. - Retrieval can combine ANN search with bounded graph traversal in a single call. - The output is a connected subgraph of context, not an unordered list of chunks. The architectural test: *can a single retrieval return both a similar item and the items connected to it, with the relationship types preserved?* If yes, the system has relational structure. If no, it is a vector store with metadata. ## Property 3: Closed Feedback Loop A Living Context Engine has a write path back from agent output to context. Concretely: - Agent decisions, completions, and outcomes are written back as new context nodes with edges to the inputs that produced them. - The next query benefits from the previous query's output — recall counts increase, new edges appear, importance shifts. - The system gets *more* contextually-grounded over time, not less. The architectural test: *does the system's quality on a fixed evaluation set improve as production usage accumulates?* If yes, the loop is closed. If no, the system is a forward-only retrieval pipeline. ## What the Three Properties Together Buy You Each property is useful on its own. Combined, they produce qualitative behavior that no static system can match: - **Compounding intelligence.** Frequently-used context strengthens; rarely-used context fades. The corpus self-curates without manual upkeep. - **Topology-aware retrieval.** Queries return shapes of relevance, not lists. An agent sees the brief, the executions derived from it, and the post-mortems that responded — in one call. - **Outcome-conditioned reasoning.** When the agent's prior outputs are written back as context, future decisions can see what was tried and what worked. The system carries institutional memory, not just retrieval. ## What It Is Not Three things often mislabeled as Living Context Engines: - **Static RAG with metadata filters.** Adds categorical pruning. Misses decay, structure, and feedback. - **Vector DB plus graph DB joined at the application layer.** Has structure, but the join is awkward, decay is absent, and the loop is rarely wired. - **Agent memory plugins that store conversation history.** Often have a primitive feedback loop, but no decay model and no relational structure. A Living Context Engine is the union of all three properties in a single store. Half-measures produce systems that look like they should work and don't. ## Why the Definition Matters If you build a system that has only similarity-based retrieval, you will hit a quality ceiling around month three. If you add intelligent decay, you push the ceiling out by a factor of three or four. If you add relational structure, you change the *shape* of retrieval results in ways that improve downstream reasoning. If you close the loop, the ceiling stops being a ceiling. Feather DB is engineered around all three properties, by design, in a single embedded engine. Subsequent posts in this series walk through each property at the implementation level. --- *Part of the Living Context Engine series. Next: [Decay, Recall, Stickiness](/theory/decay-recall-stickiness).* --- *This is the machine-readable mirror of the theory post at [getfeather.store/theory/living-context-engine-defined](https://getfeather.store/theory/living-context-engine-defined). For the full Feather DB documentation, see [getfeather.store/llms-full.txt](https://getfeather.store/llms-full.txt).*