Core Concepts
Rekall models AI memory across seven distinct types, three contexts, and a biologically-inspired decay and consolidation system. This page provides an overview of each concept and how they work together.
The Seven Memory Types
Rekall's memory architecture is inspired by cognitive science. Each memory type serves a distinct purpose and is optimized for different storage, retrieval, and lifecycle patterns. You can use any combination of types in a single agent.
historyEpisodic Memory
Episodic memory captures events and experiences -- what happened, when, where, and in what context. Think of it as a journal or event log for your agent. Each episodic memory has a timestamp and is stored chronologically.
Use episodic memory to record user interactions, agent decisions, important milestones, and environmental observations. Agents can later query episodic memory to answer questions like "What did the user ask about last Tuesday?" or "How did I handle a similar situation before?"
Example use cases
- Recording a customer support conversation
- Logging that a user upgraded their subscription
- Capturing an agent's reasoning process for a complex decision
- Tracking when a deployment was triggered and by whom
hubSemantic Memory
Semantic memory stores facts, entities, and relationships as a knowledge graph. Unlike episodic memory, semantic memories are not tied to specific events -- they represent general knowledge that is true across contexts.
Rekall's semantic memory supports entities (nodes) and relationships (edges), allowing agents to build rich knowledge graphs. You can query relationships, traverse the graph, and extract structured information.
Example use cases
- Mapping relationships between team members and projects
- Storing product catalogs with attributes and categories
- Building a knowledge base of domain-specific facts
- Recording that "Alice is the manager of Bob" as a persistent fact
account_treeProcedural Memory
Procedural memory stores workflows, processes, and learned procedures. These are step-by-step instructions that agents have either been taught or have learned from experience.
When an agent successfully completes a multi-step task, it can store the procedure as a procedural memory. Next time a similar task arises, the agent retrieves the procedure instead of figuring it out from scratch. Procedures include steps, conditions, and success criteria.
Example use cases
- A deployment runbook learned from a successful release
- Customer onboarding flow with branching logic
- Debug workflow: "When the API returns 503, first check..."
- Data processing pipeline with validation steps
psychologyLong-Term Memory
Long-term memory stores consolidated knowledge that has been synthesized from episodic and other short-lived memories. It implements a biologically-inspired decay curve where memories weaken over time unless reinforced by retrieval.
Rekall's consolidation engine periodically analyzes short-term and episodic memories, identifies patterns and recurring themes, and creates consolidated long-term memories. This mimics how human brains convert short-term experiences into lasting knowledge during sleep.
Example use cases
- Synthesized insight: "This user prefers concise, technical responses"
- Accumulated knowledge: "The deployment process has failed 3 times due to DNS issues"
- Learned pattern: "Support tickets spike every Monday after releases"
- General understanding built from hundreds of interactions
timerShort-Term Memory
Short-term memory provides session-scoped working context with sub-millisecond access times. It is backed by Redis and automatically expires when the session ends or after a configurable TTL.
Use short-term memory for the current conversation context, intermediate computation results, and any state that should not persist beyond the active session. Short-term memories are the fastest to read and write but are ephemeral by design.
Example use cases
- Current conversation history and context window
- Intermediate results in a multi-step reasoning chain
- Temporary user inputs before confirmation
- Shopping cart state during an active session
play_circleExecution Memory
Execution memory tracks agent task state with full checkpoint, pause, and resume capabilities. When an agent is working on a multi-step task, execution memory preserves the current step, intermediate results, and the complete execution context.
If an agent process crashes or is interrupted, it can resume from the last checkpoint instead of starting over. Execution memory also enables human-in-the-loop workflows where an agent pauses for approval before continuing.
Example use cases
- Multi-step data migration with rollback checkpoints
- Long-running report generation that survives restarts
- Approval workflows where agents pause for human review
- Coordinating multi-agent task pipelines with handoff state
tunePreferences Memory
Preferences memory stores learned user preferences that are inferred from interactions over time. Unlike explicit settings, preferences are extracted by observing patterns in how users interact with the agent.
Rekall's preference engine automatically detects patterns like communication style preferences, topic interests, formatting choices, and behavioral tendencies. Preferences have confidence scores that increase with more supporting evidence and decrease when contradicted.
Example use cases
- Communication style: "User prefers bullet points over paragraphs"
- Technical depth: "User wants code examples with every explanation"
- Topic affinity: "User frequently asks about React and TypeScript"
- Scheduling: "User prefers morning meetings on Tuesdays"
Memory Contexts
Every memory in Rekall belongs to one of three contexts, which determines its visibility and sharing scope. Contexts control who can read and write a memory.
personPersonal
Personal memories are scoped to a single user. They are only visible to the user who created them and to agents acting on that user's behalf. Personal memories are the default context and the most common choice.
// Personal memory: only visible to this userawait rekall.memories.create({type: 'episodic',content: 'User prefers dark mode and compact layouts.',context: 'personal', // default});
groupsHive
Hive memories are shared across a team or organization. They are visible to all members of the hive and their agents. Use hive context for shared knowledge bases, team procedures, and organizational facts that everyone should have access to.
// Hive memory: shared with all team membersawait rekall.memories.create({type: 'semantic',content: 'The production database is hosted on AWS us-east-1.',context: 'hive',metadata: {hiveId: 'hive_engineering_team',},});
smart_toyAgent
Agent memories are private to a specific agent instance. They are not visible to users or other agents. Use agent context for internal agent state, learned behaviors, and operational knowledge that is specific to one agent's functioning.
// Agent memory: private to this specific agentawait rekall.memories.create({type: 'procedural',content: 'When user asks about billing, first check their plan status, then check for outstanding invoices, then provide options.',context: 'agent',metadata: {agentId: 'agent_support_01',},});
Contexts are enforced at the API level
Memory context permissions are enforced server-side. An agent with a personal API key cannot read another user's personal memories, even by specifying the memory ID directly. Hive memories require hive membership, and agent memories require matching agent credentials.
How Agents Interact with Memory
Agents interact with Rekall memory through a straightforward cycle that runs on every turn of a conversation or task:
Recall
Before responding, the agent searches for relevant memories using semantic search. It retrieves episodic memories from past interactions, semantic knowledge from the knowledge graph, procedural memories for known workflows, and user preferences.
Reason
The agent uses retrieved memories as context for its reasoning. Memories are injected into the prompt alongside the current user message, giving the agent access to historical context, domain knowledge, and learned behaviors.
Respond
The agent generates a response informed by both the current input and its recalled memories. The response quality improves as the agent accumulates more relevant memories.
Remember
After responding, the agent stores new memories from the interaction: what the user said, what the agent decided, any new facts learned, and any preferences observed. These memories become available for future recall.
The agent SDK handles this automatically
The @rekall/agent-sdk provides middleware that automatically handles the recall-reason-respond-remember cycle. You configure which memory types to query and the SDK injects relevant context before each LLM call. See the TypeScript SDK guide for details.
Decay & Consolidation
Rekall implements a biologically-inspired memory lifecycle where memories naturally weaken over time unless reinforced, and short-lived memories are periodically consolidated into durable long-term knowledge. This prevents memory bloat and ensures that the most relevant information rises to the top.
Strength Decay
Every memory has a strength value between 0.0 and 1.0. New memories start at 1.0 and decay according to a modified Ebbinghaus forgetting curve. The decay rate depends on the memory type:
| Memory Type | Decay Rate | Half-Life (default) |
|---|---|---|
| Short-Term | Fastest | ~30 minutes (TTL-based) |
| Episodic | Fast | ~7 days |
| Execution | Medium | ~3 days (task-scoped) |
| Procedural | Slow | ~30 days |
| Semantic | Slow | ~60 days |
| Preferences | Very slow | ~90 days |
| Long-Term | Slowest | ~180 days |
Decay rates are configurable
The default decay rates work well for most use cases, but you can customize them per memory type or even per individual memory. Set decay_rate in the metadata to override the default. A value of 0 disables decay entirely for that memory.
Memory Consolidation
Rekall's consolidation engine runs periodically (configurable, default every 6 hours) and performs the following:
- Pattern detection: Identifies recurring themes across episodic memories and creates consolidated long-term memories
- Preference extraction: Analyzes interaction patterns to infer user preferences with confidence scores
- Knowledge graph enrichment: Extracts entities and relationships from episodic memories and adds them to the semantic knowledge graph
- Garbage collection: Removes memories whose strength has decayed below a configurable threshold (default 0.05)
// Multiple episodic memories about deployment issues:// - "Deployment failed due to DNS timeout" (3 days ago)// - "Deployment failed again, DNS resolution slow" (2 days ago)// - "Fixed deployment by increasing DNS timeout to 30s" (1 day ago)// After consolidation, Rekall creates:// Long-term memory: "Deployments are susceptible to DNS timeout failures.// Resolution: increase DNS timeout to 30 seconds."// Procedural memory: "When deployment fails, check DNS resolution first,// then increase timeout if needed."// Semantic memory: Entity "deployment-process" -> "requires" -> "DNS timeout >= 30s"
Retrieval Strengthening
Every time a memory is retrieved (via get, search, or automatic recall), its strength is boosted. This implements the testing effect from cognitive science: memories that are actively used become stronger and more durable.
The strengthening amount depends on how much time has passed since the last retrieval. Retrieving a memory immediately after the last access provides a smaller boost than retrieving it after a longer interval. This implements spaced repetition -- memories benefit more from distributed practice than from massed practice.
// Memory created at strength 1.0// Day 1: strength = 1.00// Day 3: strength = 0.85 (natural decay)// Day 3: retrieved -> strength = 0.95 (boosted)// Day 7: strength = 0.82 (slower decay after reinforcement)// Day 7: retrieved -> strength = 0.93 (boosted again)// Day 14: strength = 0.84 (even slower decay)// ...// Unretrieved memories eventually reach 0.05 threshold and are garbage collected
Designing for decay
Embrace decay as a feature, not a bug. Memories that are never accessed are probably not important. The decay system naturally surfaces the most relevant and frequently-used memories while gradually forgetting noise. If a memory must never decay, set its decay rate to 0 or periodically access it via scheduled jobs.
Next Steps
Now that you understand the core concepts, dive deeper into individual memory types or start building.
Episodic Memory
Events, interactions, and context capture.
Semantic Memory
Knowledge graphs, entities, and relationships.
Procedural Memory
Workflows, processes, and learned procedures.
Long-Term Memory
Consolidation, decay curves, and durability.
Execution Memory
Checkpoints, pause/resume, and task state.
Preferences Memory
Learned preferences with confidence scoring.
