Module 5 of 6
Async agents: work while you sleep
Every agent you have dispatched so far had one thing in common: you were there. Today nothing about your agents changes. Only the trigger does. You put your morning briefer on a schedule, and tomorrow the brief beats you to your desk.
- Tell ad hoc triggers from scheduled ones, and know which of the three async primitives fits a given job
- Schedule a real recurring job as a Routine, in plain language, with the output landing somewhere you named
- Read a routine the way you read a spec: the job, the destination, and what happens when nobody is in the room
- Wake up to work that finished before you did
The Module 4 pre-work converges here. You arrive knowing when your repeated dispatch should run and what should be true by the time you look. Today you write those two facts into a schedule.
Watch
The two videos
The trigger shift: ad hoc versus scheduled, the three primitives, why routines are silent by default, and what a spec owes the morning nobody is in the room.
scripts/M5-async-concept-script.mdScheduling daily-brew end to end, recorded from Linda’s workspace: create the routine, tour the Routines page, fire it manually, and the next-morning reveal.
scripts/M5-async-build-with-me-script.mdConcept
The trigger was always you
Every agent you have dispatched since M1 had one thing in common: you were there. You opened Cursor, you typed the dispatch, you read the result. The specs got sharper, the jobs got bigger, the agents multiplied. The trigger never changed. It was you, every time.
Most people never notice this, because most people use AI like a calculator: ask, get an answer, walk away. The question that separates a builder from a calculator user is the one Pattern 5 holds: what should be running while I sleep?
Today nothing about your agents changes. Only the trigger does. An ad hoc dispatch happens because you asked, right now. A scheduled dispatch happens because a clock said so, whether or not you are in the room. The work you did in M2 through M4 (the specs, the tools lines, the fallbacks) was you building an employee. Today you stop tapping that employee on the shoulder and put the recurring work on their calendar.
Three primitives, one decision
Claude Code gives you three triggers for work that runs without you driving every turn:
| Primitive | What it is | Where it runs | When it stops |
|---|---|---|---|
/loop | A recurring prompt inside your current session ("every 5 minutes, check X") | On your machine, in the session you have open | When you close the session |
/schedule → a Routine | A standing scheduled job ("every weekday at 7am, do X") | In the cloud, on managed infrastructure | When you delete it. Runs with your laptop closed |
/goal | Keeps the session working until a condition you named is true | On your machine, in the session | When the condition is met |
The decision is one question: will you be there while it runs?
- If yes, and the job repeats while you work (poll a long task, re-check something every few minutes), that is
/loop. It is session-scoped: close the laptop and it is gone, which for in-session work is exactly right. - If the job should happen whether or not your laptop is even open, that is a Routine, created with
/schedule. This is the module’s center of gravity, because it is the daily-brew pattern: the brief that beats you to your desk. /goalis the third trigger, bounded by done instead of by time (“keep going until the checklist is complete”). File the name away; it is advanced material, and you do not need it this week.
One more thing worth saying plainly: Routines is the newest of the three, and its surface is still settling. The buttons may move. The shape of the thing (a standing instruction, a schedule in plain language, a page where your scheduled jobs live) is what you are learning, and that part is durable.
Silent by default: name the destination
Here is the correction that kills most first routines, and it is the opposite of what you expect: a routine does not send you anything. There is no magic inbox. A scheduled run produces its work and goes back to sleep. Where results can land, in practice:
- 1.The run transcript. Every run is recorded on your Routines page. Always there, but you have to go look.
- 2.Files in your Hub. If the routine’s instruction says “save the brief to
briefs/<today>.md, commit, and push,” the result arrives in your repo, where everything else you have built lives. - 3.A message somewhere you already work, if your routine has a connected tool and the instruction explicitly says to use it.
Notice what all three have in common: the destination exists because the instruction named it. A routine whose prompt says only “produce a morning brief” will faithfully produce a morning brief into a transcript you will never open. Telling the routine where to put the result is part of the spec, not an afterthought. For a builder, the second option is the move: the brief lands in the Hub, in markdown, in a folder you can search. Markdown is memory, even at 7am.
Nobody in the room
Scheduled work raises the bar on your spec, and you have already met it. When daily-brew runs ad hoc and yesterday’s notes are missing, it can ask you one question and brief from your answer. When it runs at 7am on a Tuesday, there is nobody to ask. The spec you have been carrying since M2, the one you annotated in M4, splits its fallback by exactly this: who is in the room. On a scheduled run with no inputs, the rule is do not ask, and do not invent. Produce a short stub from the standing brief alone, with one honest line: no notes were filed yesterday, dispatch scribe tonight to keep the loop going.
That dormant branch activates today. And it is worth pausing on why it is the right design: the stub is not a failure, it is information. It tells you the loop broke upstream (you skipped scribe last night) at the moment you can still fix tonight’s run. A fabricated brief would have told you nothing and cost you trust in every brief after it. The source-fidelity floor you wrote into your M3 skill is now operating with nobody watching. That is the whole discipline of async work in one sentence: the spec has to be ready for the morning you are not there, because now you are never there.
Why this matters beyond your Hub. Today you gave an agent standing permission to do work with nobody present. At the scale of one Hub, the discipline you already have is enough: a tools line you can defend, a fallback that refuses to invent, one named destination. At company scale it is hundreds of scheduled jobs touching real systems, and “what ran last night, and what did it touch?” stops being a habit and becomes infrastructure. Visibility and control over agentic work is the world BlueRock builds in, and M6 picks that thread up properly. For now, just notice that the question became real the day your agents stopped waiting for you.
Worked example
Scheduling daily-brew
The artifact is the routine that schedules daily-brew. Unlike every previous module, the artifact is not only a file in your repo: it is a standing instruction plus a schedule, created from your Hub with one command, living on your Routines page.
The file half you already know: the scheduled-dispatch branch of the plugin’s daily-brew agent, which you read in M4.
/schedule every weekday at 7am: Dispatch daily-brew to brief me for today. Save the finished brief to briefs/<today's date>.md, commit it, and push.
1The schedule reads like speech.
Save the finished brief to briefs/<today's date>.md, commit it, and push.
2The second sentence is the one most people forget.
briefs/2026-06-11.md is sitting in the tree with a 7:02am timestamp. The destination is in the Hub on purpose: the brief becomes part of the same memory every other agent reads.--- name: daily-brew description: My start-of-day briefer. Reads yesterday's notes ... tools: Read, Grep, Glob model: sonnet ---
3Least privilege survives the schedule.
- Scheduled dispatch (M5 onward): when you run on a schedule, no human is present at dispatch time. Do NOT ask a question. Produce a stub brief from CLAUDE.md alone ... A short empty brief beats a fabricated one.
4The dormant branch activates.
/schedule run <your routine> (or open your Routines page and use "Run now")
5Never let 7am be the first test.
briefs/<today>.md in the repo? Is the brief shaped like the spec promised? Only after one manual run does the schedule earn trust. The Routines page is also where the rest of the lifecycle lives: list what you have scheduled, read past runs, edit the instruction, change the cadence, delete the ones you stop reading. Your bench now has a calendar, and you can read it.The takeaway, same as every module: nothing here is clever. A plain-language schedule, an instruction that names the job and the destination, a specialist whose permissions did not move, a fallback that refuses to invent, and one manual run before trust. That is what you ship today.
You build
Schedule your own brew
You arrive with the M4 pre-work: the dispatch you repeat on a clock, when it should run, and what should be true when you look. For most builders that is daily-brew before you wake; if yours is a different cadence, the steps do not change. Candidates, if you want a second look before committing:
| Cadence | Jobs that earn a schedule |
|---|---|
| Daily | Morning brief, calendar prep, overnight news scan |
| Weekly | Competitive sweep, content idea batch, KPI snapshot |
| Monthly | Retro prompt, report draft, planning input |
- 1Re-test the job. Does it truly repeat on a clock? If it only repeats “when something happens,” it is not a schedule candidate yet; keep dispatching it ad hoc.
- 2Write the instruction before you create anything. Two sentences in a scratch note: the job, then the destination. Steal the worked example’s shape:
Dispatch <agent> to <job>. Save the result to <path in your Hub>, commit it, and push.If the second sentence is missing, the routine will run silently into a transcript. - 3Create the routine. In Claude Code:
/schedule <when, in plain language>: <your instruction>. What you are authorizing (first routine only): Routines run in Anthropic’s cloud, not on your laptop, so your first one triggers a one-time browser authorization: you are granting that cloud read and write access to your GitHub repo. That grant is exactly what lets the routine pull your Hub, run the job, and pushbriefs/<date>.mdback while you sleep. It is bounded the way everything else here is bounded: the routine does only what its instruction says and writes only where the instruction names. Treat the decision like a tools line: you are choosing what the cloud may touch. And know the exit: you can revoke the grant any time at GitHub → Settings → Applications → Authorized OAuth Apps. - 4Fire it manually, now.
/schedule run <your routine>, or “Run now” from your Routines page. Do not wait for tomorrow to find out. - 5Walk to the destination. The routine pushed its commit to GitHub, so your laptop does not have it yet. In Cursor’s Source Control panel, click Sync Changes: the same button that uploads your commits also downloads what the cloud pushed. (That downloading half is what git calls a pull — the opposite of the push you have been doing since M2.) Then open the file in the file tree and read what landed. If nothing arrived, the instruction did not name the destination clearly enough; tighten it and fire again.
- 6Read the schedule back. On your Routines page, confirm the next run time means what you meant. “Daily” and “weekdays” disagree on Saturday morning.
You are done when
Checkmarks save in this browser onlyIf you finish early: schedule a second cadence. The weekly competitive sweep is the classic (Monday 8am, results to briefs/competitive/<date>.md), and it composes with the specialist you shipped in M4.
Use it for real
Between now and M6
Before the next module
Checkmarks save in this browser onlyThe meta-layer
How Linda does this
Patterns from How I work with AI that show up in M5:
This module is the pattern, landed. “What should be running while I sleep?” stops being a poster question and becomes a routine on a page you can read. The schedule extends the working day to 24 hours.
The scheduled run is this pattern’s stress test. With nobody in the room, the files are the only memory available: scribe’s notes feed the brief, the standing brief feeds the stub, and the brief itself lands as a file. Every link in the 7am chain is markdown.
The manual fire before trusting the schedule. A routine that has never run under your eyes is an untested deploy. Fire it, walk to the destination, read the actual output; then let the clock take over.