Cron Jobs: Scheduled Agent Runs

The first time you ask Hermes to run a task on a schedule, you will probably type it by hand. You will open a terminal, write hermes chat -q "check disk usage and report anything above 80%", and think "I should do this every morning." Then Monday comes around and you forget. A week later a disk fills up at 3 AM on a Saturday and nobody notices until Monday morning. That is the problem cron jobs solve: Hermes runs the check whether you remember or not.

What you'll learn

• hermes cron create registers a recurring agent run on any schedule from "every 30 minutes" to a full cron expression
• Every cron job can override the default model, attach specific skills, run in script mode, and chain output into the next job
• Invariants like the 3-minute hard interrupt and tick lock prevent runaway jobs from piling up on each other
• The full lifecycle, create, list, edit, pause, resume, run (ad-hoc), remove, and status, is managed through hermes cron subcommands

The problem

You have tasks that need to run on a cadence. A database backup every night. A disk space report every hour. A weekly summary of GitHub activity for the team. Without cron, you either remember to run them (and you will forget) or you set up a system cron job that calls a script that calls Hermes, two layers of indirection to debug when something breaks. Hermes's built-in cron system collapses that stack: the schedule, the agent run, and the delivery mechanism live in one place.

Options & when to use each

Approach	Good for	Costs you	When to pick it
hermes cron	Agent tasks with context awareness, skills, and multi-platform delivery	Runs inside the Hermes process; depends on the daemon being up	Almost all recurring agent tasks, reports, health checks, reminders
System cron (crontab -e) calling hermes chat -q	Lightweight, zero-dependency triggers	No skill attachment, no context chaining, no unified management	Quick one-liners that do not need agent state
External scheduler (GitHub Actions, Airflow, CI/CD)	Pipelines that integrate with existing infrastructure	Two systems to monitor, Hermes seen as just another step	When the trigger lives in a platform you already pay for

For anything where the agent's memory, skills, or model selection matters, use hermes cron. For a fire-and-forget command that happens to run through Hermes, system cron is fine.

Build it

Step 1: Create a simple cron job

The most common pattern: a recurring health check. The schedule syntax accepts human-readable durations, cron expressions, and ISO timestamps.

# Every 2 hours, check disk usage on the root partition
hermes cron create disk-check \
  --schedule "every 2h" \
  --prompt "Check disk usage on /. If usage is above 80%, list the 5 largest directories and estimate what is safe to clean up. Report the result."

The --schedule flag accepts:

Schedule format	Example	Meaning
Duration shorthand	30m, every 2h, every 6h	Runs at that interval from job creation time
Cron expression	0 9 * * *	Standard crontab syntax , 9 AM every day
ISO timestamp	2026-07-22T08:00:00	Runs once at that exact time

Step 2: Attach skills and override the model

A cron job gets the default model unless you tell it otherwise. For a job that generates images, you might want a specific model. For a job that needs database knowledge, you might want a skill attached.

hermes cron create weekly-report \
  --schedule "0 9 * * 1" \
  --model "anthropic/claude-sonnet-4" \
  --skills "postgresql-inspection,report-generation" \
  --prompt "Query the last week of activity from the database tables listed in the postgresql-inspection skill. Generate a summary report. If any error rate exceeds 5%, flag it prominently."

The --skills flag takes a comma-separated list of skill names. Hermes loads them before the job runs, the same way interactive sessions do.

Step 3: Script mode and context chaining

Some cron jobs do not need an agent at all, they run a fixed script. Set no_agent=true (script mode) and Hermes executes the prompt as a command rather than sending it to a model.

hermes cron create db-backup \
  --schedule "0 2 * * *" \
  --no_agent \
  --prompt "pg_dump -U hermes -d ops_db > /backups/ops_db_$(date +%Y%m%d).sql"

Context chaining passes the output of one cron job into the prompt of the next. If the disk check job finds a problem, the cleanup job runs with the disk check's findings as context.

hermes cron create disk-cleanup \
  --schedule "every 4h" \
  --context_from "disk-check" \
  --prompt "Review the output from the disk-check job. If it identified safe-to-clean directories, rotate or delete the files it flagged."

The --context_from value is the name of another cron job. Its most recent output is injected into the new job's prompt.

Step 4: Set a working directory

Cron jobs inherit the working directory of the Hermes daemon unless you specify one. For jobs that need a project root:

hermes cron create lint-project \
  --schedule "every 6h" \
  --workdir "/home/molsen/projects/my-app" \
  --prompt "Run the linter on the entire project. Report any new warnings or errors that were not present in the last run."

Step 5: Manage the job lifecycle

Use the cron subcommands to manage your scheduled tasks. You can list, inspect, edit, pause, or remove jobs as needed.

# List all cron jobs with their status
hermes cron list

# Show details for a specific job
hermes cron status disk-check

# Edit a job (opens the job definition in your editor)
hermes cron edit disk-check

# Pause a job without deleting it
hermes cron pause disk-check

# Resume a paused job
hermes cron resume disk-check

# Run a job immediately (ad-hoc, outside its schedule)
hermes cron run disk-check

# Remove a job permanently
hermes cron remove disk-check

Step 6: Multi-platform delivery

Cron job output can be delivered through channels configured in the Gateway (Day 3). If the Gateway is connected to Telegram and Discord, the job result arrives on both.

hermes cron create morning-brief \
  --schedule "0 8 * * *" \
  --channels "telegram,discord" \
  --prompt "Summarize overnight system events: any alerts, failed jobs, or unusual patterns. Keep it under 200 words."

What goes wrong

Mistake	How you notice it	The fix
Two instances of the same job overlap	The job runs longer than its interval and a second instance starts before the first finishes	Hermes has a tick lock: the second tick is skipped. Check hermes cron status <job> , if you see skipped ticks, increase the interval or reduce the job's runtime
A job hangs and never completes	The job shows as "running" for far longer than expected, blocking subsequent ticks	The 3-minute hard interrupt kills any cron job that exceeds the limit. If a job legitimately needs more time, split it into smaller jobs or use delegation
A cron job with a skill fails silently because the skill got renamed	hermes cron status shows "failed" with a missing-skill error, but no notification went out	Run hermes cron edit <job> and update the skill name. Check hermes skills to verify the skill still exists under the name you used
--context_from references a job that has not run yet	The chained job receives an empty context and either fails or produces a generic result	Run the source job manually first: hermes cron run <source-job>. Chained jobs should have a fallback prompt that handles empty context gracefully
Memory pollution across runs	Each cron run appends to the same session memory by default, and over weeks the context fills with stale artifacts	Use skip_memory=true on the job to prevent it from persisting to the session database. For jobs that want memory but not indefinitely, set a retention policy in config.yaml

Confirm it worked

Verify your cron setup by creating a test job and checking its execution. Ensure that the scheduled run triggers properly and produces the expected output.

# 1. Create a test job that runs every 5 minutes
hermes cron create mem-test \
  --schedule "5m" \
  --prompt "Report the current memory usage of the three largest processes on the system. Output the PID, command name, and RSS in MB."

# 2. Wait for the first tick, then check the job's last run
hermes cron status mem-test

# 3. Verify the output exists
# The status output shows the last run time, exit code, and a snippet of the result.
# If the exit code is 0 and the snippet shows actual process data, cron is working.

# 4. Run it manually to confirm the prompt works
hermes cron run mem-test

# 5. Clean up
hermes cron remove mem-test

If the manual run returns a list of processes with memory figures, and the scheduled tick shows the same quality of output when it fires, cron jobs are working.

Next: Subagent Delegation , farming out parallel work to child agents inside a single run.