Why Every AI Agent Needs a Context Engine (Not Just a Vector Store)

The retrieval-only trap

Most AI agents built today use a vector store for memory. The pattern is well-established: chunk documents, embed chunks, store vectors, retrieve top-k at query time. Simple, effective for RAG over static corpora, and supported by every major vector database.

The problem emerges when agents operate over time. A support agent handles hundreds of conversations. A coding assistant accumulates months of debugging sessions. A research agent builds up findings across hundreds of papers. In these scenarios, a vector store — which treats every stored chunk identically regardless of how often it's been useful — stops being sufficient.

The symptoms: the agent forgets high-value memories while returning stale, low-value ones. Retrieval doesn't get better as the agent learns. Every query is the same as the first one.

What a context engine adds

A context engine is a vector store with three additions:

1. Adaptive decay: memories that haven't been recalled recently become less likely to surface. The agent's working set shifts toward what's been recently relevant.
2. Stickiness: memories that are recalled frequently resist decay. High-value, repeatedly-accessed facts remain accessible even as the store grows.
3. Typed relationships: memories are connected by semantic edges (supports, contradicts, refines, leads_to, same_session). Retrieval can traverse these edges — surfacing not just a memory, but the connected context around it.

These three properties transform retrieval from a static lookup into a feedback loop: use a memory → it becomes stickier → it's more likely to be retrieved again → it accumulates recall weight. Don't use a memory → it decays → it eventually stops surfacing unless explicitly queried.

The Feather DB adaptive scoring formula

stickiness    = 1 + log(1 + recall_count)
effective_age = age_in_days / stickiness
recency       = 0.5 ^ (effective_age / half_life_days)
final_score   = ((1 - time_weight) × similarity
                 + time_weight × recency) × importance

Three parameters to tune:

• half_life: how many days until an unrecalled memory's recency score halves. Default 30 days.
• time_weight: how much recency contributes vs. pure similarity. Default 0.3.
• importance: a per-node weight set at ingest time. Range 0–1. Useful for boosting high-confidence facts.

A memory with recall_count = 10 has stickiness = 3.4, meaning it ages at 29% of the normal rate. A fact recalled 10 times is nearly as fresh tomorrow as it was the day it was first recalled.

Why typed relationships matter

Consider a coding assistant that remembers:

• "User's team uses async/await everywhere" (preference node)
• "Issue #431 — async bug in payment handler" (problem node)
• "PR #88 — fix for async bug" (solution node)

In a flat vector store, querying "payment bug" returns all three nodes if their embeddings are similar. In a context engine with typed edges (causes, resolves), querying "payment bug" can traverse from the problem to the solution, and from the solution to the preference that caused the pattern. A single context_chain call surfaces the full story.

The difference in practice

After 6 months of operation:

Vector store agent:

• Returns stale, low-value chunks that happened to embed near today's query
• High-value facts buried in growing noise
• No memory of which facts have been useful — every query starts from zero

Context engine agent:

• Frequently-recalled facts are stickier — they rise in the ranking
• Stale facts decay below threshold — they stop surfacing without explicit retrieval
• Related facts are linked — retrieving one surfaces its connected context

The agent with a context engine gets smarter over time. The agent with a vector store stays as confused on month 6 as it was on day 1.

When a vector store is still the right choice

Not every use case needs a context engine. Vector stores are ideal for:

• Static document corpora that don't evolve
• Single-session RAG where there's no concept of "memory across sessions"
• Use cases where all documents are equally important and time doesn't matter

Context engines are the right choice when:

• The agent accumulates knowledge over time (days, weeks, months)
• Some memories are more valuable than others based on usage patterns
• Facts are related and context chains add value
• You need the agent's effective knowledge to evolve, not just grow

Getting started

import feather_db as fdb

db = fdb.DB.open("agent_memory.feather", dim=768)

# Add a memory with importance weight
meta = fdb.Metadata(importance=0.9)
meta.set_attribute("source", "conversation")
db.add(id=1, vec=embed("User prefers Python 3.12+"), meta=meta)

# Adaptive decay search — stickier, recent memories rank higher
results = db.search(
    query_vec,
    k=10,
    half_life=30,
    time_weight=0.3
)

# Context chain — search + graph traversal
chain = db.context_chain(query_vec, k=5, hops=2)

Install: pip install feather-db · GitHub: github.com/feather-store/feather