Agent memory
Persistent memory for AI agents.
Keep state, decisions, and tool output available across sessions without maintaining a separate vector store and sync pipeline.
Agents forget because their context is scattered.
A useful agent needs more than a chat transcript. It needs a durable place for decisions, summaries, tool output, and user preferences, plus a reliable way to retrieve the right context later.
Before
- Session state in Redis
- Similarity search in a vector store
- History in an application database
- A sync pipeline between all three
With RushDB
- One record write path
- Managed search indexing after one-time setup
- Recall by meaning and agent ID
- Relationships when your workflow needs them
Graph intelligence on ingest
Incoming data becomes queryable graph context.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsWorking example
Store one decision. Recall it in the next session.
This example stores a summary from one agent session and retrieves it later with a plain-English question scoped to the same agent.
{
"agent_id": "agent-42",
"session_id": "session-7",
"action": "summarized",
"topic": "Q4 results",
"output": "Revenue grew after the pricing change."
}{
"labels": ["MEMORY"],
"propertyName": "output",
"query": "What pricing decision affected revenue?",
"where": { "agent_id": "agent-42" }
}{
"agent_id": "agent-42",
"topic": "Q4 results",
"output": "Revenue grew after the pricing change."
}TypeScript SDK
A complete starting point.
The example includes the one-time index setup so the retrieval path is explicit.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
AI overview and ontology
Use ontology and AI APIs so agents inspect stored labels, fields, values, and relationships before querying memory.
Open docsSemantic search
Create an embedding index on a string property and recall relevant memory with exact filters plus meaning.
Open docsMCP server
Expose memory operations to MCP-compatible agents that can browse labels, properties, query records, and manage relationships.
Open docsHow it works
Build the smallest useful workflow first.
01
Store the useful parts
Write summaries, decisions, tool output, and preferences as records with the agent or user IDs you already use.
02
Index the text you want searchable
Create a managed embedding index once for the text property you want recalled by meaning.
03
Recall with scope
Ask a plain-English question and filter the result to the correct agent, user, session, or workflow.
Know where it fits.
Use relationships deliberately
Attach records when your workflow needs explicit links between sessions, users, tasks, and outcomes.
Keep deployment choices open
Use RushDB Cloud for a fast start or deploy the platform with your own Neo4j instance.
Questions developers ask.
Next step