Memory product · field guide

The six kinds of memory mnueron stores

A field guide to what's in your memory store, who reads it, and how it gets used — written for both technical and non-technical readers.

Read the six types Download PDF85 KB Download Word doc19 KB

Elevator pitch

mnueron is a persistent memory layer for AI agents. It stores six different kinds of memory, because human memory isn't one thing either. You don't remember “yesterday's coffee with Maya” the same way you remember “Maya works at Stripe” or “here's how to deploy.” We store them differently because they're used differently.

#	Type	What it is	Human analogy
1	Episodic memory the chat log	Raw conversations as they happened.	“I remember that call we had.”
2	Semantic memory standalone facts	If episodic memory is 'what happened,' semantic memory is 'what's true.	“I know the capital of France is Paris.”
3	Entity memory canonical things	People, projects, places, technologies, decisions.	Recognising Maya — same Maya as last month, even with different surface forms.
4	Relational memory the graph	Once you have canonical entities, you can store relationships between them.	The mental map of who-knows-whom and what-depends-on-what.
5	Procedural memory how-to runbooks	Procedural memory is the kind that says 'here's how to do X.	“Here's how I deploy to staging.” Step by step, reusable, tested.
6	Consolidation memory “this is a duplicate”	After enough conversations, you end up saving the same fact more than once.	The “wait, didn't I write this down before?” feeling.

Type #1

Episodic memory · the chat log

“I remember that call we had.”

Non-technical

Raw conversations as they happened. When you save a Claude or ChatGPT thread (via the Chrome extension or mnueron-import), every turn becomes one episodic memory. They’re time-stamped, in order, and grouped by the conversation they came from.

Technical

Lives in the memories table. Each row carries content, namespace, source/source_ref (so chunks can group back into a thread), and metadata fields like role, parent_ref, chunk_index. These rows are not deduped or rewritten — they’re the corpus everything else is derived from.

Real example

content:        "what's the latest on the Stripe-to-Mercury migration?"
namespace:      claude-web
source:         claude-export
source_ref:     conv_2025-02-14_abc123
metadata.role:  user
metadata.chunk_index: 14

How it's used

Dashboard list shows one row per thread (clustered by parent_ref)
Search hits this table via Postgres full-text search (BM25)
Context builder lets you cherry-pick chunks into a fresh chat
Foundation for the future recall index

Type #2

Semantic memory · standalone facts

“I know the capital of France is Paris.”

Non-technical

If episodic memory is 'what happened,' semantic memory is 'what's true.' These are facts you can lift out of a conversation and reuse without needing the conversation itself.

Technical

Also lives in memories, but distinguished by source: "fact-extraction", tags: ["extracted-fact"], and a metadata.derived_from pointer back to the parent episodic memory. Created by a background fact-extraction pass after each save (paid tier; free tier opts in via BYOK).

Real example

content:                 "Maya prefers Mercury over Stripe because of the 1099 export."
source:                  fact-extraction
tags:                    [extracted-fact, preference]
metadata.derived_from:   <id of the original chat memory>
metadata.category:       preference

How it's used

Faster recall — agent doesn't have to re-read the whole conversation
Cleaner search — facts score higher than raw chat for narrow questions
Feeds entity extraction — facts are where canonical names get pulled out

Type #3

Entity memory · canonical things

Recognising Maya — same Maya as last month, even with different surface forms.

Non-technical

People, projects, places, technologies, decisions. The proper nouns. mnueron resolves 'Maya,' 'Maya P.,' and 'maya@stripe.com' to one canonical entity so the rest of your memory store can point at it.

Technical

Lives in the entities table (migration 014_p2_entities) with display_name, entity_type, aliases, mention_count, and first/last-seen timestamps. A join table memory_entities links each entity to every memory that mentions it, preserving the actual surface form used.

Real example

display_name:    Maya Patel
entity_type:     person
aliases:         [Maya, Maya P., maya@stripe.com, Maya Patel]
mention_count:   47
first_seen_at:   2024-09-12
last_seen_at:    2026-05-21

How it's used

/dashboard/entities lists every canonical entity, searchable and type-filterable
Click into one for every memory, every alias, and the graph neighbourhood
Per-entity visibility controls (private / team / public) — the unit of sharing
Server-side extraction is paid-tier; free tier BYOK supported

Type #4

Relational memory · the graph

The mental map of who-knows-whom and what-depends-on-what.

Non-technical

Once you have canonical entities, you can store relationships between them. 'Maya works at Stripe.' 'The auth-rewrite project depends on Postgres 16.' 'The Mercury migration was approved by Jordan.' Each is one edge in your knowledge graph.

Technical

Lives in relations (migration 029): a typed predicate between two entity IDs, with a confidence score and a bi-temporal validity window. "Maya works at Stripe" might have valid_from: 2024-06-01, valid_to: null. When she switches jobs we close the window — we don't delete the edge.

Real example

from_entity_id:  <Maya's id>
predicate:       works_at
to_entity_id:    <Stripe's id>
confidence:      0.94
valid_from:      2024-06-01
valid_to:        null            ← still true today

