Reality Check: Super-Memory 3.0 — Viable Product or Feature Bloat?¶

TL;DR¶

If you build all 6 layers at once, it's bloat. But if you build a "Memory Kernel" with 3 core features, then layer on what your actual usage patterns demand, it's the strongest memory system in the open-source agent space. The key: modular by design, not monolithic by default.

The Brutal Honesty¶

The 8 vendors I analyzed are not hobby projects. Here's what each one actually costs to build properly:

You are one builder (Frozen Maple Labs). You don't have 20 engineers. So the question isn't "which features are good?" — it's "which 2-3 features unlock 80% of the value?"

What "Saving Context" Actually Means (Your Core Problem)¶

Let's re-read your original request: "The issue I feel like I am trying to solve for is how do we save context and not just create a RAG for old convos."

That breaks down into three specific problems:

Problem 1: "I have to manually remember to save memories"¶

Right now you call add_memory. That's manual. Most sessions, you forget. The memory system is opt-in, so it's always incomplete.

→ This is the #1 problem. Without auto-extraction, you don't HAVE a memory system — you have a sometimes-I-remember-to-save-notes system.

Problem 2: "My memories are just a pile of vectors with no structure"¶

You save "Use JWT for auth" and "User prefers dark mode" — they're isolated blobs. There's no relationship between them. There's no concept of "this fact about the user's project supersedes that older one."

→ This is #2. Without relationships, memory is just a better search index, not a knowledge system.

Problem 3: "Bad memories poison my context"¶

The LLM once hallucinated something. You saved it. Now it keeps coming up in searches. Or you changed your mind about a decision, but both the old and new fact come back. There's no way to rank, verify, or retire memories.

→ This is #3. Without trust/decay, your memory system gets worse over time, not better.

If you solve these three problems, you have a fundamentally different product than any of the 8 Hermes providers. Every single one of them has gaps in at least one of these three areas.

The Three-Tier Truth About Combining Techniques¶

Tier 1: The "Memory Kernel" (Build This — 4-6 weeks)¶

Three features. Nothing else. This is your v3.0.

┌──────────────────────────────────────────┐
│           Memory Kernel v3.0              │
│                                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  │
│  │ Auto-   │  │ Memory  │  │ Trust   │  │
│  │ Extract │  │ Graph   │  │ Engine  │  │
│  └────┬────┘  └────┬────┘  └────┬────┘  │
│       │            │            │        │
│       └────────────┼────────────┘        │
│                    │                      │
│              ┌─────┴─────┐               │
│              │  Qdrant   │               │
│              │  (kept)   │               │
│              └───────────┘               │
└──────────────────────────────────────────┘

1. Auto-Extract (inspired by Mem0 + ByteRover) - After every N turns (configurable, default 5), fire a lightweight LLM pass over the recent conversation - Extract: facts, decisions, patterns, preferences - Store them automatically — no manual add_memory calls - Use the existing Qdrant store (no new backend) - Cost: 1 LLM call per ~5 turns. Negligible with local models (ollama/llama.cpp).

2. Memory Graph (inspired by Hindsight + Supermemory) - When storing a memory, also extract entities (person, project, decision, preference) - Track relationships: SUPERSEDES, RELATED_TO, CONTRADICTS, DERIVED_FROM - Simple graph — NOT a full knowledge graph. Just enough to answer "what other memories relate to this?" - Implementation: Add a relationships JSON field to your existing Qdrant payload. Query with a second pass when needed.

3. Trust Engine (inspired by Holographic + Honcho) - Every memory starts at trust = 0.5 - After each retrieval, the agent's behavior signals quality: - Agent uses the memory in its response: +0.05 - Agent ignores the memory: -0.02 - User corrects the agent after it used this memory: -0.15 - User explicitly confirms: +0.10 - Below 0.2: memory is archived (not deleted, just not retrieved by default) - Above 0.8: memory is "promoted" — injected automatically on session start - This is the one feature NO ONE has done well in open source. It's your differentiator.

Total new code: ~2,000-3,000 lines of TypeScript. You're already writing TS. Your existing Qdrant setup handles storage. Your existing MCP server exposes the tools.

Tier 2: "Smart Layers" (Add These Only When Kernel Is Stable — 2-3 months each)¶

These are the things that make the product special, but are useless without the Kernel working:

