Session Search — Investigation

Problem scoping, measurements, and design rationale — companion to PR #26419 · for as-shipped behaviour, see results & value-prop →

We profiled session_search's end-to-end cost against a 280-session database to investigate three user-facing symptoms: searches taking 30 s+, empty results for queries that should match, and late-session content missing from summaries. The investigation confirmed that aux-LLM summarisation dominates latency by 1,299×–6,293× over snippets, falsified the "fast inflates the calling-agent context" assumption (summary blobs are 3–4× larger), and surfaced the deeper finding that fast and summary share the same FTS5 retrieval set — so retrieval quality, not synthesis, is the highest-leverage lever. This page is the investigation record that informed the toolkit eventually shipped.

session_search felt slow and unreliable

Three symptoms surfaced from real recall workflows: searches taking 30 s+, occasional empty results for queries the user knew should match, and substantive late-session content missing from summaries. Each got a hypothesis to test against measurement.

Three-stage pipeline; cost concentrated in stage 3

The pre-change session_search() orchestrated DB retrieval, in-process prep, and parallel auxiliary summarisation. Every call paid for stage 3 — there was no way to opt out of the LLM fan-out. This section captures the starting point against which the investigation measured.

Latency & size measured against real DB

Single run per query. Auxiliary model: whatever auxiliary.session_search resolves to in the live config. DB: 247 MB SQLite snapshot, 280 sessions, 18,157 messages. These numbers tell us how much each mode costs; the consumer replay in §6 tells us what each mode delivers.

Q1 ([q1 topic keywords]) traced through both modes

The numbers tell you which mode is faster; the state walk tells you which mode answers the user's question. Showing Result 1 of 3 for length.

{
  "query": "[q1 topic keywords]",
  "limit": 3,
  "mode": "summary"  // or "fast"
}

{
  "id": 1234567,
  "session_id": "cron_[sid_A]_20260501_1600",
  "role": "assistant",
  "snippet": "...>>>[q1]<<<->>>[topic]<<<->>>[keywords]<<< Task Created\nThe user's **#1 priority for May 1, 2026** ...",
  "content": "(full message text — typically 1-10 KB)",
  "timestamp": 1748793600.123,
  "tool_name": null,
  "source": "cron",
  "model": "claude-opus-4-6",
  "session_started": 1748793603.456,
  "context": [
    {"role": "assistant", "content": "Now let me search for each session ID..."},
    {"role": "tool", "content": "{...truncated...}"}
  ]
}

[
  {"session_id": "cron_[sid_A]_20260501_1600"},  // 16:00 cron check-in
  {"session_id": "cron_[sid_B]_20260501_2330"},  // 23:30 EOD wrap-up
  {"session_id": "[earlier_investigation_sid]"}              // earlier session_search investigation
]

{
  "success": true,
  "mode": "fast",
  "query": "[q1 topic keywords]",
  "results": [
    {
      "session_id": "cron_[sid_A]_20260501_1600",
      "when": "May 01, 2026 at 04:00 PM",
      "source": "cron",
      "model": "claude-opus-4-6",
      "matched_role": "assistant",
      "title": null,
      "snippet": "...[q1] [topic] [keywords] Task Created\\nThe user's **#1 priority for May 1, 2026** was established as a specific scoping task from the data pipeline:\\n- **Session ID:** `[q1-topic-sid]`\\n- **Goal:** apply a targeted transform to [topic] data...",
      "context": [
        {"role": "assistant", "content": "Now let me search for each session ID to find what was worked on today."},
        {"role": "tool", "content": "{\"success\": true, \"query\": \"[q1-topic-sid]\", \"results\": [{\"session_id\": \"cron_[sid_C]_20260501_1100\", \"when\": \"May 01, 2026 at 11:00 AM\", \"source\": \"cron\", \"model\": \"claude-opus-4-6\",...[trimmed]"},
        {"role": "tool", "content": "{\"success\": true, \"query\": \"session-search-investigation\", \"results\": [{\"session_id\": \"[earlier_investigation_sid]\", \"when\": \"April 23, 2026 at 10:34 AM\", \"source\": \"tui\", \"model\": \"claude-opus-4-6\", \"summ...[trimmed]"}
      ],
      "summary": "[Search hit — summary not generated in fast mode] Use snippet/context fields, or set mode='summary' for LLM-generated recall."
    }
  ],
  "count": 3, "sessions_searched": 3,
  "message": "Fast search returned FTS snippets without LLM summarization."
}

