Hermes Cron Jobs Now Carry Their Previous Output Into Every Run

Recurring Hermes cron jobs run in isolated sessions. Each run starts fresh: the prompt is rebuilt, the previous run's output sits in a file under ~/.hermes/cron/output/<job_id>/, and the agent has no memory of what it reported last time. A monitor that should answer "nothing new" re-reports the same findings every run because it cannot see its own prior output.

PR #80774 adds a continuity=true flag that changes this. When enabled, a cron job's own most recent final report is prepended to the prompt of the next run, so the job can dedupe against what it already reported and continue where it left off.

The mechanism

The feature reuses the existing context_from output-injection pipe instead of adding new storage. context_from already lets a job pull another job's output into its prompt. The new work points that same pipe at the job itself, using the reserved value self.

The scheduler's _build_job_prompt() resolves self (case-insensitive) and the job's own literal 12-hex id to self-context. The previous run's final report, already persisted and truncated to 8,000 characters, is injected with continuity framing that tells the agent to avoid repeating what it already reported and to continue from where the last run left off.

continuity=true is the user-facing surface. Internally it is stored as the reserved self entry in context_from. Setting continuity=false removes self while preserving any other context_from entries.

Why not replay the full history

The feature is modeled on Amp's "Right on Schedule" post from July 21, 2026. Amp describes its scheduled agents this way:

scheduled Amp agents "wake up with their saved prompt and continue right where they left off, with all of their context and history."

Amp achieves continuity by re-entering the same thread, so full context and history persist across wakes. Hermes takes a different path because its cron runs are deliberately isolated: cron deliveries never touch chat history, and prompt-cache and alternation invariants depend on a fresh session. Replaying full session history per run would grow without bound and re-bill the entire transcript on every wake. The adaptation injects only the previous run's final report, already 8K-truncated, into the fresh prompt. No session mutation, no new storage, no prompt-cache impact.

The first run has no previous output, so the injection silently skips and the prompt is unchanged, matching existing context_from semantics.

What changed

Twelve files, +471/-19 lines across four commits.

The core logic is in cron/scheduler.py. tools/cronjob_tools.py extends create/update validation to accept self, which cannot be validated against the store because the job does not exist yet at create time. The flag is exposed across every surface: --continuity / --no-continuity on hermes cron create/edit, a checkbox in the web dashboard, the TUI cron RPC, and the Bot Mode routines.

Validation

The sabotage run stashes the fix and confirms 5 of 6 new tests fail without it; the one pass is the first-run silent skip, which is the vacuous case where no prior output exists to inject. The new test file covers the edges directly: injection of the latest output, use of the most recent output when multiple runs exist, 8,000-character truncation, case-insensitive self, silent skip on first run, own-id equivalence, and tool create/update acceptance.

Getting started

Enable continuity on an existing job:

hermes cron edit <job-id> --continuity

Or set it at create time:

hermes cron create "daily check" ... --continuity

Tool-driven jobs accept the same via continuity=true or context_from: ["self"].

[^1]: Teknium. "feat(cron): continuity=true - cron jobs carry their previous run's output across runs." NousResearch/hermes-agent, PR #80774. Merged 2026-08-17.

[^2]: Amp. "Right on Schedule." ampcode.com. July 21, 2026.