Your 9am briefing job told you the same three items again this morning — just like yesterday, and the day before. Not because it’s dumb: every run started from zero, with no idea what it already told you, so a job that watched a page and reported changes kept re-reporting the whole history. Scheduled jobs were goldfish. v0.21.0 fixes the memory side of that story: cron agents now load and update persistent memory like every other agent, a new --continuity flag injects each run’s own previous output into the next run, every job gets a durable notepad you can read and write from the CLI, and monitor-mode jobs can skip the LLM entirely when nothing changed.

What changed, in three parts

1. Memory is loaded, not ignored. Cron agents now read MEMORY.md / USER.md into the system prompt and can update persistent memory across runs — the same mechanism interactive agents use. A job that learns something one day actually knows it the next.

2. --continuity carries the last run forward. The scheduler injects the job’s own previous output into the new run’s prompt: “use it for continuity — avoid repeating what was already reported.” That’s exactly what a monitor needs to dedupe. Add it at creation or flip it later:

hermes cron create --schedule "0 9 * * *" \
  --prompt "Summarize new activity on the status page" \
  --continuity
hermes cron edit <job_id> --continuity     # or --no-continuity to turn it off

The first run is unchanged; from the second run on, the job wakes up knowing what it said last time. The help text sums up the use cases: scouts, monitors, incremental digests.

3. A notepad the job — and you — can read and write. Every job gets a durable key-value scratchpad:

hermes cron notepad <job_id> list
hermes cron notepad <job_id> set last_sync "2026-09-01"
hermes cron notepad <job_id> get last_sync
hermes cron notepad <job_id> delete last_sync

The notepad content is injected into the job prompt on each run, so the agent itself can update its own state between runs — a checkpoint of what it has already processed, without the memory system’s semantics getting in the way.

Monitor mode: no change, no LLM bill

The companion piece is monitor-mode refinement: jobs watching a script or URL for changes use hash-suppressed change detection, and when nothing changed the job can skip the LLM entirely — no tokens burned to report “still the same.” It’s the difference between a watchdog that costs a few cents per check and one that costs nothing until something actually moves.

Supporting upgrades around the edges

The window also shipped practical neighbors: pre-dispatch config validation (a broken job fails before it fires, not during), acked failure signatures (acknowledge an incident once and the job stops re-pinging you about it), per-job reasoning-effort pinning (--reasoning-effort none|low|medium|… overrides the global setting for just that job), and “Trigger now” executes immediately instead of queueing. Combined with the cron doctor health checks from the same window, scheduled jobs went from “set and hope” to a system that remembers, dedupes, and tells you when it’s broken.

Putting it together

A realistic pattern: a nightly job watches a competitor’s changelog page with --monitor-url, keeps its notepad with the last-seen commit, and runs with --continuity — so it only reports genuinely new items, and if it misses a run, the next run still knows what it last saw. For the rest of the cron surface — schedules, delivery, script-only jobs — our cron automation guide has the full tour, and the monitor + notepad deep dive covers the preflight mechanics.