Scheduled Tasks: Cron Without a Terminal

Picking Up From Fundamentals

This track assumes you have completed Hermes Agent Fundamentals -- Hermes is installed, a model provider is configured, and you have SOUL.md, at least one AGENTS.md, and a working memory setup. Everything from here builds on top of that base, starting with the thing that turns your agent from something you talk to into something that works on its own.

Three Ways to Create a Scheduled Job

From inside a chat session:

/cron add 30m "Remind me to check the build"
/cron add "every 2h" "Check server status"

From the command line, outside any session:

hermes cron create "every 2h" "Check server status"
hermes cron create "every 1h" "Summarize new feed items" --skill blogwatcher

Or simply describe what you want in natural conversation -- Hermes can parse intent directly:

Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.

That last example also hints at where this is going: combined with the messaging gateway (next lesson), a scheduled job does not just run quietly in the background, it can actually reach you.

How Schedules Are Written

Hermes accepts four different schedule formats, and picks the right interpretation automatically:

• Relative delays (one-shot) -- 30m, 2h, 1d: runs once, that far in the future
• Intervals (recurring) -- every 30m, every 2h, every 1d: runs repeatedly on that cadence
• Cron expressions -- 0 9 * * * (daily at 9 AM), 0 9 * * 1-5 (weekdays only): standard five-field cron syntax for anyone already comfortable with it
• ISO timestamps -- 2026-03-15T09:00:00: a specific moment in time, one-shot

Managing Jobs Once They Exist

Every management action is available both as a CLI command and a slash command, and both accept a job name in place of its ID, case-insensitively -- you do not need to memorize job IDs to manage your own schedule:

Where Jobs and Their Output Live

Jobs are stored in ~/.hermes/cron/jobs.json. Every run produces output saved to ~/.hermes/cron/output/{job_id}/{timestamp}.md -- a dated record of what each run actually did, which is invaluable for a job you only check on occasionally rather than watch live.

Skill-Backed Jobs

Jobs can be tied to a specific skill (skills are covered in Lesson 4) so the run always uses the same procedure rather than relying on the agent reasoning from scratch each time:

cronjob(action="create", skill="blogwatcher",
        prompt="Check feeds", schedule="0 9 * * *")

This matters for jobs that need to behave the same way every time -- a monitoring check should not subtly change its method run to run just because the model interpreted the prompt slightly differently.

Chaining Jobs Into a Pipeline

One job's output can become the next job's input via context_from, enabling multi-stage pipelines -- one job gathers data, a second job analyzes what the first one produced, without you manually shuttling output between them.

No-Agent Mode and Cost Control

Not every scheduled check needs an LLM in the loop. No-agent mode runs a script directly without invoking the model at all -- useful for watchdogs and simple monitoring where "is this service still up" does not require reasoning.

There is also a finer-grained cost control for pre-run scripts: a script can emit {"wakeAgent": false} to skip waking the full agent when conditions do not warrant it. This matters for frequent polling jobs -- a job that checks something every 5 minutes but only needs the agent involved when something actually changed should not be burning model calls on every single tick.

The next lesson covers what your agent can actually do once it is running -- the full toolset catalog, and a more advanced capability for handling complex multi-step work: sandboxed code execution.