How it's used

/dashboard/graph renders this as a force-directed view, click to re-anchor
Date slider = point-in-time querying: 'show me what was true on 2024-12-01'
Agent reasoning — when an agent needs 'people at Stripe,' it walks edges, not full-text

Type #5

Procedural memory · how-to runbooks

“Here's how I deploy to staging.” Step by step, reusable, tested.

Non-technical

Procedural memory is the kind that says 'here's how to do X.' Step-by-step, reusable, tested. This is the type Mem0 doesn't have — it's mnueron's leapfrog feature.

Technical

Lives in the procedural_memories table (migration 030). Each runbook has a title, an array of trigger_phrases (GIN- indexed for fast multi-trigger lookup), and a JSONB steps array — each step is { description, command?, check?, notes? }. The row also tracks success_count, failure_count, and last_used_at — high failure_count is the signal a runbook has drifted from reality and needs an edit.

Real example

title:           Deploy Elevizio API to Lightsail
trigger_phrase:  ship api
steps:
  1. ssh ubuntu@<lightsail-ip>
  2. cd /var/www/elevizio-api
  3. git pull && dotnet publish -c Release
  4. sudo systemctl restart elevizio-api
  5. curl https://api.elevizio.com/health   ← check
success_count:   23
failure_count:   1

How it's used

Agent gets a request matching trigger_phrase → pulls the whole runbook into context
Success/failure counter spots drifted runbooks (high failure = steps no longer match reality)
Live at /dashboard/procedural — create, edit, record outcomes in the UI

Type #6

Consolidation memory · “this is a duplicate”

The “wait, didn't I write this down before?” feeling.

Non-technical

After enough conversations, you end up saving the same fact more than once. Consolidation memory is memory about memory — proposals that say 'row #4827 and row #5912 might be the same thing.' You approve or reject; the store stays clean without you auditing every save.

Technical

Lives in consolidation_proposals (migration 029). Each row has a kind (duplicate, contradiction, stale), the two memory IDs under suspicion, a similarity score, and a status (pending/approved/rejected). Detection uses Postgres pg_trgm today; embedding-based detection is queued.

Real example

kind:           duplicate
memory_a_id:    <Maya prefers Mercury, saved Feb 14>
memory_b_id:    <Maya likes Mercury better, saved Apr 3>
score:          0.94
status:         pending
proposed_at:    2026-05-20

How it's used

/dashboard/consolidate is the review queue — approve to mark for merge
Approved proposals teach the detector which phrasings mean the same thing
Detection is paid-tier (CPU + LLM cost); review is free for everyone

How the six fit together

Picture a pipeline running every time you save a chat:

1
Episodic memory saved
always
2
Semantic facts extracted
paid tier OR BYOK
3
Entities extracted + resolved
canonical_id stamped
4
Relations extracted
bi-temporal windows
5
Procedural runbooks
user-curated, not auto
6
Consolidation detection
async, paid-tier

Each layer is derived from the one above it, and each layer is queryable on its own. The dashboard has one page per layer.

What the dashboard surfaces

Page	Shows	Backed by
/dashboard (Memories)	Episodic chat list, paginated, freshness-dotted, searchable	memories
/dashboard/analytics	KPIs, 12-month volume chart, top-entities leaderboard	/api/stats/*
/dashboard/entities	Canonical entity browser, type filters	entities
/dashboard/entities/[id]	Per-entity detail — aliases, memories, relations, visibility	entities + memory_entities + relations
/dashboard/graph	Force-directed knowledge graph with bi-temporal slider	relations + entities
/dashboard/procedural	Runbook manager — create/edit, record success/failure	procedural_memories
/dashboard/consolidate	Duplicate review queue, run-detection button	consolidation_proposals
/dashboard/context-builder	Cherry-pick + format memories for paste into ChatGPT/Claude	memories

What's not tracked yet

mnueron is opinionated about what to add when. Today we do not track:

Recall counts

How many times a memory was pulled into context. The /api/recall plumbing is queued.

Decay scores

Column exists, no logic maintains it. The dashboard derives 'freshness' from age only.

Embedding similarity

Search is BM25 (Postgres FTS) today. Vector search lands when a hosted embedder is wired.

Cross-org entity dedup

Every org has its own canonical 'Maya'. Correct for privacy; not a roadmap reversal.

When recall tracking ships, the Analytics page will gain a “most-recalled memories” leaderboard and the list view will gain a “popularity” sort. The freshness dot will mix recall-recency into the bucket — heavily-used “old” memories will still read as fresh.

Quick reference for builders

Integrating with mnueron and want to know which type to query for which intent?

Find what we said about X	search episodic — /api/memories?q=...
What do I know about X	load entity — /api/entities/<id> + relations
What's the state of X right now	walk relations with ?asOf=<today>
How do I do X	look for procedural with matching trigger_phrase
What memories are stale / duplicated	poll /api/consolidate?status=pending
Show me my month	/api/stats/timeseries?bucket=month&months=12

mnueron memory product · field guide · last updated 2026-05-22