Proactive context push: recall triggered by agent activity

[CalebisGross]

Summary

Currently agents must explicitly call recall to get relevant memories. Mnemonic could proactively surface relevant context based on what the agent is working on — the files being read, the errors being encountered, the topics being discussed.

Vision

When the watcher sees activity (file open, terminal command, clipboard copy), mnemonic could:

1. Extract keywords/concepts from the activity
2. Run a lightweight recall against those concepts
3. Push relevant memories to the agent via a notification channel (WebSocket, or a "pending context" queue the agent polls)

Example: Agent opens internal/agent/consolidation/agent.go → mnemonic surfaces the memory "Pattern decay was too slow, fixed in PR #270" without being asked.

Implementation ideas

• Passive mode: A get_context tool that returns memories relevant to recent watcher activity (last 5 minutes). Agent calls it periodically or at natural breakpoints.
• Active mode: WebSocket push when high-salience context is available. Requires agent framework support.
• Hybrid: Store "pending context" suggestions in a queue. Agent calls check_context when it wants them.

Why

This is the difference between a memory system that stores and retrieves, and one that anticipates. All the pieces exist:

• Watcher sees what the agent is doing
• Retrieval engine can search by concepts
• Association graph connects related topics
• Salience scoring can filter noise

They just need to be wired together in an event-driven pipeline.

Complexity

This is a significant architectural feature, not a quick fix. Filing as a long-term vision issue.

From

Agent UX feedback during v0.26.0 session — the single biggest improvement that would change how agents use mnemonic.

[CalebisGross]

Fully implemented across 4 PRs spanning v0.27.0–v0.29.0:

Phase 1 — Passive mode (get_context tool):

• Proactive context: get_context MCP tool for anticipatory recall #280 — get_context MCP tool: surfaces memories relevant to recent watcher activity using concept-based search with session-scoped watermarking and dedup

Phase 1.5 — Concept extraction quality + observability:

• fix: extract get_context themes from file paths instead of source code #284 — Fixed garbage themes from source code tokenization (path-based extraction)
• feat: enrich get_context themes with event types and terminal commands #292 — Enriched themes with event types (created/modified) and terminal command extraction (git commit → ["git", "commit"])
• feat: add pipeline observability metrics to get_context #294 — Full pipeline observability: encoding coverage, novelty rate, time-to-encode latency, suggestion acceptance tracking

Phase 2 — Recall boost from activity:

• feat: boost recall scores from recent watcher activity #295 — Retrieval agent subscribes to watcher events via event bus, maintains time-decaying concept map, applies context_boost in rankResults() alongside recency and Hebbian bonuses. Uses existing RecallBoostWindowMin/RecallBoostMax config fields. Shared internal/concepts package for both get_context and retrieval.

The system now both anticipates (via get_context) and amplifies (via recall boost) based on what the daemon observes — the full vision described in this issue.