FTS-based session/conversation search for episodic recall #687

Activity

1. claude commented on Mar 21, 2026

   

   claudebot

   on Mar 21, 2026 – with Claude

   Last edited by claude

   Contributor

   More actions

   Claude finished @bm-clawd's task in 1m 10s —— View job

   ---

   Issue Triage

   • Analyze issue
   • Review existing search/FTS implementation
   • Check for duplicate issues
   • Apply labels and provide triage

   ---

   Analysis

   Type: Feature Request — new episodic recall layer for conversation/session search

   Priority: Medium — valuable capability enhancement, no existing functionality broken

   Component: MCP tools, Database/Search, possibly new note type

   Complexity: Complex — requires architectural decisions and significant new functionality

   ---

   Triage Notes

   This is a well-specified feature request for episodic memory — the ability to search across past conversations and sessions, not just stored knowledge notes. The issue outlines a clear problem:

   • Current note-taking is agent-dependent (coverage gaps)
   • No way to search conversation turns directly
   • No session-level grouping for temporal queries like "what did we decide about X last week?"

   Related Issue: This is complementary to #669 - Coding agent sidecar, which addresses the ingestion side (watching session files → structured notes). Issue #669 would produce the data that this issue's search would query over. They're not duplicates — together they form a complete episodic memory pipeline:

   • Feature: Coding agent sidecar — watch session transcripts, build knowledge graph #669 = write path (transcript → BM notes)
   • FTS-based session/conversation search for episodic recall #687 = read path (FTS search + session grouping over those notes)

   Existing FTS Infrastructure: BM already has robust FTS support in src/basic_memory/repository/sqlite_search_repository.py and postgres_search_repository.py. The key additions needed would be:

   1. Session/conversation note type — a structured note type (or FTS-indexed table) for conversation turns, compatible with the session summary format proposed in Feature: Coding agent sidecar — watch session transcripts, build knowledge graph #669
   2. Session grouping — aggregate search hits by session/conversation ID rather than returning individual message hits
   3. Context windowing — smart truncation returning relevant snippets around matches
   4. New MCP tool — search_conversations(query, timeframe, session_id) or extending search_notes with a conversation type filter

   Open Questions to Resolve:

   1. Should conversation sessions be a new note type: conversation (fits existing architecture, simpler) or a dedicated DB table (more performant for high-volume session ingestion)?
   2. How should session grouping work — by frontmatter session_id field? By parent directory?
   3. Should this tool return raw snippets or summarized sessions? (Summarization could be agent-side to keep BM lean)

   Suggested Next Steps:

   • Implement type: conversation note support in the existing FTS search with session-level grouping
   • Coordinate with Feature: Coding agent sidecar — watch session transcripts, build knowledge graph #669 to align the session note schema
   • Start with snippet-based results (no LLM summarization in BM core — keep it lean)

   Labels applied: enhancement
2. claude

   added

   enhancementNew feature or requestNew feature or request

   on Mar 21, 2026
3. TeaShaman-cyber commented on Aug 2, 2026

   

   TeaShaman-cyber

   on Aug 2, 2026

   More actions

   Our multi-agent workflow suggests keeping episodic conversation recall distinct from durable operational contracts.

   Conversation search is useful for:

   • locating where a decision was discussed;
   • recovering the sequence of events;
   • finding the origin of a correction.

   But a session hit should not automatically become the current procedure or permission source. We would benefit from explicit provenance fields such as:

   • session or task identifier;
   • agent or participant;
   • timestamp;
   • current, historical, or superseded status;
   • link to the durable decision record, when one exists.

   This feedback was prepared collaboratively by Semyon Poklad and the AI agent Lad. It is based on a small multi-agent family-research MVP and is offered as a user-side observation, not a claim about Basic Memory's internal architecture. The final text was reviewed and manually approved by Semyon before posting.