Scheduled work in Hermes: Did the agent run, or did the job finish?

At nine in the morning, an agent writes a report. The scheduler shows the run as complete. Later, someone opens the report and finds yesterday’s version. The agent produced the text, but the push to the repository failed. From the scheduler’s perspective, a run happened; from the team’s perspective, the work is still missing. The hard part of putting agents on a schedule is not getting them to wake up on time. It is proving that the intended result reached its destination.

Hermes Agent is an open source agent runtime from Nous Research. It supports tool using agents across terminal and messaging surfaces, with profiles, skills, sessions and scheduled jobs. It provides the layer that connects a model’s answer to reading files, writing artifacts and calling external systems. Earlier articles in this series discussed the runtime and its organizational uses. This one looks at a narrower operational question: when can a recurring job reasonably be called finished?

What actually starts on schedule?

Hermes supports recurring and one time cron jobs. A job can carry relevant skills and deliver its result to a configured destination. One detail in the documentation matters more than the clock expression: each scheduled job runs in a fresh agent session. It does not simply pick up yesterday’s conversation. That helps make the starting context predictable, but it also means yesterday’s local decision is not automatically today’s instruction.

Imagine an editorial team publishing a different technical article each day. If the prompt only says “write the next article,” a new session must infer where the series stopped. It could inspect earlier files, but that guess becomes fragile when someone revises an older article or when publication succeeds while the tracking record fails. The series position belongs in an explicit state file. The new session reads it first, works on exactly the indicated topic and advances it only after delivery is confirmed. Persistent memory can carry preferences and procedures. A concrete sequence of completed transactions needs a separate record that can be inspected and reconciled.

Three kinds of success

There are at least three distinct events in a scheduled agent task. The agent runs: it starts a session, calls tools and creates an output. The output is delivered: a repository or API accepts a write. The target reflects the outcome: the intended version appears where the team expects it. Collapsing all three into a single success label makes it difficult to diagnose what broke.

In a blog workflow, writing a local file proves only the first part. Link checks and a site build add confidence that the file can be incorporated into the project. A successful Git push demonstrates delivery to the source repository. It does not, by itself, prove that the public site has updated. An automated deployment still has to finish. The status report should distinguish “file created,” “repository updated” and “page visible on the live site.” If nobody has checked the last event, it should not be reported as complete.

The same reasoning applies outside publishing. If an agent creates a support ticket, an HTTP response may not be enough; a read of the exact ticket ID can confirm the target record exists. If it compiles an inventory summary, finding a file is less informative than checking which reporting period the file actually covers. A harness orchestrates tool calls. The team must decide what evidence counts as a finished task.

What happens on a second run?

Scheduled work happens in unreliable environments. A connection drops. Someone else updates the repository while the agent is writing. One step succeeds and the next fails. Retrying without a plan can publish the same article twice or create duplicate support records. A repeatable job therefore checks whether today’s result already exists before it creates anything new.

For an editorial workflow, the order might be: fetch the current remote branch; read the series state; check today’s completion record and proposed filename; stop if the work is already complete. If the file exists but the state has not moved, do not skip to a second topic. Record the mismatch and reconcile it. For a genuinely new article, run validations, commit only files owned by this job and push. Finally, compare the local commit with the remote branch. This is not elaborate prompt writing. It is the contract that makes a run safe to repeat.

The point at which state changes matters. Advancing the topic before delivery can cause a failed article to disappear from the sequence. Delivering the article but failing to deliver the state record creates a different inconsistency. In either case, reporting “done” hides work that still needs attention. A useful error record says which step completed and which step did not. On the next run, the agent can investigate the incomplete step without generating a second article on the same subject. An execution log is not a substitute for delivery, but it makes incomplete delivery discoverable.

Profiles are not a substitute for permissions

Hermes profiles provide separate homes for configuration, sessions, memory and scheduled jobs. An editorial agent and a support agent can run without blending their contexts or schedules. This is helpful for accountability, but naming a profile does not itself restrict the permissions granted by an external service. Repository write access, production credentials and API scopes must still be limited at their sources.

For a first deployment, choose a low risk task that can be reversed. Write down its inputs, output location, acceptance check and failure message. Then deliberately try a bad condition. If a network request fails, what does the second run do? If validation fails, does the state remain unchanged? These tests teach more than a demonstration where the agent writes attractive prose once. In routine operations, trust is built by a system’s behavior when something goes wrong.

Hermes determines when an agent runs, what tools it can use and how the session is organized. Who owns the work and who may accept it remain organizational questions. To make that layer explicit, agentic-organization offers a self-hosted, file-based platform for managing AI agents as first-class members of the organizational chart.