Alerts and watchers.

What a watcher is and what it is not CORE

A brief runs every day whether there is news or not. A report runs every week whether there is news or not. A watcher is different: a watcher runs on a schedule (say, every four hours), but it produces output only when a specific condition is met. The other nineteen runs a day do nothing — a log line, maybe, but no artifact, no alert, nothing for you to read.

The shape makes watchers feel like an always-on background sensor. They are not always-on — they run on a discrete interval — but they behave, from your perspective, like a quiet listener that taps you on the shoulder only when something specific happens.

Examples of watchers the course recommends as realistic first builds:

• An email from a specific person (a teacher, an employer, a college admissions office) arrives in your bounded label — fire once, write a one-line alert, flag the thread.
• A keyword you are tracking (a specific court ruling name, a product announcement, a competition deadline) appears in the scheduled research refresh’s output — fire once.
• A deadline in the Agent Access calendar crosses a threshold (72 hours away, 24 hours away) — fire once at each threshold.
• A cost threshold you set — a daily or weekly ceiling on total automation spend — is crossed. (This is a meta-watcher that watches your own automations.)

Two things watchers are not, and confusing them is the typical first-build mistake:

• Watchers are not live, push-triggered notifications. A webhook or push API that fires the moment a new email arrives is a different architecture and not what Module 6 teaches. Module 6 watchers run on an interval — every four hours, every hour, twice a day — and are accepted to be a little late. The interval is the tradeoff; pick one that matches how fast you actually need to know.
• Watchers are not alert clouds. A watcher that fires 30 times a day because its condition is loose is not a watcher; it is noise. The alert fatigue failure mode (Block 2) retires most watchers that don’t last; Module 6 installs the rails to avoid it.

The three failure modes and the tradeoff between them CORE

Every watcher fails in three specific ways. Naming them lets you know which one you’re at risk of on the watcher you’re about to build.

• False positives. The watcher fires when nothing that warranted firing happened. A cousin emails; the watcher (scoped too loosely) fires because their last name matches part of a tracked keyword. You read the alert, find it’s nothing, and the watcher’s credibility erodes one drop.
• False negatives. The watcher fails to fire when something that did warrant firing happened. The teacher emails from a different address than the one the watcher’s condition named; the watcher saw nothing; you missed the email.
• Alert fatigue. The watcher fires accurately but too often, and you stop reading the alerts. This is the most common long-term failure mode of watchers, because it is not a bug — the watcher is doing what you told it to — and is only visible from your own behavior.

The tradeoff: you cannot minimize all three. Every real watcher lives somewhere on a triangle between tolerates false positives (alerts a lot, catches everything), tolerates false negatives (alerts rarely, misses some), and tolerates fatigue (alerts at the right level, but over time wears down). Module 6’s recommendation is to bias toward false negatives for most first builds — a watcher that misses three things in a year but never wastes your attention is more useful than one that fires daily, because your capacity to keep reading is the binding constraint.

This bias is contextual. For a college admissions email you cannot miss, bias the other way — tolerate more false positives so the real one is certain to be caught. The module teaches the bias as a conscious choice per watcher, not a universal default, and the worksheet /resources/module-06/watcher-design.md asks you to state the bias for your watcher in one sentence.

Condition, threshold, and the anatomy of a good watcher CORE

A watcher’s prompt has a different shape than a brief or report. The core of the prompt is the condition-and-threshold statement — a single paragraph that says exactly when to fire. A good condition-and-threshold statement has four parts:

• The event. Concretely: “An email from <named sender> at <named address> lands in my agent-access/school label.” Not “a message from my teacher” — the teacher’s actual email address. Not “anything school-related” — a specific label. Specificity is the difference between a watcher and a mailing list.
• The qualifier. The extra conditions the event must satisfy to fire. “Only if the subject line does not start with [newsletter].” “Only if the message is not a calendar invite.” “Only if the body is longer than two sentences (auto-acknowledgements do not count).”
• The threshold. What changed meaningfully since the last run. For keyword watchers: the keyword appears in the new research-refresh output but did not appear in the prior one. For deadline watchers: the time-until-deadline has crossed one of the bands (72h, 24h). Without a threshold, a watcher can fire repeatedly on the same underlying event.
• The non-event. What explicitly does not fire. “If the teacher’s auto-responder reply appears, do not fire.” “If the keyword is a substring of an unrelated phrase (‘patel’ appearing in an email about a student named Patel unrelated to the court case), do not fire.” Naming non-events in the prompt reduces false positives in exactly the places the agent would otherwise err toward yes.

The watcher’s quiet-run behavior is the other half of the prompt. On any run where the condition is not met, the watcher writes one line to its log file — date, run ID, “no trigger, [N sources checked]” — and exits. No artifact file. No draft. The log line is the evidence the watcher ran; the absence of an artifact is the evidence nothing fired. A watcher that writes nothing on quiet runs is indistinguishable from a watcher that is broken, which means after a week you have no idea which one you have.

The watcher’s firing behavior is: exactly one artifact file per unique event, named from a stable event ID (not the run timestamp — two runs that both detect the same event must not produce two artifacts). The event ID can be the email’s message-ID, the calendar event’s UID, or a content-hash of the triggering content. The worksheet details the options per watcher type.

The response test: what will you do when it fires? CORE

The test that decides whether a watcher is worth building — before you build it, not after — is: what specific action will you take when this watcher fires?

If you can name the action (“I’ll open the teacher’s thread within 30 minutes and draft a reply”), the watcher has a reason to exist. If the action is vague (“I’ll see what’s up”), the watcher is a curiosity, not an alert, and will become noise within three weeks. If there is no action — “I just want to know” — the watcher is worse than noise; it is a demand on your attention with no return.

The response test is the module’s answer to the watcher-as-hobby failure mode — students who build watchers because watchers are fun, not because the watcher earns its place. The test is strict on purpose: a watcher without a named action is retired before it is built.

One softer version of the test, for watchers on long-running topics: the action may be “add to a list I review on Fridays.” That is a real action — it routes the signal somewhere you actually will process it. But “I’ll read the alert” is not an action; reading is not routing.

Apply the test every time you design a watcher, and apply it again in Lesson 6.5’s retirement ritual. A watcher that fires four times in two months but produced no student action in any of those four firings has failed the response test retroactively. Retire it.

Watcher-specific audit: the “last fire” column CORE

The automation register has columns for last run and last success. Watchers need one more: last fire. A watcher’s “last run” is any time the scheduler fired the task; “last success” is the last time the watcher produced output you read; “last fire” is the last time the watcher’s condition was met.

The three columns separate three distinct failure modes:

• Last run is old. The scheduler stopped firing the watcher. The task is broken; fix the scheduler.
• Last run is current but last fire is old. The watcher is running but has not triggered in a long time. This is either the watcher is well-scoped and the world has been quiet (fine) or the watcher has drifted into irrelevance (retirement candidate). Compare to the retirement trigger.
• Last fire is current but last success is old. The watcher is firing, but you have not read the alerts. This is the alert fatigue signal. Either the alerts are too noisy or the response action is not happening. Either way, the watcher needs redesign or retirement before it fires again.

Only watchers need this third column, and only watchers need the extra scrutiny. Briefs and reports fire whether or not there is news; their “last run” and “last success” tell you what you need to know. Watchers’ asymmetric output — nothing most of the time, something occasionally — requires the third column to tell the three failure modes apart.