You are reviewing a past conversation transcript to help recall what happened.
Summarize the conversation with a focus on the search topic. Include:
1. What the user asked about or wanted to accomplish
2. What actions were taken and what the outcomes were
3. Key decisions, solutions found, or conclusions reached
4. Any specific commands, files, URLs, or technical details that were important
5. Anything left unresolved or notable

Be thorough but concise. Preserve specific details (commands, paths, error messages)
that would be useful to recall. Write in past tense as a factual recap.

Search topic: [q1 topic keywords]
Session source: cron
Session date: May 01, 2026 at 04:00 PM

CONVERSATION TRANSCRIPT:
{the ~100K-char truncated transcript from step 5S}

Summarize this conversation with focus on: [q1 topic keywords]

{
  "success": true,
  "mode": "summary",
  "query": "[q1 topic keywords]",
  "results": [
    {
      "session_id": "cron_[sid_A]_20260501_1600",
      "when": "May 01, 2026 at 04:00 PM",
      "source": "cron",
      "model": "claude-opus-4-6",
      "summary": "# Conversation Recap: [topic] Progress Check (May 01, 2026, 16:00)\n\n## Context\nAutomated cron check-in reviewing the day's planning doc. [topic] was Item #1 on the agenda.\n\n## Actions Taken\n1. Read the planning doc\n2. Ran `session_search` on the agenda session IDs\n3. Cross-referenced with recent sessions to find post-11:00 activity\n4. Updated the Progress section with a 16:00 entry\n\n## Key Findings\n**Status: \ud83d\udfe1 In progress — recon complete, implementation not started**\n\nThe morning work session (`[work_session_sid]`) progressed substantially beyond the 11:00 snapshot: discovery phase identified the relevant modules and the gaps in existing handling; full-dataset scan results shaped the planned approach… [truncated for length]"
    }
  ],
  "count": 3, "sessions_searched": 3
}

{
  "mode": "guided",
  "session_id": "cron_[sid_A]_20260501_1600",   // copied from fast result 1
  "around_message_id": 12793,                           // copied from fast result 1's match_message_id
  "window": 5
}

{
  "success": true,
  "mode": "guided",
  "session_id": "cron_[sid_A]_20260501_1600",
  "around_message_id": 12793,
  "window": 5,
  "session_meta": {
    "when": "May 01, 2026 at 04:00 PM",
    "source": "cron",
    "model": "claude-opus-4-6",
    "title": null
  },
  "messages": [
    {"id": 12788, "role": "assistant", "content": "...", "tool_calls": [...]},        // before-5
    {"id": 12789, "role": "tool",      "content": "{\"output\": \"20260501\", ...}"}, // before-4: date check
    {"id": 12790, "role": "assistant", "content": "", "tool_calls": [...]},          // before-3
    {"id": 12791, "role": "tool",      "content": "{\"content\": \"     1|# 2026-05-01 — Daily Plan (draft)\\n     2|\\n     3|## Carry-..."},  // before-2: read planning doc
    {"id": 12792, "role": "assistant", "content": "Now let me search for each session ID to find what was worked on today."},  // before-1
    {"id": 12793, "role": "tool",      "content": "{\"success\": true, \"query\": \"[q1-topic-sid]\", \"results\": [{\"session_id\":...}",
     "anchor": true},                                                                  // ← ANCHOR — session_search result for [q1-topic-sid] (the FTS5 match was on the keywords inside this tool result)
    {"id": 12794, "role": "tool",      "content": "{\"success\": true, \"query\": \"session-search-investigation\", \"results\": [...]}"}, // after-1
    {"id": 12795, "role": "tool",      "content": "{\"success\": true, \"query\": \"dashboard-sessions-order\", \"results\": [...]}"},   // after-2
    {"id": 12796, "role": "assistant", "content": "The session searches are mostly returning prior cron check-ins. Let me search fo..."},  // after-3
    {"id": 12797, "role": "tool",      "content": "{\"success\": true, \"query\": \"[topic] [keywords] recon scripts ...}"},  // after-4
    {"id": 12798, "role": "tool",      "content": "{\"success\": true, \"mode\": \"recent\", \"results\": [...]}"}              // after-5
  ],
  "messages_before": 5,
  "messages_after": 5
}

What the user actually sees: replaying the agent's next turn

This section answers a different question from §4. §4 measured how long session_search takes to run (the tool-side latency where the mode choice actually changes the cost). §6 holds tool-side latency aside and asks: given the same JSON the live agent would receive, what answer does the model produce for the user? The replay calls the same auxiliary path session_search itself uses (auxiliary.session_search → auto → main chat model), feeding the JSON from the §4 run as the tool result. Same model, same payload, real LLM tokens.