What a scheduled agent actually is.

From sitting-down-with-an-agent to commissioning one CORE

Everything you did in Modules 3, 4, and 5 happened when you were there. You opened a session. You typed a prompt. You waited. You read what came back. You approved a diff or reviewed a draft. When the session ended, the agent was done.

A scheduled agent is a different shape. You tell the agent — once — what job to do. You tell the computer when to do it and how often. After that, you walk away. A while later, the agent runs, does the work, and leaves you something to read. You find the artifact the next morning, or on the commute home, or in a folder on Friday afternoon. The session you imagined happening with the agent already happened without you.

Three concrete examples of the shape:

• At 6:30 every weekday morning, before you wake up, an agent reads yesterday’s messages in your agent-access label, glances at today’s calendar, and writes a one-page morning brief into a file called brief-2026-04-22.md. You read it at breakfast.
• Every Sunday at 6:00 PM, an agent walks through your commits for the past seven days, reads the week’s research file, and writes a weekly report into week-2026-17.md. You review it at the start of your planning block on Monday.
• Every four hours during the day, an agent checks a narrow research query you cared about — a specific court ruling, a specific legislative bill, a specific product announcement — and writes a single line into watchers/ruling-v-patel.log if anything new surfaced. Most runs write nothing. One run in twenty writes something that makes you stop what you’re doing.

In each case, the agent does the same four moves you saw in earlier modules — read, categorize, draft, review — except the student is not there for the first three. The agent reads, categorizes, and drafts on its own. The student joins the loop at review, hours or days later. That is what scheduled means.

There are two things scheduled agents are not. First, they are not cron jobs with a prompt bolted on. A cron job runs a command at a time; a scheduled agent is a cron trigger plus a capable model plus tools plus a prompt plus an output contract plus an idempotency key plus a budget plus a review date. The scheduler is one part of the system. Second, they are not autonomous agents in the always-on sense — they do not make long-running decisions, they do not reach out to other humans unprompted, and they do not, in this course, send anything to anyone but you. They wake up, do one bounded job, deliver to you, and sleep. The boundedness is the feature.

What's a “scheduler”? The Cowork tab, plus cron, launchd, and Task Scheduler CORE

