Recall

The design decisions that define Recall

Every production memory system faces the same three choices: what to store, how to retrieve it, and when to trust it. The decisions Recall makes on each are different from most systems — and the differences compound.

What to store: filter at write time, not retrieval time. Most memory systems store everything and rely on retrieval ranking to surface what matters. This produces a Junk-to-Signal ratio that degrades retrieval precision proportional to the junk fraction. The Recall approach inverts this: the seven-stage write pipeline rejects ~70% of candidate memories before they reach storage. A denser, cleaner store means any retrieval method produces better results — there's simply less noise to rank past. The pre_filter stage alone accounts for ~62% of total rejections; its relevance_threshold is the single most impactful tuning parameter in the system.

How to retrieve: five methods, fused. No single retrieval method covers the full query space. Semantic search (cosine similarity over HNSW) handles paraphrase and concept matching. BM25 handles exact matches — product names, error codes, quoted terms, user IDs. Entity-graph traversal handles relational queries ("what do I know about Sarah's manager?"). Temporal range scanning handles time-anchored queries ("what was the plan last quarter?"). Type-filter pre-scans narrow the candidate pool before any scoring happens. Running all five concurrently and fusing with score-weighted RRF (k=60) achieves P@5 of 0.91 on LongMemEval_s — versus 0.78 for semantic-only. The 13-point gap represents queries that semantic search structurally cannot handle.

When to trust it: confidence × freshness, computed separately. A memory's reliability depends on two independent signals that decay at different rates. Confidence (how much to trust the content) is computed at write time from source strength, evidence count, recency, and type prior: conf(m) = min(1.0, 0.45·s + 0.20·r + 0.25·e + 0.10·t). Freshness (how current the memory is) is computed at retrieval time from time elapsed: freshness(t) = 2^(-t/τ) with type-specific half-lives. The two signals are multiplied before ranking. This means a high-confidence memory from 6 months ago competes on equal terms with a low-confidence memory from yesterday — neither automatically wins.

How the pipeline stages interact

The seven stages are sequential by design: each stage produces a more refined candidate set for the next. But understanding the interaction between stages matters for tuning.

pre_filter → extract: pre_filter rejects by predicted relevance; extract then attempts to identify what type of memory the surviving candidate should become. These stages should be tuned together. If pre_filter is too permissive (low threshold), extract receives more low-quality candidates and produces lower-confidence extractions. If pre_filter is too aggressive (high threshold), the false negative rate rises — real signals rejected before extraction. The recommended starting point is relevance_threshold: 0.40 for general workloads, 0.55 for high-noise environments (customer support, voice transcripts), and 0.35 for low-noise environments (structured research notes).

dedupe → conflict: deduplication (semantic hash, similarity threshold 0.85) runs before conflict detection. This ordering matters: two nearly-identical memories of "user works at Acme" and "user works at Acme Corp" should be merged by dedupe, not treated as conflicting by conflict detection. Getting this wrong produces unnecessary conflict flags that require human review. The dedupe threshold (0.85 default) is the key parameter; higher values reduce merging of semantically similar but factually distinct memories.

conflict → persist: the conflict stage is the final gate before storage. It checks whether any surviving candidate contradicts an existing memory with confidence above a threshold. For most deployments, the recommended handling is strategy: flag_for_review rather than strategy: auto_supersede — the latter is faster but loses the older memory silently. Flag-for-review adds a small latency overhead (the human loop) but preserves the full decision history.

What the numbers mean in practice

The headline metrics — ~90% junk rejection, P99 < 200ms, 85%+ on LongMemEval — translate into specific improvements in deployed agents.

~90% junk rejection: In a 4,096-token memory budget (the practical limit for most 128K-window models after system prompt and conversation history), the difference between R=10 (10 junk entries per signal) and R=0.1 (0.1 junk per signal) is approximately 3,700 tokens of useful context versus 370 tokens of useful context. The remaining 3,330 tokens are either noise or unused. Junk is not neutral — it actively occupies the context budget and degrades the agent's ability to surface what matters.

P99 < 200ms: Multi-retriever fan-out adds latency versus single-retriever retrieval. Recall's P99 is lower than most single-retriever alternatives despite running five retrievers concurrently, because the Rust core eliminates GC pauses that dominate Python-based systems' tail latency at the 99th percentile. For real-time agent use cases, P99 is the operative metric — mean latency hides GC spikes.

85%+ on LongMemEval: The LongMemEval_s benchmark specifically tests temporal, relational, and preference reasoning over multi-turn conversations — the query types most likely to fail in flat vector stores. The 85% figure reflects the full pipeline: write-time filtering producing a clean store, plus five-retriever fusion handling the full query-type distribution. Either half alone produces lower scores.

Deployment modes and operational considerations

Recall ships in three deployment modes, each with different operational characteristics.

Embedded mode (local, in-process): the Recall binary links directly into the host process via napi-rs (Node) or PyO3 (Python). No network boundary. Data never leaves the host process. P99 latency: ~45ms. Best for: single-tenant applications, edge deployments, development environments. Trade-off: all memory lives on the local machine; no replication, no multi-node fan-out.

Self-hosted mode (Postgres + Recall server): the Recall server runs as a separate process alongside a Postgres instance (with pgvector). The SDK communicates over a local network boundary. P99 latency: ~80-120ms. Best for: multi-tenant deployments, team-shared memory stores, production applications that need replication and backup via standard Postgres tooling. Trade-off: operational overhead of running Postgres and the Recall server.

Managed cloud (Recall-hosted): fully managed, multi-region, SLA-backed. SDK connects to the managed endpoint. P99 latency: ~120ms (same region). Best for: teams that don't want to operate infrastructure. Trade-off: data leaves your infrastructure; review the security page for current compliance state and roadmap.

All three modes use the same SDK interface. Migration from embedded to self-hosted to managed is a configuration change, not a code change — the VectorStore and MemoryStore abstractions in the Rust core ensure that the pipeline behavior is identical regardless of which backend the data lands in. This means you can develop and test in embedded mode and promote to self-hosted or managed in production without rewriting integration code.

Reading the research

The research content on this site is organized at two levels. The overview papers (linked below) assume familiarity with the pipeline architecture described above. The Learn track builds up that foundation incrementally — if any concept in the papers is unfamiliar, the relevant Learn page will have it with a worked example and interactive demo. The cheat sheet has every formula, threshold, and constant on one page for quick reference while reading. For the quantitative comparisons referenced above, the 2026 benchmark report documents methodology, dataset, and full results with interpretation guidance so you can evaluate the numbers against your own workload rather than taking the headline figures at face value.

The research papers

Three technical papers go deep on the areas where Recall's design departs most from conventional approaches:

• Confidence and Scoring — Full derivation of the confidence formula, freshness decay schedule, RRF with score-weighting, and end-to-end worked examples tracing a single memory from extraction through scoring to final ranking position.

• Layered Hallucination Defense — Architecture of the three-layer guard (write-time grounding, store-time consistency, read-time faithfulness), multiplicative escape rate analysis, calibration methodology, and integration patterns for async workloads.

• Drift Taxonomy — Four types of drift (data, concept, schema, vocabulary) with detection algorithms, significance testing, unified configuration, and the monitoring cadence required to catch slow-moving drift before it degrades retrieval quality. Includes a full PostgreSQL schema for storing drift findings and a dashboard interpretation guide.