hermes - 💡(How to fix) Fix Feature: bundle findings_to_wiki — auto-populate memory + structured finding detection [1 participants]

Summary

Bundle a lightweight findings_to_wiki memory provider that auto-populates MEMORY.md from conversation turns AND detects structured findings (analysis reports, decisions, key findings) for downstream curation.

Unlike existing providers (Honcho, Mem0, OpenViking), findings_to_wiki is not a storage backend — it's a content detection layer that feeds the built-in MEMORY.md.

What it does

Two things in sync_turn():

1. Auto-populate MEMORY.md. After every user↔assistant exchange, extracts a short fact (timestamp + topic + key insight) and writes to ~/.hermes/memories/MEMORY.md. Skips trivial turns (thanks, ok, 👍) via a skip-list.

Without this, memory is ONLY populated by explicit memory() tool calls — the agent has to remember to save. With auto-populate, every turn potentially adds a fact.

2. Auto-detect structured findings. Patterns matched via configurable regex:

• Prism analyses (## Findings, ## Conservation Law, ## Findings Table)
• ADRs (## Decision, ## Status, ## Context)
• Research reports (## Key Findings, ## Verification, ## Recommendations)

When 2+ markers match (min 100 chars threshold), the full analysis is saved for downstream curation (LLM Wiki, other KB).

Why now

The MemoryProvider ABC (agent/memory_provider.py) and its hooks (sync_turn, on_session_end) have been stable for a long time. Currently no bundled provider uses these hooks for content detection — they all focus on external storage.

The mem_to_file provider (the minimal built-in) dumps raw conversation history. findings_to_wiki is a natural upgrade: it writes to MEMORY.md directly (which is already injected into system prompt) and detects structure where mem_to_file sees blobs.

Proposed implementation

~150 lines of Python in plugins/memory/findings_to_wiki/__init__.py:

class FindingsToWikiProvider(MemoryProvider):
    def sync_turn(self, user_content, assistant_content, *, session_id=""):
        # 1. Save short fact to MEMORY.md
        fact = extract_fact(user_content, assistant_content)
        if fact:
            append_to_memory(fact)  # atomic write, dedup, trim to limit
        
        # 2. Detect structured findings via regex
        if len(assistant_content) > 100:
            ftype = detect_pattern(assistant_content, config.patterns)
            if ftype:
                save_finding(assistant_content, ftype)  # to configurable output dir
    
    def on_session_end(self, messages):
        # Flush last turn as [end-of-session] fact
        ...

Key design decisions:

• Atomic writes via tempfile + os.replace (already in mem_to_file)
• Pattern configurable via memory.findings_to_wiki.patterns in config.yaml
• Threshold: 2+ matches, min 100 chars → avoids false positives on casual mentions
• sync_turn receives only text (no tool results) → sufficient for content detection
• on_session_end receives full message history → can flush remaining context

Comparison with existing providers

Next steps

Happy to submit a PR with the cleaned-up implementation. The current prototype (323 lines, includes wiki-specific code) needs ~150 lines trimmed — happy to do that and make it config-friendly.

Context: I built this for my own setup after getting tired of manually calling memory(). The finding detection was a side effect that turned out more useful than expected — it catches structured analysis that would otherwise be lost between sessions.

Future work: associative session search via co-occurrence graph

Beyond auto-populating memory, there's a complementary problem: finding sessions by meaning, not by keywords.

The gap

session_search (FTS5) is exact-match. It finds "RSI" if you search "RSI". But it cannot find RSI-related sessions when you search:

How co-occurrence PPR solves this

If session A mentions "RSI" + "перекупленность" + "индикатор", and session B mentions "индикатор" + "MACD" + "сигнал", then:

• Search перекупленность → FTS5 finds only session A
• PPR on the co-occurrence graph: перекупленность → индикатор → MACD → session B also ranked

The graph captures structural associations that no keyword search can match — not because of synonyms, but because terms that appear together in context get linked.

Prototype exists

Our hipporag-lite.py (~75 lines of core PPR logic on top of scipy sparse matrices) builds a co-occurrence graph from sessions and runs Personal PageRank for retrieval. Key metrics:

The approach is lightweight enough to run as an optional enhancement to session_search — no API calls, no GPU, no external services.

What this would look like upstream

A config flag on session_search:

session_search:
  fallback: ppr          # after FTS5 returns < N results, run PPR
  ppr_damping: 0.85
  ppr_iterations: 30

Or as a separate MemoryProvider that provides associative retrieval alongside the existing FTS5 index. Happy to outline the architecture in a dedicated RFC if there's interest.

Update 2026-05-05: working prototype as a Hermes Agent tool

The PPR search is now running as a registered Hermes Agent tool (assoc_search):

• Source: tools/assoc_search_tool.py (280 lines)
• Auto-discovered by the tool registry (no monkey-patching)
• Lazy imports (scipy loaded only on call, not at agent startup)
• Uses the existing ppr_matrix.npz built by the indexing pipeline
• Falls back gracefully when matrix unavailable

The tool is registered under the search toolset alongside session_search. The agent can call it explicitly or via a workflow rule: "if session_search returns <3 results, call assoc_search with the same query."

Complete implementation would upstream this as an optional extension to session_search_tool.py — adding a ppr_fallback: true config flag that transparently runs PPR after FTS5.