Vector search is one part of agent memory.
Vector databases are good at similarity search. Agent memory often needs more: durable records, exact filters, relationships, permissions, analytics, and a schema the agent can inspect.
What this guide covers
The practical decision points.
Vector search answers fuzzy questions
Embeddings help retrieve text when the user does not know the exact keywords.
Memory layers preserve product context
Agent memory also needs structured records, relationships, workflow state, and permission filters.
RushDB combines both paths
Semantic search works alongside typed properties, graph links, SearchQuery, and ontology.
Architecture sketch
Where vector search fits
Vector ranking is one retrieval path. A memory layer also owns the Records, exact filters, relationships, analytical projections, and schema awareness that surround that ranking step.
Implementation example
Combine semantic search with filters and schema discovery
The memory-layer pattern is to inspect the shape of the available data, constrain the search with exact fields, and return ranked Records that still carry product context.
What a vector database solves
A vector database stores embeddings and ranks items by similarity. It is valuable for fuzzy text retrieval, recommendation, clustering, and RAG over unstructured content.
Find related text without exact keyword matches.
Rank candidates by meaning.
Support RAG retrieval over documents or memories.
What a memory layer also needs
A production agent usually needs to know who owns a record, whether a record is active, which workflow produced it, what it is connected to, and whether a query is valid. Those needs live outside raw vector ranking.
Exact filters for tenant, status, dates, permissions, and workflow state
Relationships between documents, entities, users, events, and decisions
Aggregations for dashboards and operational views
Live schema discovery for adaptive UIs and safer agent queries
How RushDB combines them
RushDB lets you store Records, choose text fields to index for semantic search, filter by typed properties, traverse relationships, and inspect the live ontology. That means vector search becomes part of the memory layer instead of a separate store your application has to keep synchronized.
Decision table
Vector database vs memory layer
A vector database can be a strong component. The question is whether your application also needs structure, relationships, analytics, and agent-readable schema in the same place.
Store embeddings and rank items by similarity.
Store durable context as Records, then support semantic search, filters, relationships, and analytics.
Usually text chunks plus metadata.
Messages, tool results, documents, entities, events, decisions, tasks, and nested product payloads.
The app often owns metadata sync, joins, deletes, and schema drift.
The app writes structured data and queries one backend for meaning, values, relationships, and schema.
The agent often needs prompt-supplied schema notes or hardcoded metadata fields.
The agent can inspect live ontology before building filters, traversals, or semantic searches.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.