The word scheduler appears all over Module 6. A scheduler is just a program whose job is to run other programs at specific times. Four schedulers matter for this module — one chat-shaped (Module 6's home base), three traditional. Knowing the shape of each before the recipes hit lets you choose well.

• The Cowork tab's scheduled tasks — the chat-shaped scheduler in the Claude desktop app, and the home base for this module. You set up a task in conversation, name a schedule in plain English (“daily at 6:30 AM”), and the Cowork tab handles the rest — including running on schedule even when your local machine is asleep, in many configurations. No syntax to memorize, no sleep-and-wake debugging, and the agent's prompt and the schedule live together in one place.
• Cron is the Unix-tradition scheduler, available on macOS and Linux. You configure it with a single text file (the crontab) where each line says “at this time, run this command.” Cron is reliable, scriptable, and has been around for decades. It also has notoriously cryptic syntax, opens vi by default for editing (an old keyboard-only text editor that traps new users — even quitting it requires a memorized command), and does not run jobs while your machine is asleep — three real friction points for a self-paced student. Pairs with the Claude Code CLI in this module's Optional Advanced path.
• launchd is Apple's modern replacement for cron on macOS. It uses .plist (property list) XML config files and handles sleep-and-wake gracefully — if your laptop was asleep when a job was supposed to fire, launchd runs it on next wake. Better choice than cron on a laptop that closes nightly. The syntax is more verbose but the recipes ship templates you fill in. Optional Advanced.
• Windows Task Scheduler is Windows's built-in equivalent — a graphical app you open from the Start menu. You configure tasks through a wizard with three concepts: Trigger (when), Action (what), and Conditions (extras). Friendlier UI than cron, slightly more clicks than launchd. Optional Advanced.

The five moves: plan, trigger, run, deliver, log CORE

In Module 5 you learned the four moves of an email/calendar agent: read, categorize, draft, review. A scheduled task adds a wrapper around those four moves so they can happen without you. The wrapper has five moves of its own.

Plan. You decide, once, what the task is, what scope it runs against, what artifact it produces, where the artifact lives, who reads the artifact, what the task costs, when you will review it, and what event would cause you to retire it. You write this into the automation register. Plan is entirely yours. The agent is not a participant here.

Trigger. The scheduler fires the task. It happens at 6:30 AM, or when a watcher’s condition is met, or when you run an on-demand command. The scheduler is a dumb but reliable clock; its job is to wake the agent up on time, not to decide whether the task should run.

Run. The agent, woken up, executes the plan. It reads the right scope, categorizes, drafts the artifact. This is the part that looks most like the work you did in Modules 4 and 5. The difference is that the agent is running against your pre-written prompt, not your live chat — every run of a scheduled task gets the same starting instructions, which is a feature and occasionally a trap. If the prompt is bad, it is bad reliably every day; we will return to this in Lesson 6.5.

Deliver. The agent writes the artifact to the destination you named in the plan. A file on disk. A draft in your drafts folder. An email to your own address. A row in a private log. In Module 6, delivery targets you only — we will say more about why in the next block.

Log. Every run — successful, failed, or no-op — writes a line to a log. Timestamp, task name, status, artifact path (if any), cost, any error. Logs are how you keep trust with an automation you stopped looking at. Lesson 6.4 and 6.5 return to logs as the minimum viable observability; you do not skip them.

Notice the split. The agent owns run. Everything else is yours or the scheduler’s. Plan is a one-time design move by you. Trigger is the scheduler’s job. Deliver is the agent’s, but only to a target you specified in the plan. Log is the agent’s, following a convention you set. This matters because in production, the part that fails is almost never the agent’s part — it is the plan that was vague, the trigger that was wrong, or the log the student stopped reading. If you can name which of the five moves is broken, the fix is usually quick. If you cannot, you will spend much longer re-prompting an agent that was fine.

Audience = only you: the Module 6 extension of drafts-not-sends CORE

Module 5 installed drafts, not sends. The rule was: the agent writes, a human reviews and sends. A student following that rule in a synchronous session is fine — they read every draft within minutes, they click Send themselves, and the relational rail holds.

A scheduled task complicates the rule in a specific way. Imagine the morning brief we described. If it emails itself to you, you wake up to a useful summary and review on your own time. If instead the task emails the same brief to your teacher, you have crossed a bright line: the teacher read a piece of writing that came from your account without you ever seeing it. No matter how polite the brief is, no matter how accurate — the teacher was the audience for something you did not write and did not review. That is not “drafts, not sends.” That is a send, dressed up in automation.

The Module 6 rule is: audience = only you. Every scheduled task in this module — every morning brief, every weekly report, every research refresh, every watcher, every student-designed task — delivers to the student and to no other human. The delivery targets this module accepts are:

• A file on the student’s own machine (common default).
• A draft in the student’s own drafts folder, which the student reviews and sends themselves if they want to.
• An email to the student’s own email address, which the student reads like any other message.
• A row in a log file on the student’s own machine.
• A message in a private Slack or Discord channel only the student is in.

The delivery targets this module does not accept are: an email, DM, SMS, or post to anyone but the student; an auto-reply, auto-RSVP, auto-accept, or auto-decline that another human will see; a post to a shared channel, family group, class forum, or teacher mailbox; a calendar event that lands on someone else’s calendar without a human-click confirmation.

This is not a carve-out policy. It is a uniform rule. You do not “just” auto-RSVP for routine meetings. You do not “just” auto-post to the family calendar. The reason the rule is uniform is the same reason drafts, not sends was uniform in Module 5: carve-outs metastasize. A student who starts with “I’ll auto-post to the family calendar because everyone wants the events anyway” ends up, six weeks later, with an automation that accepts meetings they would have declined and a relationship with a family member who thinks the student no longer cares. The rule exists before the temptation to make an exception exists.

What you gain from the rule: an enormous, well-scoped playground. Audience = only you still lets you build a morning brief, a weekly report, a research refresh, a watcher, a cost dashboard, a reading-list aggregator, a practice-problem generator, a study-schedule reconciler — dozens of high-leverage recurring tasks. You do not need to reach other humans to get an enormous amount of value from automation. The rule narrows the set; the set is still large. What you lose from the rule: the ability to build autonomous outbound pipelines. That capability will be available to you when you finish this course; it is not available to you in Module 6. That trade is the module’s intentional design, not an oversight.

Idempotency: the rail that fails most often CORE

Idempotency is a one-word concept with a big payoff. A task is idempotent when running it twice produces the same result as running it once. If your morning-brief task runs at 6:30 AM and the machine is sleepy and the scheduler fires it a second time at 6:32, an idempotent task produces one brief — the second run notices “today’s brief already exists” and either overwrites it or exits cleanly. A non-idempotent task produces two briefs. Or three. Or ships two copies of something outbound, which is the Module 5 nightmare scenario reproduced at scheduler scale.

Most student automations break here, and almost always in the same way: the student does not design an idempotency key, and so the task has no way to know whether it already ran. The fix is a quick habit taught once.

The habit: every scheduled task has a stable key, and every artifact it produces is named from that key. Concrete examples from this module:

• Morning brief — key is the date. File name: brief-2026-04-22.md. A re-run for 2026-04-22 overwrites the same file; one day, one artifact, ever.
• Weekly report — key is the year and ISO week number. File name: week-2026-17.md. A re-run for week 17 overwrites.
• Research refresh — key is the query ID you chose when you designed it. File name: research/q-supreme-court-patel/run-2026-04-22T0800.md, with a latest.md symlink the reader opens. Two runs in the same interval overwrite the later file in the query’s folder; diffs against latest.md are computed from content hashes.
• Watcher — key is the event ID the watcher has decided to track. A watcher that has already fired for event e-42 does not fire again for e-42, no matter how many times it runs.

If you cannot name the key for a task you are about to build, you are not done designing it. The Module 6 register has a required Idempotency key column for exactly this reason. In Lesson 6.5, the retirement ritual asks you to audit every entry in your register for an idempotency key that is actually stable, not just claimed.

One more reason idempotency matters for scheduled tasks specifically: schedulers fire twice sometimes. Cron can double-fire when a laptop wakes up from sleep. Cowork scheduled tasks can re-run a failed task with the same intent. Your retry logic — or your scheduler’s — will occasionally run the same task twice. The right response is not to eliminate double-firing (impossible) but to make it harmless. That is what idempotency buys.

The automation register: the habit this module lives inside CORE

The safety norms of Module 6 are not good intentions. They are columns on a table. You write the table once — the automation register — and every scheduled task you run during the module (and after it) has one row there. If a task is not on the register, it is not allowed to run. If a row’s next review date is in the past, that task is paused until you audit it.

The register has these columns. The worksheet in the automation-register row template spells out the full template; this is the summary:

• Task name. Three-to-five-word description. “Morning brief.” “Week-of report.” “Watcher — Patel ruling.” Unique in your register.
• Purpose. One sentence. What question this task answers for you.
• Schedule. The trigger. “Daily 06:30 local.” “Sundays 18:00 local.” “Every 4h, 07:00–23:00.”
• Scope / credentials. What the agent can read and write, and with what credentials. The narrowest scope the task actually needs.
• Idempotency key. The stable identifier the artifact is named from. Date. Week. Query ID. Event ID.
• Artifact path. Where the output lives. A specific file or folder on the student’s own machine or account.
• Audience. In Module 6 this column reads “me” for every row. If it does not, the row is not allowed.
• Cost ceiling. Dollars per run and dollars per month. See the budget-and-review discussion in Lesson 6.5.
• Last run / last success. The most recent trigger date and the most recent date the task produced an artifact you read and found useful.
• Next review. A date no more than 90 days from today. The task pauses when this date passes.
• Retirement trigger. One sentence describing the event that would make this task not worth running anymore.

Every row you add during Module 6 fills in every column. A row with missing columns is not a row; it is a note. That sounds pedantic in Lesson 6.1. By Lesson 6.5 you will see why it is not.