Agent memory
Persistent memory for AI agents.
Every agent session produces state worth keeping: summaries, decisions, tool output, and user preferences. RushDB stores each as a MEMORY record tagged with agent_id and session_id, indexes the output field once, then lets a later session recall it with a plain-English query scoped to that same agent — no Redis, vector store, or sync pipeline stitched together by hand.
AI agent memory in RushDB is a durable graph record of an agent's session state, decisions, tool output, and preferences, retrievable later by meaning and by agent or session ID without a separate vector store.
Agents forget because their context is scattered.
A useful agent needs more than a chat transcript, but scattering that context across Redis session state, a vector store for similarity search, and an application database for history means three write paths to keep in sync. When one falls behind, the agent either repeats work it already did or answers from stale state, and nobody can tell which store held the truth.
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.
Each agent turn arrives as a small JSON payload — agent_id, session_id, action, topic, output — and RushDB writes it straight into a MEMORY record without a predefined schema. The output field becomes searchable the moment a managed index exists on MEMORY.output, so summaries and tool results are recallable by meaning as soon as they land, not after a batch embedding job.
01
Normalize incoming turns
RushDB infers types for agent_id, session_id, action, topic, and output as each MEMORY record is written, no upfront schema needed.
02
Auto-link session structure
Nested session or task payloads under a MEMORY record become traversable child records automatically, preserving turn order.
03
Enrich across sessions
Suggested-relationship analysis can surface links between memories sharing an agent_id or topic, connecting decisions scattered across sessions.
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.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
db.ai.indexes.create({'label': 'MEMORY', 'propertyName': 'output'})
db.records.create(
label='MEMORY',
data={
'agent_id': 'agent-42',
'session_id': 'session-7',
'topic': 'Q4 results',
'output': 'Revenue grew after the pricing change.',
},
)
recall = db.ai.search({
'labels': ['MEMORY'],
'propertyName': 'output',
'query': 'What pricing decision affected revenue?',
'where': {'agent_id': 'agent-42'},
'limit': 10,
})Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
AI overview and schema
Use schema 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 docsRelated guides
Read the concept before implementation.
These guides explain the category, tradeoffs, and related RushDB features behind this workflow.
How 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