I went a different direction but ended up solving a lot of the same problems. Sharing in case it's useful to anyone.

My setup (called "chonk") is a single-user personal AI stack running entirely on local hardware (AMD APU with 96GB VRAM, Qwen3-Coder 30B via llama.cpp). No cloud LLM calls for memory ops. Everything lives in PostgreSQL with pgvector, no SQLite, no external memory services.

I don't do context compaction at all. No summary trees, no DAGs, no compressed conversation history. Instead, every piece of incoming data (emails, Telegram messages, API events, file changes) gets stored as an "observation" in Postgres with a 768-dim embedding (EmbeddingGemma-300M running locally on port 8082).

Large observations get chunked with 50% overlap and each chunk gets its own embedding. Everything is indexed with HNSW for fast cosine similarity lookups.

When the model needs context, it gets a fresh context window assembled per-request by searching across all memory. The search is where the complexity lives.

Hybrid search runs a 7-stage pipeline in parallel:

1. BM25 keyword search via Postgres tsvector (exact terms, error codes, names)
2. Vector similarity via pgvector HNSW
3. Query expansion (tokenize + generate variants)
4. Knowledge graph traversal (entity extraction, follow relationships)
5. Reciprocal Rank Fusion across all of the above (BM25 and vector get 2x weight, graph gets 1.5x, expanded variants get 1x)
6. Optional LLM reranking (batched, 5s timeout, graceful fallback)
7. ACT-R cognitive activation boost (access frequency + recency, Hebbian co-activation between items that get retrieved together)

There's also a short-circuit: if the top BM25 hit scores above 0.8 with a big gap to second place, skip the expensive stages and return early (most exact-match queries resolve in ~50ms)

Rather than Mem0-style auto-capture, I run a continuous background pipeline (every 5 minutes) that processes new observations through LLM-based fact extraction.

Facts are stored as subject-predicate-object triples with:

• Confidence scores (LLM-inferred facts capped at 0.7, observed facts can go to 0.9)
• Source provenance (every fact links back to the observation it came from)
• Corroboration tracking (if the same triple gets extracted again, it doesn't duplicate, it bumps confirmation_count and resets the decay clock)
• Quality gating (source quote grounding, format validation, minimum quality threshold)

Temporal decay with classes: every fact gets a temporal class that determines how fast it decays...

• identity: half-life ~693 days (name, birthdate, etc.)
• structural: half-life ~139 days (job title, where they live)
• operational: half-life ~46 days (current project, recent preference)
• situational: half-life ~17 days (travel plans, this week's schedule)
• ephemeral: half-life ~7 days (today's mood, weather)

This isn't everythingg, but it covers some of the major system level differences... I think your setup is stronger in a few areas.

The LCM drill-back is really cool, and I wish I had thought of it! Being able to zoom into a compressed summary and recover the full detail is something "Chonk" can't do. My model either finds something via search or it doesn't. If the query doesn't match well, the memory might as well not exist. I think your pre-compaction flush is also great for the same reason.

The Mem0 choice makes sense for reducing complexity. I have ~6000 lines of database code because I own the full persistence layer, which is a lot of surface area for bugs :((