Skip to content

Cognitive Memory

Inspired by cognitive science (Tulving’s taxonomy), YantrikDB supports four memory types:

TypeWhat it storesExample
EpisodicEvents, experiences with context”User had a rough day at work on Feb 20”
SemanticFacts, knowledge, abstractions”User is a software engineer who likes AI”
ProceduralStrategies, behaviors, what worked”User prefers concise answers with code examples”
EmotionalValence-weighted memories”Dog’s death → high emotional weight → never forget”

Every memory goes through a lifecycle:

  1. Active — recently created or accessed, high importance
  2. Warm — moderate age, decaying importance
  3. Consolidation candidate — similar memories detected, ready to merge
  4. Consolidated — merged with related memories into a summary
  5. Archived — very old, low importance, compressed storage
  6. Tombstoned — explicitly forgotten or superseded

Memories decay over time using a half-life model:

decay_score = importance * (0.5 ^ (elapsed / half_life))
  • High-importance memories decay slowly (long half-life)
  • Low-importance memories fade quickly
  • Accessing a memory reinforces it (spaced repetition)
  • Emotional valence modulates decay — emotionally significant memories persist longer

When multiple memories about the same topic accumulate, YantrikDB automatically:

  1. Clusters similar memories by embedding similarity
  2. Extracts a summary that captures the essential information
  3. Creates a consolidated memory with higher importance
  4. Tombstones the original fragments (preserving them for audit)

This mirrors how human memory works — individual episodes compress into general knowledge over time.

When YantrikDB detects conflicting memories (e.g., “user works at Google” vs “user works at Meta”), it creates a conflict record with typed classification:

  • Identity facts — flagged immediately (critical): “works at Google” vs “works at Meta”
  • Preferences — resolved naturally in conversation: “prefers VSCode” vs “prefers Neovim”
  • Temporal conflicts — prefer most recent, flag if uncertain: “meeting on March 30” vs “meeting on April 15”
  • Minor contradictions — keep both, resolve lazily

Conflicts are resolved conversationally, not programmatically — the AI asks the user.

How does YantrikDB know that “PostgreSQL” vs “MySQL” is a conflict, not just two similar memories?

Substitution categories — curated vocabularies of interchangeable terms. When two high-similarity memories differ only by tokens from the same category, it’s flagged as a real conflict rather than redundancy.

8 built-in seed categories ship with every database:

CategoryExamplesMode
databasesPostgreSQL, MySQL, MongoDB, Redis, …exclusive
cloud_providersAWS, GCP, Azure, Vercel, …exclusive
programming_languagesPython, Rust, Go, TypeScript, …exclusive
frameworksReact, Vue, Django, FastAPI, …exclusive
rolesbackend, frontend, devops, ML, …exclusive
infrastructureKubernetes, Docker, Terraform, …exclusive
editors_toolsVSCode, Neovim, IntelliJ, Cursor, …exclusive
llm_providersOpenAI, Anthropic, Google, Mistral, …exclusive

Categories grow over time through a confidence-gated feedback loop:

  1. Seed vocabulary (confidence 0.95) — ships with the database, covers ~80 common terms
  2. User corrections (confidence 1.0) — when a user reclassifies a conflict, differing tokens are learned as new category members
  3. LLM suggestions (confidence 0.35) — AI agents can suggest new members, but they’re marked “pending” and cannot drive conflict detection until confirmed

Only members with confidence ≥ 0.6 can trigger conflict detection. This means LLM suggestions alone never create false conflicts — they need human confirmation first.

Anti-pollution: The learning system filters stopwords and requires single-candidate matching to prevent contaminating categories with irrelevant tokens.

Beyond storing facts, YantrikDB tracks what works:

  • Record strategies: “When the user asks about code, show examples before explanation”
  • Track effectiveness: Each procedural memory has an EMA-based score that adapts with reinforcement
  • Surface relevant procedures: When facing a similar task, retrieve strategies that worked before

This enables AI agents to genuinely improve over time — not just remember what happened, but learn from it.

YantrikDB tracks conversation sessions, enabling:

  • Cross-session continuity: Remember what was discussed last time
  • Session-aware triggers: “It’s been 3 days since we last talked about the migration”
  • Entity relationship depth: How many sessions have you discussed a topic across?

think() doesn’t just detect problems — it surfaces opportunities:

  • Redundancy detection: Similar memories that should be consolidated
  • Conflict detection: Contradictions including substitution-based conflicts
  • Pattern mining: Recurring themes in memory (behavioral patterns)
  • Gossip triggers: Categories ready for LLM-assisted expansion
  • Stale memory alerts: Facts that haven’t been verified recently
  • Session awareness: Context from previous conversation gaps