The setup takes four minutes. Knowing what to put on a schedule is the actual skill.
Lightning LessonClaude Cowork
Dr. Aki Wijesundara · TAI Labs
Type in chat: the one thing you do every week that you are sick of doing. I am building one of yours live in ten minutes.
Session30
minutes One filter. One live build.
Two things in the first 45 seconds. One, the naming: in Cowork it is called Scheduled tasks, not Routines. The desktop Routines button is a different product with different docs. Three things carry scheduling names right now and everyone is confused, so say it once plainly and the room relaxes. Two, run the chat prompt properly and read answers out loud by name, because you are sourcing the live build from this and you need real material. Backup if chat is thin: a Monday competitor check writing to a dated file.
01
Part 1: The filter
What Belongs on a Schedule
Anyone can find the New task button. The expensive mistake is scheduling the wrong thing, because it fails quietly and you keep filing the output.
01
Would you hand it to a new starter with a checklist?
02
Can it be wrong for a week and survive?
03
Does the input change on a clock?
04
Is the manual version already clean?
Automation multiplies whatever you already have. Most people hear that as a promise. It is a warning.
The one sentence behind each question, say these as you go: (1) If it needs your judgment, taste or relationships, it is a task you run and review, not a schedule. (2) Nothing that touches sensitive files, sends messages for you, makes purchases, or is hard to undo. (3) If the real trigger is an event, you will run it when nothing changed or miss the thing that did. (4) A schedule does not fix a process, it repeats it on time, forever, broken parts included.
This is the slide the signup page actually sold, so give it the time. Take two or three answers from chat and run them through the four questions out loud. Half will fail and saying exactly why is the lesson. The one that passes cleanly becomes your live build, say so on air. Question 3 is the one people argue with, so have the example ready: "tell me when a contract is signed" is an event, not a schedule, and a daily timer gives you 364 useless runs and one late one. Question 2 is Anthropic's own written guidance, quote it as such.
02
Part 2: The mental model
Every Run Is Day One
Not a reminder that goes off. A new person starting your job, who remembers nothing and has never met you.
The only thing that survives between runs is what you wrote down.
03You define what done looks like.A first day hire cannot infer your standard.
Write it for a competent stranger with no context and no memory, because that is exactly what runs it.
The diagram replaces cards 1 and 2. The full line behind each: (1) No "as we discussed", no "the usual format". Write it for someone who has read nothing. (2) To compare against last week it must write last week's result down and read it back. (3) Exact format, exact sources, exact scope. A first day hire cannot infer your standard.
This frame explains every rule in the rest of the session, so land it properly. The contrast worth saying out loud: a reminder tells you to do the work and only needs a time and a label, a scheduled task does the work and needs everything you would give a person on their first day. The state on disk point is what people thank you for later, it is the difference between a tracker that says "here are their prices" every week and one that says "they changed this since Monday". If asked whether it remembers across runs: no, and that is a feature, because a fresh session cannot drift.
03
Part 3: Build it
0:00
Build One, Live
Describe it to Claude, or fill the fields yourself. Either way these are the decisions.
Field
The decision
Name
How you recognise it in a list of twenty
Prompt
The whole job, written for a stranger
Approval
How much you trust it yet. Start manual
Frequency
Hourly, daily, weekly, weekdays, manual
Folder
Where it reads and writes. Scope it narrow
It runs remotely, so it fires with your laptop shut. Unless it needs local files or apps, then the machine must be awake.
Start weekly and go daily later. Reliability is earned per task, never granted per feature.
Presenter reminder: narrate the decisions, not the clicks, then press Run Now before you leave the screen. This slide stays up for the whole build, timer top right. Use the task you picked from chat. Narrate the decisions, not the clicks, the clicks are obvious and the decisions are the content. Do Run Now at the end so they see a real result before you leave the screen, that is what makes the promise true. Read this strong prompt out loud as your model of a good one: "Every Monday open these three URLs, read the pricing page on each, compare against competitor_notes_last_week.md in this folder, write a new dated file listing only what changed with the URL and date beside each claim, and if a page did not load or nothing changed say that at the top instead of writing a normal report, then overwrite competitor_notes_last_week.md with this week's findings." It works because it tells a stranger where to look, what to compare, what to write, and what to do when things go wrong. Contrast with "check our competitors every Monday and tell me what changed".
04
Part 4: Checkpoints
Checkpoints That Surface Problems
A broken run and a quiet week produce the same tidy document.
Approval mode
What happens
Use for
Manually Approve
Pauses and asks before acting
Anything new, anything that writes
Automatically Approve
No pauses, every action safety reviewed
Read mostly tasks you have watched run
Skip All Approvals
No pauses, no safety review
Almost nothing. Never with web access
01
Run Now before you schedule.
Read the execution log, not just the output.
02
Make silence impossible.
If a step failed or nothing changed, say so at the top.
The second one is a single sentence, costs nothing, and decides whether you notice your automation has been broken for a month.
The full line behind each card: (1) Read the execution log, not just the output, then watch the first three to five runs. (2) Put this in the prompt: if a step failed, a source was unreachable, or nothing changed, say so at the top.
Be honest here, it buys the room. The Cowork changelog from the last two months is full of real scheduling bugs: cron using 7 for Sunday never firing, every N days schedules landing on the wrong days, re enabling a task kicking off catch up runs for every missed slot, runs dying behind a VPN after the machine woke. Anthropic has since added automatic retries at 5, 15 and 30 minutes when a run cannot reach the model. Naming one of these is worth more than polish because everyone here has been burned by a cron job. Also worth saying: Automatically Approve uses more of your allowance because of that safety checking, and Skip All Approvals meaningfully raises prompt injection exposure, which is why it is never right for anything reading the open web.
05
Take this with you
The Four Question Test
Ask
If no
Would you hand it to a new starter
Run and review it, do not schedule it
Can it be wrong for a week
Do not schedule it
Does the input change on a clock
You want an event, not a schedule
Is the manual version clean
Fix the process first
Anthropic's own line: do not schedule tasks that access sensitive files, send messages on your behalf, make purchases, or take other actions that are difficult to undo.
Pick one weekly task tonight. Manually Approve, weekly, Run Now once, read the log.
We go deeper in the Claude Code and Cowork certification with TAI Labs. Link in the chat.
Questions
Tell them to screenshot the table. One spoken mention of the course, then straight to questions, no selling. Maven adds every signup to the waitlist and emails the recording in 48 hours, the work is done. Held for Q&A: how Cowork scheduled tasks differ from desktop local routines, slash loop and cloud routines, running against a git repo, chaining tasks, usage cost.