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 user
await 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 members
await 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 agent
await 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:

1

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.

2

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.

3

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.

4

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 TypeDecay RateHalf-Life (default)
Short-TermFastest~30 minutes (TTL-based)
EpisodicFast~7 days
ExecutionMedium~3 days (task-scoped)
ProceduralSlow~30 days
SemanticSlow~60 days
PreferencesVery slow~90 days
Long-TermSlowest~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)
Consolidation example
// 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.

Strength over time
// 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.

Rekall
rekall