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:

1. Compounding intelligence. Frequently-used context strengthens; rarely-used context fades. The corpus self-curates without manual upkeep.
2. 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.
3. 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.