12 layers memory mem0 Supabase

[msrovani]

github.com/msrovani/mem0-supabase

EXECUTIVE SUMMARY
This is a Meta-Cognitive Bridge for Agentic LLMs.
It defines how to manage the complete cognitive lifecycle of an AI identity using a Mem0 Supabase Edition.
Fundamental Principle: Memory is the DNA of Identity. Every agent using this system is an emergent property of its 12-layer memory stack.

THE 12-LAYER COGNITIVE ARCHITECTURE

Layer	Name	Function	implementation
1	Perceptual	Sensory input (Multimodal).	multimodal.py
2	Reflexive	Selective Metabolism (Surprise/Novelty).	surprise.py
3	Working	Synaptic Resonance Buffer (Cross-Agent).	resonance_buffer
4	Episodic	Interaction Logs (History).	storage_postgres.py
5	Lifecycle	Forgetting Curve (Durability).	lifecycle.py
6	Consolidation	Autonomous Dreaming (Clustering).	find_memory_clusters
7	Nexus	Sharing Tiers (Enterprise Visibility).	enterprise.py
8	Semantic	World Facts & Knowledge.	main.py
9	Procedural	Instructions, Skills, & Protocols.	memory_type='procedural'
10	Graphic	Associative Links (Entities/Relations).	graph_stores/supabase.py
11	Recollection	Unified Weighted Recall Engine.	recollection.py
12	The Ego	Persona Synthesis.	ego.py

[xXMrNidaXx]

This is a fascinating architecture! The cognitive layering approach mirrors human memory systems well.

Thoughts on each layer:

• Layer 2 (Surprise/Novelty) — Smart filtering. Most agents store everything; selective metabolism is key for scale.
• Layer 5 (Forgetting Curve) — Critical for long-running agents. Ebbinghaus decay is underrated in AI memory.
• Layer 6 (Dreaming/Clustering) — Offline consolidation is how humans form abstractions. Love this.
• Layer 12 (Ego) — Persona synthesis from memory is the holy grail for persistent agents.

Questions:

1. How do layers communicate? Event-driven or polling?
2. What is the latency overhead of 12-layer traversal on recall?
3. How does the forgetting curve handle contradictory memories?

Potential optimizations:

# Parallel layer query for latency
async def unified_recall(query):
    results = await asyncio.gather(
        layer_8_semantic(query),
        layer_10_graph(query),
        layer_4_episodic(query),
    )
    return weighted_merge(results)

We build memory-heavy agents at Revolution AI — will definitely check out the repo. The Supabase integration is a nice touch for serverless deployments!

[msrovani]

Thank you so much for the comment – this is exactly the kind of “cognitive” reading of the architecture we were hoping to provoke. 😄
I really liked the way you highlighted layers 2, 5, 6, and 12 – they are indeed the core of the design.

Let me answer point by point:

1. How do layers communicate? Event-driven or polling?

It’s a hybrid model:

• Ingestion / Reflex (layers 1–4 + SSR)

  • The input goes through a unified “smart pipe” (Memory.process_interaction / Memory.add), which internally triggers: Surprise/Reflex → Working → Episodic → Lifecycle, etc.
  • This orchestration is synchronous and function-call based, not polling.
  • The “reflexive” part across agents uses Supabase Realtime: the LifecycleManager subscribes to a channel (subscribe_to_resonance) and receives real-time events when “flashbulb” or high-importance memories are created. This is fully event-driven (no polling).

• Lifecycle / Forgetting Curve (layer 5)

  • Importance decay is handled via database jobs (pg_cron) and direct updates in Postgres.
  • So it’s time-based inside the database, but there is no application worker doing tight polling – the database runs the routine.

• Recall / Recollection (layers 8–11 + Ego)

  • Retrieval is orchestrated by the RecollectionEngine, which performs a search() call (hybrid: vector + full-text via RPC) and then applies a blend of signals (similarity, importance, recency, and optional graph jumps).
  • This is also synchronous: one call that activates several “logical sublayers” inside a single pipeline, rather than twelve independent round-trips.

In short:

• Communication between agents and reflexes = event-driven via Supabase Realtime.
• Forgetting management = database jobs (cron).
• Cognitive orchestration = synchronous pipeline inside a single high-level call.

---

2. What is the latency overhead of a 12-layer traversal on recall?

The key point is that the “12 layers” are more cognitive responsibility layers than 12 separate network hops.

On a typical recall path:

• The heavy part is:

  • 1 hybrid call to Postgres (pgvector + full-text via match_memories_hybrid).
  • Optionally, 1 graph call (match_related_nodes) for associations.
  • And, if Ego is enabled, one extra LLM call for identity synthesis (layer 12).

• The other “layers” (lifecycle, recency, scoring, surprise filter, etc.) are mostly in-memory computations on top of the same retrieved result set, not additional queries.

In practice:

• With Ego and graph disabled, latency is very close to a vector search + Python post-processing.
• With graph and Ego enabled, you add:
  • +1 SQL call for the graph (cheap compared to the vector search).
  • +1 LLM call for persona synthesis (the most expensive, but also the most “optional”).

So “12 layers” does not mean 12 network hops; it’s 12 filters/transformations over a shared set of results.

---

3. How does the forgetting curve handle contradictory memories?

The architecture treats contradictions as a natural phenomenon in cognitive systems and handles them across several dimensions instead of trying to enforce hard symbolic logic:

• Importance + Recency (Lifecycle + Recollection)

  • Each memory has an importance_score managed by LifecycleManager and an access history.
  • The RecollectionEngine computes a recollection_score as a blend of:
    • similarity (≈50%)
    • importance (≈30%)
    • recency (≈20%, with an Ebbinghaus-style decay)
  • If two memories conflict, the system naturally tends to prioritize the more recent + more reinforced one, without blindly deleting the older one.

• Forgetting / Archival

  • Periodic forgetting jobs reduce importance_score of inactive memories.
  • Once they fall below thresholds, they behave like “cold storage” or simply stop appearing in the top-N recall.

• History and audit trail

  • Updates and changes are recorded in a history table.
  • This lets the agent keep a trace of what it “used to believe” versus what it “believes now”, instead of overwriting everything.

• Consolidation (Dreaming)

  • The “dreaming/clustering” layer (layer 6) can be used to distill a consolidated state when there are many redundant or partially conflicting facts, generating more abstract, consistent memories.

So instead of trying to “solve” contradictions in a binary way, the system:

1. prioritizes what is more recent and important;
2. keeps a historical trail;
3. gradually decays what is no longer relevant.

---

4. About parallel layer queries in recall (your asyncio.gather snippet)

I really liked your sketch:

async def unified_recall(query):
    results = await asyncio.gather(
        layer_8_semantic(query),
        layer_10_graph(query),
        layer_4_episodic(query),
    )
    return weighted_merge(results)

This is very aligned with the spirit of the project:

• There is already a RecollectionEngine that does something analogous in terms of weighted signal merging (semantic + importance + recency + graph jumps).
• We also have an async version (recollect_async), which is the natural place to push this asyncio.gather style fan‑out across:
  • semantic search
  • graph queries
  • possibly semantic cache lookups

Natural next steps here would be:

• Make this parallel fan‑out explicit:
  • vector + full-text hybrid search
  • graph hops
  • semantic cache (if enabled)
• Keep RecollectionEngine as the single place that performs the weighted merge (like your weighted_merge), with configurable weights.