AI agent memory that survives the session.
Agent memory is the durable context an agent can reuse after a chat, model call, MCP client, or workflow run ends. The useful version stores structured facts, decisions, tool output, entities, and retrieval evidence in a form that can be queried later.
What this guide covers
The practical decision points.
What memory needs to hold
Messages are only one input. Useful memory also includes tool results, summaries, entities, preferences, approvals, and events.
Why glue appears
Teams often split agent state across an application database, cache, vector store, and custom sync jobs.
How RushDB fits
RushDB stores the same payloads as Records with typed fields, graph links, searchable text, and live schema discovery.
Architecture sketch
A durable memory loop
The agent writes the useful output of each run as structured Records. Later runs inspect the available structure, retrieve by meaning or exact fields, and continue from stored context instead of replaying old transcripts.
Implementation example
Store and recall one memory record
This is the smallest useful agent-memory path: create an index for the text you want recalled, store structured JSON, then search within the correct agent scope.
What AI agent memory is
AI agent memory is a product data layer, not just a longer prompt. It gives an agent a durable place to store information that should survive a single inference call or conversation window.
Facts the agent learned from tools or users
Decisions and rationale that future runs should reuse
Entities such as accounts, users, documents, tasks, policies, and incidents
Searchable summaries and cited source material
Relationships between records that make context explainable
Why the standard stack gets fragile
A modern agent stack usually starts with ordinary application storage, then adds Redis for short-lived state and a vector database for semantic recall. The difficult part is not any single store. The difficult part is keeping all three synchronized as schemas, models, and workflows change.
The application database owns facts and history.
The cache owns current session state.
The vector store owns embeddings and similarity search.
Application code owns sync, retries, deletes, joins, and permission filters.
How RushDB models memory
RushDB starts with one primitive: the Record. A Record can represent a message, tool result, user preference, document chunk, entity, task, or event. Typed properties, graph relationships, semantic indexes, and ontology output all sit around that same primitive.
Decision table
Prompt memory vs durable memory
The practical distinction is ownership. Prompt memory is context assembled for one model call. Durable memory is stored product data that can be queried, filtered, linked, and reused across tools and sessions.
Exists only while the current prompt, chat, or framework session is assembled.
Lives as Records that remain available after the session, model, or client changes.
Usually replayed by stuffing summaries or transcripts into context.
Retrieved by semantic search, exact fields, relationship traversal, or ontology-aware query planning.
Often text-first, with structure reconstructed by prompts.
Stores typed fields, labels, nested records, relationships, and indexed text together.
Easy to prototype but hard to audit, scope, expire, or migrate.
Behaves like a backend data layer with explicit records, filters, docs-backed APIs, and deployment choices.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.