What cron means in Hermes

In ordinary applications, cron means “run something later.”
In Hermes, cron means:

• persist a job
• wake a fresh agent session
• execute it safely
• store output
• optionally deliver the result back to a user surface

That is a much richer idea.

Job objects are durable state

Hermes stores jobs in JSON, but the important part is conceptual:

• jobs have identity
• schedules are parsed into structure
• repeat counts are tracked
• delivery targets are remembered
• output is persisted separately from delivery

That makes a cron job a real stateful object, not a transient callback.

The isolation boundary is excellent

When Hermes runs a cron job, it launches a fresh agent session with special restrictions:

• cron toolset disabled
• messaging toolset disabled
• clarify disabled
• context files skipped
• memory skipped

This is the right boundary for unattended execution.

It prevents:

• recursive self-scheduling
• uncontrolled direct messaging
• question-asking in a context with no user present
• contamination of user memory from scheduled system tasks

At-most-once is a deliberate tradeoff

For recurring jobs, Hermes advances the next scheduled run before execution begins.
That means a crash can cause a missed run, but it prevents repeated replay on restart.

For side-effecting autonomous jobs, that is usually the correct trade:

• duplicate execution can spam users or mutate state repeatedly
• missing one run is often safer

This is a concrete example of Hermes choosing operational safety over theoretical completeness.

Pre-run script + wake gate is a powerful pattern

Hermes can run a pre-script and use it as a wake gate:

• if nothing interesting happened, skip the agent call
• if something changed, pass that data into the prompt

This reduces:

• cost
• noise
• unnecessary autonomous runs

That small feature is one of the best examples of “agent systems need pre-LLM control logic too.”

Output and delivery are not the same thing

Hermes always tries to save output artifacts, even if nothing is delivered.
It also supports a [SILENT] convention so successful jobs can opt out of user-facing notification.

This is a sign of a thoughtful autonomy system:

• execution should be auditable
• delivery should be selective

Those two concerns should not be fused.

The larger lesson

Cron in Hermes is really a compact autonomous execution stack built from:

• durable jobs
• isolated runs
• scheduling semantics
• safe delivery policy
• auditability

That is the difference between “timer support” and “autonomous runtime design.”