Blog
AI Agent Cron Automation: The Two-Stage Brief
Stop polling. Schedule AI agents that reason overnight and deliver fast at dawn. The two-stage cron pattern, self-terminating jobs, and silent-when-healthy rules.
The best scheduled agent I run does its hardest thinking at 6am while I am asleep, then hands me a tight brief at 7am that costs almost nothing to produce. That split โ expensive reasoning overnight, cheap delivery at wake-up โ is the single most useful pattern in AI agent cron automation, and it is the one most people miss. They cram everything into one job that fires at 7am, watches me wait, and burns a premium model to do work it could have done hours earlier.
This piece is about scheduling agents that actually earn their keep: the two-stage brief, self-terminating monitors, timezone-proof jobs, and the rule that keeps a fleet of crons from turning into spam. Real commands, real tradeoffs.
Reasoning is expensive, delivery is cheap
Hold onto that sentence. It explains the whole design.
When an LLM synthesizes weeks of context โ your conversation history, meeting notes, prior logs โ that is the costly part. Reading a file and formatting it nicely is not. So separate them. Do the synthesis when no one is waiting and you can use a cheaper model without anyone noticing latency. Do the delivery fast, from a pre-computed file, on a model picked for speed.
That is the "dreaming" pattern. Two crons, one file between them:
- 6am job (cheap model). Reads everything โ chat history, notes, logs โ and writes 3 prioritized recommendations plus 1 non-negotiable to
~/.hermes/dream.md. - 7am job (fast model). Reads
dream.md, adds today's weather and calendar, delivers the brief.
# Stage 1: the overnight "dream" โ heavy reasoning, cheap model
hermes cron create "0 6 * * *" \
"Synthesize 3 recommendations and 1 non-negotiable for my day from all
context, recent sessions, and meeting notes. Write to ~/.hermes/dream.md." \
--name dream-precompute
# Stage 2: the morning brief โ fast delivery, reads the file
hermes cron create "0 7 * * *" \
"Read ~/.hermes/dream.md, add today's weather and calendar,
and deliver my morning brief to Telegram." \
--name morning-brief --deliver
The pre-computed file is the asset. Any later job, on any model, can read it. Once you see the world this way you start using it everywhere a delivered artifact needs deep upstream reasoning: a weekly report that thinks on Saturday and sends on Monday, a standup summary that digests overnight and posts at 9.
A quick note on syntax, because shipping a broken command is worse than shipping none: hermes cron create takes the schedule first and the prompt second as positional arguments, not --schedule/--prompt flags. Run hermes cron create --help once and confirm before you paste anything into production.
Webhooks for events, cron for time
Before you schedule anything, ask whether time is actually your trigger. A lot of "checking" jobs should not be cron jobs at all.
If you want to know when a new customer signs up, do not poll the API every ten minutes. That is a job for a webhook โ the event wakes the agent. Cron is for things that genuinely happen on a clock: the morning brief, the nightly backup, the weekly digest. Use the right one and you stop paying for a thousand "nothing happened" checks a day.
A clean rule of thumb: if the trigger is "a thing occurred," reach for a webhook. If the trigger is "it is now this time," reach for cron.
Self-terminating monitors
Sometimes you do want frequent polling, but only for a while. A video just dropped and you want to answer comments for the first day. A deploy is going out and you want eyes on errors for the next few hours.
You can manage that lifecycle in plain language:
hermes cron create "*/10 * * * *" \
"Check my YouTube video [URL] for new comments and reply in my voice
using the transcript. After 24 hours from now, delete this cron." \
--name yt-launch-watch --repeat
The agent runs every ten minutes and kills its own job when the window closes. No orphaned cron quietly polling a week later because you forgot it existed. This is the cleanest way to do burst monitoring without leaving litter in your schedule.
Make crons timezone-proof
A fixed UTC time looks fine until daylight saving shifts and your "midnight" backup fires at 11pm or 1am. The portable fix is an hourly self-check instead of a hardcoded hour:
hermes cron create "0 * * * *" \
"If the current time in America/Chicago is midnight, push my .hermes
folder to GitHub (token in .env as GITHUB_TOKEN, git identity hermes-bot).
Otherwise do nothing and stay silent." \
--name nightly-backup --repeat
It runs every hour, checks local time, and acts once a day at the right local moment regardless of DST. Costs you 23 cheap no-op checks; saves you a backup that drifts twice a year. For backups specifically, push only *.md files or just the skills/ folder rather than the whole directory โ the full .hermes/ can run 60MB+ and choke on size limits.
Silent when healthy
This is the rule that decides whether your fleet is a helper or a nuisance: a scheduled job that finds nothing wrong should say nothing.
If the backup succeeded, you do not need a message. If there were no new subscribers this hour, stay quiet. The only time a monitor pings you is when something needs you. Bake it into the prompt โ "post to Telegram only if there were subscribers" โ and your phone goes quiet until it matters. A fleet that reports every successful run trains you to ignore it, which defeats the point.
Become the approver, not the author
The highest-leverage crons turn you from the person doing the work into the person signing off on it.
The classic pair: one job, twice a day, drafts replies to unread email. A second job at 8am delivers a prioritized brief โ high-priority messages with deep links, your calendar, anything you flagged. You wake up to drafts and a plan, not an empty inbox and a blank page. You read, you approve, you send.
Two guardrails make this safe. First, draft only โ never let a scheduled job send email, post, deploy, or spend on its own. Put every outbound action behind a human gate. As Jack Roberts put it, "I would never let them run riot." Second, budget the tokens. Do not run a heavy triage job every ten minutes. Twice a day is plenty, and your bill will thank you. If cost is a real constraint, see optimizing agent runs.
Don't re-do work you already did
One failure mode bites every scheduled scraper or sync: the job that re-processes everything on every run. A daily content refresh that re-uploads the entire corpus instead of just the new items will quietly 10x your costs and your storage.
Always tell the job to skip what it has already handled. "Scrape new videos since the last run; if a video is already in the store, do not re-upsert." A small dedup guard in the prompt is the difference between a daily job that adds a few items and one that re-uploads thousands. For multi-step scheduled pipelines, this is also where multi-agent orchestration and a durable board help โ the board already knows what got done.
FAQ
What is AI agent cron automation?
It is scheduling an AI agent to run on a recurring clock โ daily, hourly, or in bursts โ to do work like briefings, backups, monitoring, or report generation without you triggering each run by hand.How is a cron job different from a webhook for AI agents?
Cron fires on a schedule (it is now 7am). A webhook fires on an event (a customer just signed up). Use cron for time-based work and webhooks for event-driven work so you are not polling for things that should push to you.How do I stop a recurring agent job from spamming me?
Adopt a silent-when-healthy rule: instruct the job to message you only when something needs attention. A successful backup or an empty check should produce no notification.Can a scheduled AI agent send emails or deploy code on its own?
It can, but you should not let it. Keep scheduled jobs draft-only and put every outbound action โ send, post, deploy, spend โ behind a human approval gate.Skip the trial and error
Getting these crons right took a lot of people a lot of broken jobs โ UTC drift, runaway monitors, duplicate uploads, triage bills that surprised them. OpenClawCrew starter kits ship the two-stage brief, self-terminating monitors, timezone-proof backups, and the silent-when-healthy approval pattern as real files you drop into Hermes or OpenClaw and adjust. Get the $49 starter kit to wire your own schedule, or book a done-for-you setup and wake up to a working brief tomorrow.
Related reading: AI agent webhooks, multi-agent orchestration, agent memory that compounds, and personal ops automation.