Heartbeats and Crons.
Two ways to make agents wake up on their own. Heartbeats poll on an interval. Crons schedule at fixed times. Most builds use both.
- A working mental model for when to reach for an interval poll versus a fixed schedule, and why production fleets run both side by side.
- A concrete pattern for moving any command (your morning briefing, an inbox triage, a weekly summary) onto a schedule that fires while you sleep.
- The autonomy ladder five rungs from interactive prompting up to multi-agent continuous work, with heartbeats and crons sitting on rung three.
Put one command on a schedule.
Pick a command you already run by hand. Hand it to Claude with the prompt below and it will walk you through wrapping it in a shell script and scheduling it on your computer.
How this fits in the OS.
A slash command that already works when you run it by hand. Your CLAUDE.md from Stage 01, your MCPs from Stage 02, and a secrets manager (Infisical or 1Password) so the scheduled run can sign in without a human at the keyboard.
Built-in scheduling on your computer. Cron on Mac and Linux. Task Scheduler on Windows, pointed at Git Bash. Optionally launchd on Mac or n8n for anything more complex than a fixed time.
The shift from assistant to system. The agent stops waiting for you to ask. It wakes up, does the work, drops the result somewhere you will see it, and goes back to sleep.
The shape of the problem.
Everything you have built so far waits for you. You open a session, you type, the agent responds. That is powerful. But there is a level beyond that: workflows that run on their own, without you doing anything.
This is the difference between an assistant and a system. An assistant waits for you. A system runs while you sleep.
There are two clean ways to wake an agent up on its own. They sound similar and they overlap in practice, but they solve different problems. Most real builds use both.
The two patterns.
Poll on an interval
What it is. A loop that fires every N minutes regardless of the clock. Every 5 minutes, every hour, every 30 seconds. The agent checks something, decides if anything changed, and acts only if it has to.
What it is for. Watching. Reacting to change you do not control. New email landed. Inbox has unread messages older than 48 hours. A build job finished. A file appeared in a folder.
How it thinks. "Anything new since last time? If yes, handle it. If no, go back to sleep."
Schedule at fixed times
What it is. A scheduler that runs a command at specific clock times. 7:30 AM weekdays. Friday at 5 PM. Monday at 9 AM. The five-number pattern minute hour day-of-month month day-of-week tells it when to fire.
What it is for. Reporting. Anything tied to a time of day or week. Morning briefing. Weekly summary. Monday content check. End-of-day journal.
How it thinks. "It is 7:30 AM on a Tuesday. Run the script."
Cron is the Unix scheduler that has been doing this for forty years. On Mac and Linux you edit it with crontab -e. On Windows the equivalent tool is called Task Scheduler. Heartbeat is the architectural name for an interval-polling loop. There is no single tool called "heartbeat," it is a pattern you implement with a shell loop, a launchd plist set to StartInterval, an n8n schedule trigger, or any tool that can fire repeatedly. The point is the shape, not the tool.
When to use which.
The picker is mostly the question "is this tied to a clock, or to a change in the world?"
| Trigger | Use | Why |
|---|---|---|
| "Every weekday at 7:30 AM, give me a brief." | Cron | Tied to a clock. Fires once, predictable, done. |
| "Friday at 5 PM, summarize my week." | Cron | Same as above. Weekly version. |
| "When new email comes in from a client, draft a reply." | Heartbeat | Not tied to a clock. The agent has to keep checking. |
| "Every 5 minutes, check if anything in my fleet failed." | Heartbeat | Watching a system you do not control the rhythm of. |
| "Run a smoke test after every deploy." | Heartbeat | Event-driven. The heartbeat polls for "new deploy." |
| "7 AM brief plus continuous monitoring of overnight failures." | Both | The brief is cron. The monitor is heartbeat. They compose. |
The two patterns answer different questions. Cron answers "what time is it?" Heartbeat answers "what changed?" A real agent operating system needs both. Your morning briefing wants a cron. Your fleet monitor wants a heartbeat. The mistake is trying to force one tool to do both jobs.
The autonomy ladder.
Scheduling is one rung on a five-rung ladder. Knowing which rung you are on tells you what work is left.
- You ask, Claude does. Interactive. You type a request, the agent responds. This is most of what you have done so far.
- You trigger, Claude executes. Command. You type
/morning, the agent runs the full workflow. Still you-initiated. - Scheduled, Claude executes. Automated. Cron or Task Scheduler fires the command. Output gets delivered somewhere you will see it. This is where heartbeats and crons live.
- Event-triggered, Claude executes. Reactive. Something happens (new email, form submission, webhook), an interval-poller or webhook listener detects it, the agent responds. Heartbeats power most of this rung. n8n is the usual tool.
- Multi-agent, continuous. Fully autonomous. Multiple agents working together on ongoing tasks, the agent directing other agents.
Most students move from rung one to rung three in a single afternoon. Rungs four and five are the next frontier, and they are more accessible than they sound once rung three is real.
What this looks like in the workshop.
You do not need a new build to see these patterns. They are already inside two cards you have access to.
The Morning Brief uses a cron. Sources come in, the agent compiles the brief, the short ping goes to a channel, the full write-up lands on a deployed dashboard. The trigger is a single cron line: at 6:30 AM, run the script. The same cron pattern applies to every other daily or weekly automation you ship.
The Multi-Machine Heartbeat uses a heartbeat. A small loop, fires every few minutes, checks every machine in your fleet (your computer, your Mac Mini, your VPS) for failed jobs, stale workflows, or anything that needs human eyes. It is the always-on watcher that crons cannot do, because the questions it answers are not tied to a clock. It answers "did anything break?"
When the agent runs autonomously, you are not there to review each action. Set up any new scheduled workflow in Ask permissions mode first and run it by hand a few times. Verify the output. Only then move it to a schedule. For any autonomous workflow that sends messages or changes real systems, build in a review step: write the output to a file first, review the file, then have a second command actually execute. Over time, as you trust specific workflows, you can remove the review step. Start cautious.
Where to go next.
You have the mental model. The natural next moves: