Build a Cron-to-Approval Loop with Hermes Agent

Scheduled agents are useful when they produce concrete work on a predictable cadence: draft a report, inspect logs, check a repository, summarize new issues, or prepare a pull request. They become risky when they publish, merge, delete, or notify without a review step. A small approval loop keeps the automation useful without turning it into an unattended decision-maker.

This recipe uses Hermes Agent cron jobs, messaging delivery, skills, and plain-text commands to make that loop explicit. The goal is simple: the agent creates an artifact, sends a reviewer enough context to decide, then stops. Approval, rejection, and revision stay human-controlled.

Hermes cron approval loop — Cron trigger creates a verified artifact, delivers it for review, and waits for a human approve, reject, or revise command.

When to use this pattern

Use a cron-to-approval loop when the task is repetitive but the final action has taste, risk, or business context.

Good fits:

content drafts for a static site or newsletter
weekly engineering health reports
repository hygiene checks with suggested fixes
dependency update summaries
incident-review drafts from logs and tickets
customer-support trend summaries

Poor fits:

tasks that need live conversation at every step
production changes where rollback is unclear
jobs that cannot verify their own output
jobs where every run should be silent unless a threshold fires

A useful rule: let the agent prepare work; require a person to accept consequences.

Workflow shape

Stage	Agent responsibility	Human responsibility
Trigger	Start from cron schedule and task prompt	Define cadence and scope
Build	Use tools, skills, and sources to produce artifact	None during run
Verify	Check files, links, commands, or tests	Trust only reported evidence
Deliver	Send concise approval packet	Read and decide
Decide	Wait for command	Approve, reject, or request revision

The most important line in the prompt is not the schedule. It is the stopping condition. Say exactly what the agent may produce, what it must verify, and what it must not do.

Minimal prompt template

Use a prompt that names paths, evidence, and approval commands. Avoid vague requests like “keep the site updated.”

Create one Markdown draft for the site.
Do not publish. Do not modify cron jobs.
Avoid duplicate slugs in content/posts, content/drafts, and content/rejected.
Save the draft under content/drafts/YYYY-MM-DD-slug.md.
Run the site helper list command after writing.
Final response must include slug, title, summary, preview, sources, artifact path, and approval commands.
If there is nothing new to report, respond exactly [SILENT].

That prompt gives the agent a bounded job. It also gives the reviewer a bounded decision: approve this artifact, reject it, or ask for a revision.

Approval message anatomy

A good approval packet is short enough to read on a phone and detailed enough to audit later.

Include:

Draft ID or artifact ID so commands target the right object.
Slug or stable identifier for lookup.
Title and summary for fast triage.
Preview of the first few paragraphs.
Sources for factual claims.
Verification evidence such as test output, helper output, or file paths.
Exact commands the reviewer can send back.

Example command set:

approve agents draft hermes-cron-approval-loop
reject agents draft hermes-cron-approval-loop
show agents draft hermes-cron-approval-loop
revise agents draft hermes-cron-approval-loop: tighten intro and add one example

Exact commands reduce ambiguity. They also make the approval system easier to route through chat, email, or another gateway.

Use skills for repeatability

Hermes Agent skills are reusable procedures the agent can load during a run. For approval-gated work, a skill should capture the boring details: frontmatter shape, site paths, validation commands, notification format, and known pitfalls. That keeps each cron prompt smaller and makes future runs more consistent.

A good skill for this workflow includes:

trigger conditions: when the skill applies
required directory checks before writing
artifact naming convention
validation command sequence
approval message template
pitfalls such as “do not call the sender directly when cron delivery handles output”

Skills should not hide accountability. The final approval packet still needs concrete evidence from the current run.

Practical safeguards

Add these guardrails to the job prompt or skill:

No silent side effects: “Do not publish, deploy, merge, delete, or modify cron jobs.”
Duplicate checks first: inspect existing artifacts before choosing a slug.
Source-backed claims: include official URLs when describing product behavior.
Verification before delivery: run helper commands or tests after writing.
One artifact per run: easier review, easier rollback, less notification fatigue.
Explicit silence rule: only return [SILENT] when no artifact or finding exists.

For developer workflows, also separate “generate patch” from “merge patch.” A code-review agent can produce a branch and test output, but approval should decide whether it gets merged.

Common failure modes

Failure	Symptom	Fix
Prompt too broad	Agent creates many artifacts or changes scheduler config	Limit output to one artifact and forbid cron edits
Weak verification	Approval message says “done” without evidence	Require command output or file paths
Unsupported claims	Post mentions features without sources	Require official URLs in frontmatter or report
Chat formatting breaks commands	Placeholder text gets parsed as markup	Use plain text for approval packets
No revision path	Reviewer must reject for small edits	Add `revise ...: instruction` command

Implementation checklist

Before enabling a scheduled approval job, confirm:

[ ] task can run without live clarification
[ ] prompt names allowed and forbidden actions
[ ] artifact path is deterministic
[ ] duplicate check is mandatory
[ ] validation command is available
[ ] delivery channel is configured outside the task prompt
[ ] final response includes approval commands
[ ] rejection and revision paths exist

This pattern works because it treats autonomy as preparation, not permission. The agent does the repeatable work: inspect, draft, verify, summarize. The human keeps the final judgment call. That split is slower than full automation, but it is far easier to trust in real systems.

END OF NOTE