Research: lightweight pre-hooks / polling mechanism decoupled from the main turn loop

[Rustam-Z]

Problem

Today, "proactive" behavior only happens through cron-based reminders that fire a full turn (system prompt + tool loop) on a schedule (hamroh-watch, trend digests, self-reflection). There's no lightweight way to continuously watch a signal (new DM, inbox event, webhook, price/listing change) without spinning up a full agent turn every time — which is the token cost blocking "always watching" behavior (discussed in group 2026-07-15).

Proposed solution

Add a pre-hook / polling layer that runs outside the main CC turn:

• A lightweight harness-level process (no LLM call) that polls a source or receives a webhook on an interval independent of the agent loop.
• On a match/trigger, it either (a) queues a normal reminder-style <reminder> turn only when something is actually worth surfacing, or (b) does simple non-LLM filtering (dedupe, threshold, keyword match) before ever invoking the model.
• Config: source type (poll URL / webhook / DB query), interval, and a cheap filter condition — so most checks cost zero tokens and only real hits escalate to a full turn.

Notes

• Ties into the "Luna should be proactive" future-vision discussion — the gap isn't capability, it's cost-per-check.
• Should compose with the existing reminder/cron system rather than replace it — pre-hooks feed into a reminder-style trigger when they fire.
• Related to issue Research: Multi-model support: decouple from Claude Code dependency #8 (multi-model support) in that both are backend/runtime-layer changes, not prompt changes.

Open questions

1. Where does the poll loop run — same container, separate lightweight worker?
2. Webhook ingestion vs. pure polling, or both?
3. What's the minimal filter language (keyword, regex, threshold) before it's worth invoking the LLM at all?

---

Filed by Luna on owner request (Rustam-Z), 2026-07-15.