4. Pre-Compression Extraction (inspired by ByteRover) - Hook into OpenCode's context compaction event - BEFORE the context window squeezes, extract any unsaved facts - This solves the "I was 50 turns deep and forgot to save" problem - Why it's Tier 2: Requires the Auto-Extract pipeline to already exist. Adds nothing on its own.

5. Tiered Loading L0/L1/L2 (inspired by OpenViking) - L0 (100 tokens): "What is this project about?" — auto-injected on every session start - L1 (2K tokens): "What are the key decisions and current patterns?" — loaded when planning - L2 (full): Specific memories — retrieved on demand - Why it's Tier 2: Requires the Trust Engine (to know which memories are L0-worthy) and the Memory Graph (to cluster related memories into L1). Useless without both.

6. User Modeling (inspired by Honcho) - Build a persistent "user profile" — preferences, communication style, expertise areas - Updated dialectically (the LLM reasons about the user based on conversation patterns) - Why it's Tier 2: Requires 50-100 sessions of data before it's meaningful. Honcho's insight only works at scale.

Tier 3: "Nice to Have" (Maybe Never — High Complexity, Marginal Value)¶

7. Full Knowledge Graph with SPARQL/RDF - Hindsight's approach. Requires a graph database (or complex Qdrant workarounds). - Verdict: Overkill. The simple relationships JSON in Tier 1 gets you 80% of the value.

8. Memory Decay / Consolidation - Old memories fade, similar memories merge. - Verdict: Cool concept, but adds massive complexity (what consolidates? when? how do you undo?). The Trust Engine in Tier 1 naturally handles this — low-trust memories get archived.

9. Multi-Peer Profiles (Honcho-style) - Different "peers" for different agent personas. - Verdict: Unless you're running multiple agents against the same user, this is bloat. Your existing projectId isolation in Super-Memory-TS handles the common case.

10. Dialectic Reasoning (Honcho's crown jewel) - LLM-synthesized insights about the user across sessions. - Verdict: Requires running a local LLM with substantial context. Beautiful when it works, but fragile and expensive. Honcho spent 18 months on this.

The "Will It Be Bloated?" Scorecard¶

What a Functional v3.0 Actually Looks Like¶

Week 1-2: Auto-Extract pipeline - Add an extractor.ts module - After every 5 turns, send recent conversation to local LLM (or the same LLM the user is already running) - Parse the output into structured memories - Feed them into your existing addMemory flow - Result: Memories accumulate without manual intervention

Week 3-4: Trust Engine - Add trust_score and retrieval_count to Qdrant payload - After each query, update scores based on agent behavior - Filter results: trust_score > 0.2 - Result: Bad memories naturally sink, good ones rise

Week 5-6: Memory Graph - Add entities and relationships to Qdrant payload - When storing, extract entities with a lightweight prompt - When retrieving, do a second query for related memories - Result: Memories are connected, not isolated

This is not bloat. It's ~2,500 lines of focused code on top of your existing architecture. Every feature directly solves one of your three stated problems. There are no speculative features.

The "What If I'm Wrong?" Fallback¶

The beauty of the Kernel approach: every feature is independent and optional.

• Auto-Extract can be disabled: system falls back to manual add_memory (your current behavior)
• Trust Engine can be disabled: all memories treated equally (your current behavior)
• Memory Graph can be disabled: isolated vector search (your current behavior)

You're not building a monolith. You're adding three optional modules to an existing system. If any module doesn't work, remove it and the rest keeps functioning.

Compare this to: - Mem0: Requires their cloud infrastructure or complex self-hosted setup - Honcho: Requires their peer model, dialectic engine, and cloud - Hindsight: Requires their graph database and reflect pipeline - Your v3.0 Kernel: Requires... a TypeScript file and an LLM call

The Final Answer¶

Will combining all techniques create bloat? Yes — if you build all 6 layers, all 12 features, all at once. That's a product team of 10+ people working for a year.

Will the Memory Kernel (3 features, 4-6 weeks) create a functional tool? Yes — and it will be more useful than any single Hermes provider because: 1. Auto-Extract fixes the "I forgot to save" problem (Mem0 has this, Holographic doesn't) 2. Trust Engine fixes the "bad memories poison context" problem (NO ONE has this well) 3. Memory Graph fixes the "pile of unrelated vectors" problem (Hindsight has this, but requires their full stack)

And it stays MCP-native and OpenCode-compatible throughout. You're not trading compatibility for features.

This is a supplement to the main report. Read the main report for vendor details; read this for build decisions.