Words about scheduled agents
- Scheduled agent
- An agent with a pre-written prompt, tools, an idempotency key, a budget, and a delivery target, fired on a schedule by a trigger you designed. Different from a synchronous chat (you sit there) and from an always-on autonomous agent (running continuously). The student designs once, then walks away; the agent runs without you.
- The five moves
- Every scheduled task runs through plan (you design it once), trigger (the scheduler fires it), run (the agent executes the plan), deliver (the agent writes the artifact to a place you specified), log (every run writes a line). Plan is yours; trigger is the scheduler's; run and deliver are the agent's; log is a habit both enforce.
- Audience = only you
- The Module 6 extension of drafts, not sends. Every scheduled task in this module delivers to you and only you — files on your machine, drafts in your own drafts folder, email to your own address, lines in your own log. No auto-outbound to other humans, no auto-RSVPs, no auto-posts to shared channels. Uniform; no carve-outs in this module.
- Automation register
- A table where every scheduled task you run has a row. Columns: task name, purpose, schedule, scope/credentials, idempotency key, artifact path, audience, cost ceiling, last run, last success, next review, retirement trigger, prompt-change log. If a task is not on the register, it is not allowed to run. If a task's next review date passes, the task pauses until you audit it.
- Prompt-change log
- A small column (or section per row) where you record every change you make to a scheduled task's prompt — one line per change, dated, with a one-sentence reason. Defends against prompt drift, where a student tweaks a prompt repeatedly over weeks and ends up with a prompt that bears no relation to what they started with.
Schedulers
- Scheduler
- A program whose job is to run other programs at specific times. Four matter for this module: the Cowork tab's scheduled tasks (primary, chat-shaped) plus cron, launchd, and Windows Task Scheduler (Optional Advanced, scriptable). The Cowork tab is recommended for first builds; the others are scriptable but require comfort with shell and editor mechanics.
- Cron
- The Unix-tradition scheduler on macOS and Linux. Configured with a crontab file where each line is a five-position time expression plus a command. Reliable and ubiquitous; does not run jobs while your machine is asleep; opens vi by default for editing (set EDITOR=nano first if vi is unfamiliar).
- Crontab
- The file cron reads to know what to run. Edit yours with crontab -e. Each line is one job: minute hour day-of-month month day-of-week command. Star (*) means "every." Example: 30 6 * * * = every day at 6:30 AM.
- launchd
- Apple's modern replacement for cron on macOS. Uses .plist (property list) XML config files in ~/Library/LaunchAgents/. Handles sleep-and-wake gracefully — if your laptop was asleep when a job should have fired, launchd runs it on next wake. Better than cron on a laptop that closes nightly.
- plist file
- Apple's XML config format for launchd jobs. Each plist describes one job: a label, the program to run, and when to run it. The recipes ship complete plist templates; you fill in three or four fields and run launchctl load <file>.
- Windows Task Scheduler
- Windows's built-in graphical scheduler. Open from the Start menu. Three concepts per task: Trigger (when), Action (what), Conditions (extras like "only when AC powered"). The "Create Basic Task" wizard is the friendliest first build path.
- Cowork tab's scheduled tasks
- The chat-shaped scheduler in the Claude desktop app's Cowork tab — Module 6's home base. You set up a task in conversation and name a schedule in plain English; the Cowork tab remembers the prompt, fires on schedule (in many configurations even when your local machine is asleep, because the agent runs in a hosted cloud VM), and keeps a per-run history. Recommended as the first-build path because there's no syntax to memorize and no sleep-and-wake debugging.
Words about idempotency
- Idempotency
- Running a task twice produces the same result as running it once. The rail that fails most often in student automations. Achieved by naming every artifact from a stable key — date, week, query ID, event ID — so a re-run overwrites the same file (or exits cleanly) instead of producing two.
- Idempotency key
- The stable identifier an artifact is named from. Date for a daily task (brief-2026-04-22.md). ISO week for a weekly task (week-2026-17.md). Query ID + timestamp for a refresh (run-2026-04-22T0800.md). Event ID for a watcher (fires/<message-id>.md). If you cannot name the key, you are not done designing the task.
- ISO week
- A standard week-numbering system. ISO week 17 of 2026 is the week of April 20–26. Used for weekly-task filenames because the same week number is reported by every tool — calendars, git logs, date commands — making the filename portable. Computed via date -d 'last sunday' '+%G-%V' (Linux), date -v-sun +%G-%V (macOS), or Get-Date -UFormat "%G-%V" (Windows PowerShell).
Words about specific scheduled tasks
- Morning brief
- A daily artifact (typically brief-YYYY-MM-DD.md) that summarizes inbox and calendar in five sections: header, three things that want your attention, inbox summary, calendar preview, health footer. Read quickly at breakfast. Lesson 6.2.
- Weekly report
- A weekly synthesis-and-accountability artifact (week-YYYY-WW.md) answering three questions a daily brief cannot: what shipped, what didn't ship, what changed in the topic world. Inputs: commit history, capstone-folder changes, and the latest research-refresh diff. Lesson 6.3.
- Scheduled research refresh
- A Module-4-style research query re-run on an interval, reporting only the delta from the prior run. Each run's content is also copied to latest.md so the next run can compute the diff. Lesson 6.3.
- Diff contract
- The paragraph in a research-refresh prompt that defines "meaningful change" — what to include, what to exclude, what counts as "new." Without it, refreshes either over-report (every URL the agent found) or fabricate change to justify the run.
- Zero-state behavior
- What a scheduled task does when its expected work is empty — no new emails, no meaningful research changes, no events fired. The honest behavior is "produce the artifact anyway with empty sections, and say so." Defense against a task that fabricates content to fill space.
- Watcher
- A scheduled task that runs on an interval but produces output only when a specific condition is met. Most runs do nothing — just a log line. Examples: alert when an email from a named sender arrives; alert when a tracked keyword appears in research; alert when a deadline crosses 72 hours.
- Condition-and-threshold statement
- The watcher prompt's core paragraph defining when to fire. Four parts: event (what specifically counts), qualifier (extra conditions), threshold (what changed since last run), non-event (what does not count, even though it might look like it does).
- Quiet-run behavior
- What a watcher does when its condition is not met. Standard: write one log line ("ISO timestamp, task name, no-trigger, N sources checked") and exit without producing any artifact file. Distinguishes a working-but-quiet watcher from a broken one.
- Response test
- The pre-build filter for watchers: what specific action will you take when this fires? If you cannot name a real action, the watcher fails the test and is retired before it is built. "I'll see what's up" is not an action.
- Last-fire column
- A register column that exists only for watchers. Tracks the last time the condition was met (not the last time the scheduler ran or the last time the student read an alert). Together with last run and last success, distinguishes three failure modes: broken scheduler, quiet condition, alert fatigue.
Words about reliability and cost
- Observability minimum
- The three things every scheduled task must produce so you can audit it later: a log line per run (success, no-trigger, or error), an artifact header (run timestamp, task name, idempotency key, what was searched, cost), and a next-run expectation (so you can notice when a run is missing). Skipping these is what makes automations feel unreliable six weeks in.
- Failure mode hierarchy
- How a scheduled task should behave when something goes wrong. Transient failures (network blip, rate limit) → retry once with backoff. Input failures (scope deleted, credentials revoked) → fail loud, do not retry. Output failures (wrong shape) → write to an .attempt.md path, do not overwrite the last good artifact. Catastrophic failures (credentials revoked permanently, model deprecated) → stop the task entirely, pause until human audit.
- Cost as a rate
- A scheduled task's cost is per-run × runs per month, accruing forever until retired. A $3/month task costs $360 over ten years. The register's per-task ceiling and monthly review force the math to happen before the bill arrives, not after.
- Ceiling breach
- A retirement signal: the task's monthly cost crossed the ceiling you wrote. Pause, audit (data volume? model upgrade? prompt growth?), then resume or retire.
- Attention bankruptcy
- A retirement signal: the aggregate demand on your review time exceeds what you actually have. Even if every individual task is fine, too many tasks together is a problem. If the total automation suite demands more review time than the budget you wrote into your Automation Posture, retire the lowest-leverage task.
Retirement vocabulary
- Retirement trigger
- A column in every register row: a one-sentence description of the named event that would make this task no longer worth running. "The court case is decided." "I have not opened the brief in two weeks." "The competition season ends." Specific, not vague — vague retirement triggers drift forever.
- The five retirement signals
- Reasons a scheduled task should retire: 1. Named event — the task's retirement trigger fired. 2. Stale last-success — the task is running but the student has stopped reading the output. 3. Silent drift — artifacts no longer answer the original question. 4. Ceiling breach — monthly cost exceeded the ceiling. 5. Attention bankruptcy — the aggregate review load is too much.
- Retirement ritual
- The three-step process for retiring a task: (1) disable the scheduler entry, (2) revoke the credentials the task was using, (3) archive the task's folder to ~/ai-architect-academy/automation/retired/<task-name>-YYYY-MM-DD/ and update the register row to Retired
with a one-sentence post-mortem. Skipping the credential-revocation step is the most common mistake. - Revocation ritual extended
- Module 5's revocation ritual (revoke after one-off, reduce after recurring, re-audit on a cadence) applied specifically to schedule-bound credentials. When a scheduled task retires, the OAuth token / API key / MCP permission it held does not get to outlive it — that's the zombie credential Module 9 will deepen the threat model around.
Shell and scheduler syntax
- crontab -e
- The command to edit your crontab. Opens the editor named by your EDITOR environment variable. Default is vi; set EDITOR=nano first if you don't want vi.
- vi exit commands
- To save and quit: press Esc, type :wq, press Enter. To quit without saving: Esc, :q!, Enter.
- &&
- Shell short-circuit AND. cmd1 && cmd2 runs cmd2 only if cmd1 succeeded.
- >>
- Append output to a file. cmd >> log.txt appends cmd's output to log.txt instead of overwriting it.
- 2>&1
- Redirect stderr (stream 2) to wherever stdout (stream 1) is going. Combined with >> log.txt, the effect is "send both normal output and errors to log.txt."
- TZ= prefix
- Pins a command to a specific time zone, regardless of the machine's local time zone. TZ=America/New_York date prints the current time in New York. Used in cron lines so traveling across time zones doesn't shift fire times.
- Shebang line (#!)
- The first line of a shell script — #!/bin/bash — that tells the OS which interpreter to use. Required if you want the script to run via ./run.sh after chmod +x run.sh.
- chmod +x <file>
- Make a script file executable. Required once per script, on Mac/Linux.