Context

With #370 landed, memory recall now only runs at turn boundaries (not on every tool-loop iteration). This is correct — the recall query is based on the last user message, which doesn't change between tool iterations, so re-querying produces identical results.

Future Enhancement

There may be value in tool-result-aware recall: incorporating tool results into the recall query so that mid-loop iterations could surface different, more relevant memories based on what the tools discovered.

Example scenario:

1. User asks "what should we do about the database?"
2. Turn-start recall surfaces general DB preference memories
3. Tool call discovers the issue is specifically about PostgreSQL replication
4. A re-query incorporating "PostgreSQL replication" context could surface more targeted memories (e.g., the user's PostgreSQL version preferences, prior replication decisions)

Current Behavior

The recall query always uses _state.FindLastUserMessage()?.Content, which is the raw user message. Tool results are not factored into the query.

Design Considerations

• Would require a new recall query strategy that extracts key terms from tool results
• Could use a lightweight extraction (keyword-based) or LLM-based query reformulation
• Should be opt-in / configurable to avoid adding latency to tool loops that don't benefit
• The exclusion-based progressive recall from perf(memory): stop re-injecting same memories on every tool loop iteration #370 would still apply — tool-aware re-queries would exclude already-injected memories

Related

• perf(memory): stop re-injecting same memories on every tool loop iteration #370 — memory recall deduplication (prerequisite)
• design: semantic skill discovery via description embedding instead of keyword extraction #355 — semantic skill discovery (similar pattern of context-aware retrieval)