Brain Watches

Content monitoring used to live on reservoirs — a keyword list and a bare relevance threshold, disconnected from anything that actually describes what you care about. Brain watches move monitoring onto the brain instead. A watch is scored against the brain's own description, aliases, and compiled knowledge map, with its own keywords as an additional signal rather than the only one. A hit that clears the threshold lands in the brain's Triage lane as a pending note, never merged straight into the compile.

Watch types

• keyword — searches HackerNews, Reddit, and YouTube (configurable per watch via platforms) for a set of keywords, mirroring the sources reservoir monitoring covers today.
• rss_feed — reads an existing RSS feed (rss_feed_id) already polled by the RSS cron, instead of re-fetching it.

Both are scored the same way once candidates are found: the brain's description, aliases, and compiled-note excerpt are the primary signal; the watch's own keywords add a secondary signal on top. A hit below min_relevance (default 0.7) is dropped before it ever reaches Triage.

The brain-term match saturates at 3 distinct terms — matching 3 or more words from the brain's own description/aliases/compiled excerpt scores the full brain signal (0.7), the same as the default threshold. For a brain with a short, specific description this is a tight filter; for one with a long compiled excerpt covering a broad topic, 3 incidental word matches (a common word like "data" or "using") can be enough on their own to clear the default. If a watch is producing hits that feel too loose, raise min_relevance via update_brain_watch rather than tightening the brain's own description.

Managing watches

• get_brain_watches — brain_id. Lists every watch on a brain, including disabled ones, with last_run_at and last_hit_count from the most recent run.
• create_brain_watch — brain_id, source_type (keyword or rss_feed), plus the fields for that type (keywords for keyword; rss_feed_id for rss_feed), and optionally platforms, subreddits, exclude_youtube_shorts, min_relevance, enabled.
• update_brain_watch — brain_id, watch_id, and any field above except source_type or rss_feed_id. Both are fixed at creation; to point a watch at a different feed or switch it between keyword and rss_feed, delete it and create a new one.
• delete_brain_watch — brain_id, watch_id. Does not affect hits already written to Triage.

create_brain_watch({ brain_id: "<uuid>", source_type: "keyword", keywords: ["kombucha", "fermentation"] })
get_brain_watches({ brain_id: "<uuid>" })
update_brain_watch({ brain_id: "<uuid>", watch_id: "<uuid>", min_relevance: 0.6 })

get_brain also surfaces a brain's enabled watches and the latest watches_last_run_at directly, so an agent doesn't need to call get_brain_watches speculatively just to see whether anything is configured.

How a watch runs

The brain-watches cron runs every enabled watch on a schedule (every 6 hours, the same cadence as the existing content-monitoring cron). For each candidate it finds, it scores relevance against the owning brain and writes anything that clears min_relevance into that brain's Triage lane with full lineage (source_type, url, the watch id, and the relevance score) — the same shape Brain Triage Lane already documents. The same URL is never ingested twice into the same brain.

Relationship to reservoir monitoring

Content Monitoring (reservoir keywords, HackerNews/Reddit/YouTube) keeps running exactly as before — brain watches are additive, not a replacement, until reservoirs are fully retired. If you're setting up monitoring for the first time, point it at a brain instead of a reservoir: the brain is where the knowledge actually accumulates.

Related

• Brain Triage Lane: where watch hits land, and how to promote or dismiss them.
• Content Monitoring: the reservoir-based monitoring this is replacing over time.