UnisonWhy Not Just Use a Vector Database for Agent Memory?
A vector DB gives you similarity search over chunks. Agent memory needs visibility scopes, fact supersession, conflict handling, and prompt-ready recall - the layer above the index.
You can build agent memory on a vector database - that's roughly what every memory layer does internally. The question is whether you want to build and operate the layer above it yourself.
What the vector DB gives you
Similarity search over embeddings. That's one retrieval signal - necessary, not sufficient.
What memory needs that the index doesn't have
| Need | Why raw vectors fail |
|---|---|
| Truth that changes | embeddings of "we use Redis" and "we dropped Redis" both match "queue architecture" - without supersession, recall returns both |
| Visibility scopes | private vs team vs company isn't a similarity problem; it's an authorization model |
| Multi-writer conflicts | two agents asserting opposites needs review semantics, not nearest-neighbor |
| Prompt-ready output | chunks need fusing, ordering, and clipping into one injectable block |
| Abstention | cosine similarity always returns something; memory must be able to say "I don't know" |
| Time-travel | "what did we believe on May 1" requires bitemporal records, not vectors |
Unison ships that layer as the product: hybrid retrieval underneath, bitemporal facts, scope-by-path visibility, and one-call recall with weakEvidence. Keep your vector DB for your RAG corpus - see memory vs RAG.
Why a Bigger Context Window Doesn't Fix Agent Memory
Even at 1M tokens, a context window resets every session - and context rot degrades quality long before the window is full.
Benchmarks
unison-evals is a public, reproducible benchmark harness: 4 datasets (LongMemEval, LOCOMO, MemoryAgentBench, Context-Bench), black-box adapters, same metrics for every system.