The Infrastructure Stack of the Context Era

What the Context Era stack looks like

The LLM Era stack was simple: embedding model → vector store → LLM. Embed the query, retrieve similar chunks, pass to the LLM, return response. Each component was a separate service. The simplicity was a feature — it was fast to build and easy to reason about.

The Context Era stack is more layered. The retrieval step is no longer a flat nearest-neighbor lookup — it is a decay-adjusted, graph-traversal-augmented, stickiness-weighted operation that requires integration between components that were previously separate. Building this stack from individual services (a vector DB, a graph database, a decay scheduling system, a metadata store) requires coordination complexity that did not exist in LLM Era architectures.

Feather DB collapses the Context Era stack into a single embedded package. Understanding the full stack clarifies why integration matters and what each layer contributes.

The full Context Era stack

+--------------------------------------------------+
|              APPLICATION LAYER                   |
|   (agents, copilots, marketing AI, assistants)   |
+--------------------------------------------------+
                        |
+--------------------------------------------------+
|                  LLM LAYER                       |
|   (GPT-4o, Gemini-2.5-Flash, Claude — any)      |
+--------------------------------------------------+
                        |
+==================================================+
|              CONTEXT ENGINE LAYER                |
|                  (Feather DB)                    |
|  +---------+  +--------+  +--------+  +-------+ |
|  | Adaptive|  | Context|  |Semantic|  |Metadata| |
|  | Memory  |  | Graph  |  | Search |  | Intel  | |
|  | (decay, |  |(edges, |  |(HNSW + |  |(attrs, | |
|  |stickiness| | BFS)   |  |  SIMD) |  |  ns)   | |
|  +---------+  +--------+  +--------+  +-------+ |
+==================================================+
                        |
+--------------------------------------------------+
|              EMBEDDING LAYER                     |
|   (text-embedding-3-small, nomic, MiniLM, etc.)  |
+--------------------------------------------------+
                        |
+--------------------------------------------------+
|               DATA SOURCES                       |
|   (sessions, campaigns, documents, events)       |
+--------------------------------------------------+

Layer 1: The embedding layer

The embedding layer converts raw data (text, structured records, interaction logs) into fixed-dimension vectors. Feather DB is dimension-agnostic — dim= at initialization accepts any dimension from 32 to 3072+. The choice of embedding model affects retrieval quality but not Feather DB's performance characteristics.

For most applications: text-embedding-3-small (1536 dims, OpenAI) or all-MiniLM-L6-v2 (384 dims, local, MIT) provide strong semantic retrieval. For cost-sensitive deployments, nomic-embed-text (768 dims, free, Apache 2.0) is a viable alternative. The embedding model determines semantic retrieval quality; the context engine layers above determine how that retrieval is weighted and augmented.

Layer 2: Semantic search (HNSW + SIMD)

Feather DB's semantic search layer uses Hierarchical Navigable Small World (HNSW) graphs for approximate nearest neighbor (ANN) search. HNSW provides logarithmic search complexity with tunable precision via the ef_search parameter.

Performance at 500K vectors: 0.19ms p50 ANN latency, 97.2% recall@10. AVX2/AVX512 SIMD acceleration is applied automatically based on the host CPU's instruction set. Cosine similarity is the default distance metric.

The v0.16 update added persisted HNSW — the graph is saved to disk and loaded on startup, providing 5–6× faster cold load compared to rebuilding the index from scratch. For production agents that restart (service deployments, container orchestration), this means full retrieval quality is available immediately after restart.

Layer 3: Adaptive memory (decay + stickiness)

The adaptive memory layer is what separates a context engine from a vector database. It applies two mechanisms that transform static nearest-neighbor retrieval into time-aware memory retrieval:

Half-life decay. Each retrieved memory has an effective age calculated as age_in_days / stickiness_factor. The recency score is 0.5 ^ (effective_age / half_life). At half_life=30, a memory not recalled in 30 days scores 50% of its initial recency. At 90 days without recall, it scores 12.5%.

Recall stickiness. Each time a memory is returned in a retrieval result, its recall_count is incremented. Stickiness is calculated as 1 + log(1 + recall_count). A memory recalled 10 times has stickiness 3.4, meaning it ages at 29% of the normal rate — it effectively stays fresh much longer.

The combined scoring formula:

def score_memory(similarity, importance, age_days, recall_count,
                 half_life=30, time_weight=0.3):
    stickiness = 1 + math.log(1 + recall_count)
    effective_age = age_days / stickiness
    recency = 0.5 ** (effective_age / half_life)
    return ((1 - time_weight) * similarity
            + time_weight * recency) * importance

Layer 4: Context graph (edges + BFS)

The context graph layer stores typed weighted edges between memories. Nine predefined relationship types: supports, contradicts, supersedes, caused, resolved, same_session, references, derived_from, related. Custom types are also supported.

BFS traversal from retrieved seed nodes expands the context window to include connected memories that may not be semantically similar to the query but are causally related. A query about a user's billing issue retrieves the billing complaint memory (semantic match), then traverses to the resolution attempt (caused edge), and the communication preference (same_session edge) — providing causal context that flat retrieval cannot surface.

Layer 5: Metadata intelligence (attributes + namespaces)

The metadata layer stores arbitrary key-value attributes per memory and enables server-side metadata filtering during retrieval. Namespace isolation is implemented through metadata filtering: filters={"user_id": user_id} or filters={"brand": brand} ensure retrieval is scoped to the correct entity.

Metadata filtering is applied before HNSW search, not post-hoc — which means filter selectivity directly improves retrieval precision without affecting recall on the target namespace.

Full stack comparison

Why integration matters

The decay and graph layers are not independently useful — they derive their value from being integrated with the retrieval layer. A decay scheduler that runs separately from the vector store must update scores in a separate system and then re-rank results post-retrieval, adding latency and synchronization complexity. A graph database that is separate from the vector store requires a second query after vector retrieval, adding a network round-trip.

Feather DB integrates all five layers so that a single db.search() call applies decay, stickiness, and metadata filtering to the HNSW retrieval simultaneously. The db.context_chain() call extends this with graph BFS in the same embedded process. No network hops, no synchronization complexity, no separate services to maintain.

The result is 0.19ms p50 retrieval end-to-end — including decay scoring, metadata filtering, and HNSW approximate nearest neighbor search — at 97.2% recall@10 on 500K vectors. This is fast enough to be a synchronous agent primitive, not a database call that adds perceptible latency.

Frequently Asked Questions

What is HNSW and why does Feather DB use it?

HNSW (Hierarchical Navigable Small World) is a graph-based algorithm for approximate nearest neighbor search. It provides logarithmic search complexity with high recall — 97.2% recall@10 at 0.19ms p50 on 500K vectors in Feather DB's implementation. Compared to flat exhaustive search, HNSW is orders of magnitude faster at the scale where agent memory stores operate. The persisted HNSW in v0.16 eliminates cold-load rebuild time, providing 5–6× faster startup.

What is the difference between recall stickiness and importance weighting?

Importance is set at storage time and represents the a priori reliability or value of a memory. Stickiness is earned at retrieval time through repeated successful recalls — it increases with each retrieval, reducing the effective decay rate. The two work together: high-importance memories start with a scoring advantage; high-stickiness memories maintain their scoring advantage over time. A low-importance memory that is repeatedly recalled will eventually have high stickiness; a high-importance memory that is never recalled will still decay.

Can I use Feather DB as a drop-in replacement for an existing vector database?

For basic vector search, yes — Feather DB's HNSW search is compatible with the use patterns of other embedded vector databases. The migration adds access to decay, stickiness, graph edges, and metadata filtering. The one change required is initialization with fdb.DB.open(path, dim=N) and using fdb.Metadata for per-vector attributes. Existing embedding pipelines work unchanged.

How does Feather DB handle multi-tenant memory isolation?

Namespace isolation is implemented through metadata filtering. Each memory is stored with a user or entity identifier as a metadata attribute. Retrieval queries include a filter on that attribute — filters={"user_id": user_id} — ensuring that one user's memories never appear in another's retrieval. The filter is applied before HNSW search, not post-hoc, so isolation has no accuracy cost.

What is the maximum memory store size Feather DB supports?

Feather DB benchmarks show 0.19ms p50 latency at 500K vectors. Performance degrades gracefully beyond that — the HNSW search complexity is logarithmic, so doubling the store size increases search time by less than a factor of two. For most production agent applications, per-user stores of thousands to tens of thousands of memories are typical, well within performance targets. Very large stores (millions of vectors) benefit from namespace filtering, which reduces the effective search space to the relevant namespace.