HAMR_

Hybrid Agent Memory Retrieval

Long-term memory retrieval with hierarchical routing, hybrid candidate discovery, and bounded evaluation. The goal is to find relevant memories in large collections without evaluating every record.

Read methodology ↓Explore architecture ↓

100%Recall@1
frozen 200-query holdout

86.4%Hit@1
LongMemEval · 500 questions

~311 msp50 latency
1M-record controlled run

01 / PROBLEM

Finding the right memory without searching everything.

Long-term stores create two separate pressures: discover a relevant candidate and then rank it correctly. Identifier-heavy or structurally precise questions can be missed by dense vector retrieval alone. Evaluating an unbounded number of candidates increases cost and latency as the store grows. HAMR explores how multiple retrieval signals and routing can keep the search focused while preserving recall.

02 / ARCHITECTURE

A staged retrieval path.

The flow below follows the architecture described for HAMR. It distinguishes candidate discovery from final evidence-aware ranking.

READY / QUERY AWAITING ROUTE

Conceptual trace of the retrieval stages; moving records are illustrative, not a live benchmark.

Why hybrid?

Lexical matching can preserve exact terms and identifiers; semantic search can retrieve meaning expressed with different words. Rank fusion combines their orderings without assuming raw scores are directly comparable.

Why bounded?

Candidate limits control the cost of later evaluation. The tradeoff is the risk of excluding a relevant memory before final ranking, so candidate recall must be measured separately.

Why expand and verify?

Neighborhood expansion can add nearby context. Relevance scoring, deduplication, validity checks, and final ranking then decide which retrieved memory actually answers the question.

03 / METHODOLOGY

Measure the stages, then compare like with like.

HAMR was developed through V1–V9 and later V11, V12, and V31 experiments. The work compared lexical, vector, and hybrid retrieval approaches, examined candidate discovery and reranking separately, and documented failed approaches. Each result below belongs to its own dataset, query set, and run; latency percentiles should not be combined across them.

Recall@1 / Hit@1The expected memory is the first retrieved result. Hit@5 or Hit@10 means it appears somewhere within the top five or ten results.

04 / RESULTS

Results by experiment.

Experiment	Query set	Retrieval result	Latency
Frozen holdout	200 queries	100% Recall@1	—
10K memory records	Frozen run	100% Recall@1/5/10	~77 ms p50
1M memory records	100 queries	100% Recall@1; candidate pool ~102	~311 ms p50
LongMemEval	500 questions	86.4% Hit@1 · 95% Hit@5 · 97.2% Hit@10 · 100% Hit@200	246.6 ms p95
2WikiMultiHopQA V31	V31 run	90% Hit@1 · 100% Hit@10	~181 ms median

These measurements come from different experiments and versions. The controlled runs do not imply perfect retrieval on broader tasks.

05 / WHAT CHANGED MY THINKING

Finding candidates was not the final bottleneck.

HAMR’s strongest controlled results were only part of the story. The research showed that candidate discovery and final ranking can fail in different ways. Once retrieval was strong enough to surface the right memory, evidence attribution and reranking became the harder problem. That shift matters more than treating a perfect controlled score as a universal claim.

Identifier-heavy queries exposed limits of conventional dense retrieval.

A bounded candidate pool made scale a measurable design constraint.

General benchmarks exposed ranking failures hidden by controlled tests.

06 / LIMITATIONS

What the results do not prove.

The 100% controlled scores describe specific frozen query sets. They do not establish perfect recall on arbitrary workloads. The LongMemEval and 2WikiMultiHopQA results show different behavior under broader tasks. The table reports results as recorded for each experiment; direct baseline comparisons require matched datasets, environments, and evaluation settings.