Automation & Agents — งานที่รันเองและตรวจเองAutomation & Agents — Work That Runs and Checks Itself

🤔 If you close the lid and walk away from the desk — what is the Hermes you have spent five posts configuring still doing for you?

The previous post — #5 Skills, MCP & Memory — stocked the agent's shelves: skills loaded on demand, MCP servers wiring in external tools, and the two memory files you can edit from the screen. I ended it by saying the numbers on the context meter would come back, because every cron job and every subagent has a context of its own to pay for. This is where they come back.

The one-line answer: work that runs itself in Hermes Desktop arrives through three surfaces — a Routine (a cron job a Bot owns) woken by the clock, a subagent the agent spawns for itself with delegate_task to fan work out in parallel, and the Agents and Command Center panes, which are the screens you watch those two from. Then this post closes with the gate that matters most for unattended work — verify_on_stop, which forbids the agent from saying "done" on a turn where it edited code and produced no fresh verification evidence.

1. What Runs When You Are Not Typing

The direct answer first: in Hermes Desktop (Hermes Agent v0.21.0, tag v2026.8.31) three surfaces can start work without you typing — cron jobs, which appear as Routines when a Bot owns them; subagents, which the agent creates for itself through the delegate_task tool; and the Agents and Command Center panes, which the docs describe as "orchestration surfaces for multi-agent work".^[3] The first two are mechanisms; the third is a window onto them.

The distinction to get straight from the outset is who presses start. A cron job is woken by the gateway's own ticker on a schedule you set; it builds a whole new session and delivers its result to a configured target. A subagent is created by the agent itself while it is already working for you — it is work being split inside one conversation, not a schedule. The delegation docs put it plainly: "Each child gets a fresh conversation and works independently — only its final summary enters the parent's context."^[4]

A Routine is simply what Bot Mode calls a Bot's own cron job, and it is not a new thing in the system — the Bot Mode docs say so outright: "Routines are plain Hermes cron jobs namespaced [bot:<name>] <routine> — they also show up in hermes cron list and the core Cron page."^[2] That is my favourite property of this design: the pretty screen did not invent a primitive we have to learn twice. What you click in the Routines pane is the same row hermes cron list prints in a terminal, and the same file at ~/.hermes/cron/jobs.json.^[1]

This post is the hands-on half, not the theory. If you want the full operations layer of cron — the executions.db file layout, the per-run ledger, the incidents/doctor/runs loop, inbound webhooks that verify a signature before believing anything, blueprints and the API server — I wrote it up in Hermes #8 Automation, and the four-layer multi-agent map (subagents, Kanban, Bot Mode/A2A, multi-profile serving) is in Hermes #2 Agent Teams. I will not repeat either of them here; I will click and type on the Desktop screen, and point back to those two posts when you want the depth.

2. Procedure A — Schedule a Routine

What you will have at the end: one Routine attached to one Bot, with a schedule of its own, testable immediately without waiting for the real hour, and its result landing in that Bot's own chat — where you would be talking to it anyway.^[2]

1. In Desktop's left sidebar, switch from the Sessions tab to the Bots tab and pick the Bot that should own this job. The Routines pane (called Cronjobs in some builds) docks beside the chat — the docs note it appears only while the Bots tab is active and steps aside when you switch back to Sessions, while older builds keep it always visible.^[3]
2. If you want the whole machine's view rather than one Bot at a time, open the Cron pane in the sidebar's management panes, which the Desktop docs describe in one line as "Cron — view and manage scheduled jobs".^[3] This is where every Bot's Routines meet the cron jobs you created from a terminal.
3. Create the job from the Routines pane. The docs describe the schedule control as "a structured schedule picker … (frequency first, then only the detail that matters), with an Advanced field exposing the raw Hermes schedule string"^[2] — so you choose the frequency first, fill in only the detail that matters, or open Advanced and type the raw schedule string yourself.
4. In the Advanced field use one of the forms the cron docs accept: a one-shot delay (in 30m), an interval (every 2h), a natural day/time (every monday 9am, daily at 7am, weekdays at 9am), a five-field cron expression (0 9 * * *) or an ISO timestamp (2026-03-15T09:00:00).^[1] For anything you actually need to depend on I would use the cron expression, because it leaves nothing to interpret.
5. Write a prompt that stands on its own. Remember that each run is a fresh session with none of the earlier conversation attached — and if the job needs a specific capability, attach a skill: one job can carry zero, one, or several skills.^[1]
6. Save it and fire a test immediately. The button is Trigger now — PR #70638, merged on 15 August 2026, is titled "make Trigger now execute immediately and safely" and fixed both the Dashboard and Desktop paths so that an immediate fire really goes through the scheduler provider instead of merely moving next_run_at.^[12]
7. Read the output. If the Routine belongs to a Bot, the result lands in that Bot's chat history,^[2] and whatever the delivery target is, every run is always written to a file at ~/.hermes/cron/output/{job_id}/{timestamp}.md^[1] — the evidence you can re-read when the result never reached you.

The CLI twin

Everything above has a terminal equivalent, and I usually create jobs from here because it can be written into a runbook. These commands are lifted straight from the cron feature page and the CLI reference:

# a recurring job every two hours — the docs' own example
hermes cron create "every 2h" "Check server status"

# attach a skill to the job (repeat --skill for several)
hermes cron create "every 1h" "Summarize new feed items" --skill blogwatcher

# let each run see its own previous output
hermes cron create "every 6h" "Scan for news" --continuity

# list everything — a Bot's Routines appear here too, named [bot:<name>] …
hermes cron list

# the rest of the lifecycle
hermes cron <pause|resume|run|remove|status|doctor|tick> <job_id_or_name>

Two details save a lot of time. First, every mutating verb (pause, resume, run, remove, edit) accepts a job name in place of the hex id, case-insensitively; when several jobs share a name the command refuses and lists the candidate ids so you pick one explicitly rather than having it guess.^[1] Second, hermes cron doctor is a read-only fleet health check — failed runs, failed deliveries, overdue or missing next_run_at, missing scripts or workdirs — and it exits non-zero when issues are found, which means you can hang it off CI or an OS-level cron directly.^[9]

💡 Since v0.21.0 scheduled jobs are no longer goldfish: the v0.21.0 release note reads "Scheduled jobs stopped being goldfish. Cron agents now load and update persistent memory like every other agent, continuity=true carries each run's output into the next (so a monitor can dedupe against what it already reported), every job gets a durable notepad scratchpad, monitor-mode jobs skip the LLM entirely when nothing changed".^[11] A caveat I checked myself on the day of writing: the cron docs page has not caught up — it documents continuity and context_from fully, but contains no sentence about cron persistent memory at all.^[1] So I would treat continuity as the documented mechanism and treat persistent memory as behaviour the release note announces but no docs page yet governs, including which memory files a cron run touches.

One community observation worth reading: the most common complaint about cron is not "it did the wrong thing" but "it ran once and never again". Greg Isenberg's Hermes Desktop walkthrough with Alex Finn (6 June 2026) summarises the fix in one line, noting that Finn "praises the Cron section for giving one-click confirmation that scheduled tasks truly exist".^[14] Put another way: a job you asked for in chat or over Telegram and never opened in the Cron pane is a job you do not know exists. The Cron pane is not decoration, it is the receipt — and hermes cron list is the same receipt in a terminal.

3. Procedure B — Delegate and Watch

The answer first: you do not press a button to create a subagent. You ask the agent to split the work, and it calls delegate_task itself. Your job is to see how many children it spawned and what they are doing — and, when one drifts off course, to redirect it mid-flight instead of throwing away the work it has already done.

1. In an ordinary Desktop chat, give it work that genuinely splits into independent pieces — "review these three PRs in parallel and report each one back to me separately". If the sub-tasks do not depend on each other, the agent will choose the batch form on its own.
2. Know what the agent is sending. The delegate_task parameters the docs describe are goal (what to do), context (everything the child needs, because it starts from an empty conversation), tasks (the array for a parallel batch, with an optional group when results should come back consolidated), role — "leaf" by default or "orchestrator" — max_iterations (tool-calling turns for one child), background and output_schema.^[4][11]
3. When the answer needs a fixed shape, ask for an output_schema. PR #81144, merged 7 August 2026, describes the behaviour: the child receives the schema as "an explicit OUTPUT CONTRACT block in its context", the parent then validates the final answer with jsonschema, and on failure sends exactly one bounded retry turn carrying the validation errors verbatim.^[12]
4. See who is running with /agents (alias /tasks). The docs say it shows a live tree of running and recently-finished subagents grouped by parent, with per-branch cost, token and file-touched rollups, plus kill and pause controls that cancel one subagent mid-flight without interrupting its siblings.^[4]
5. Redirect rather than kill — the parent orchestrates its children with the same tool it spawned them with, sending the three actions in the code block below. The docs state the reason plainly: "Interrupting a child throws away its in-flight work; often you just want to redirect it."^[4]
6. Read the cost. v0.21.0 added "per-delegation cost surfaced in results",^[11] so you can see the price of one fan-out rather than only the session total.

{"action": "list"}
{"action": "steer", "subagent_id": "sa-0-1a2b3c4d", "message": "focus on pricing instead"}
{"action": "stop",  "subagent_id": "sa-0-1a2b3c4d"}

Three simple calls, with details worth knowing before you depend on them. list returns the conversation's live children with subagent_id, goal, status, running_seconds, accepting_steer and the live transcript path. steer queues a course correction into a running child without stopping it, and stop ends a child at its next iteration boundary — with the partial result still re-entering the conversation as a normal completion rather than being lost. All three actions run synchronously in-turn, are scoped to the caller's own spawn tree (a conversation can never see or control another session's children), and never consume the per-turn spawn cap, so stop keeps working even after the cap is hit.^[4]

One trap to remember: "queued" is not "delivered". The docs explain that a "queued" response means the text was accepted before the child's completion boundary, not that the child has seen it. If a child accepted the steer but had already produced its final answer, the completion entry the parent receives retains it as missed_steer, with a note appended to the summary — [steer did not land — the subagent finished before it could be delivered: …] — so you can tell a steered child from one that finished on the old instructions.^[4]

4. Gates for Unattended Work

Directly: the switch you want is agent.verify_on_stop. The configuration docs describe it as follows — "When enabled, Hermes refuses to accept a final answer on a turn where the agent edited code in a workspace but produced no fresh verification evidence (a passing test run, build, lint, etc.) — it injects a synthetic follow-up asking the agent to verify or explain why it can't."^[5] Doc, markdown or skill-only edits never trigger it, and the loop is bounded so it can never trap the agent.

The default is off, and this is where most people are caught out, because they assume it ships on. The config block has three keys:

agent:
  verify_on_stop: false        # true | false | "auto" (surface-aware: on for CLI/TUI/desktop, off for messaging)
  verify_guidance: true        # Append creative-UI / clean-diff guidance to the missing-evidence nudge
  max_verify_nudges: 3         # Cap on consecutive continue nudges per turn (built-in + pre_verify hooks)

The three values verify_on_stop accepts are true (on everywhere), false (off — the default) and "auto", the legacy surface-aware behaviour: on for interactive coding surfaces — CLI, TUI, desktop — and programmatic callers, off for messaging surfaces such as Telegram or Discord where the verification narrative reads as chat noise.^[5] The docs add that fresh installs ship false and that the config migration turned it off on existing installs, so enabling it is always a deliberate opt-in; the HERMES_VERIFY_ON_STOP environment variable overrides the config value. I confirmed the default in the source too: hermes_cli/config_defaults.py carries "verify_on_stop": False and "max_verify_nudges": 3.^[10]

The second gate — the pre_verify hook

If your team's rule is more specific than "there must be evidence", write a plugin hook. The hooks docs say pre_verify "Fires once per turn when the agent edited code, just before it finishes (after the built-in verify-on-stop guard)" and call it "a user/plugin policy gate".^[6] The payload the callback receives has seven fields:

• session_id — unique identifier for the current session
• platform — where the session is running ("cli", "telegram", …)
• model — the model identifier
• coding — whether the turn is in the coding posture; scope your hook on this
• attempt — how many times this turn has already been nudged (0 on the first); self-throttle on this
• final_response — the answer the agent is about to deliver
• changed_paths — the files the agent edited this turn (sorted, and never empty in this context)

Return {"action": "continue", "message": "…"} to send the agent back to work — the message is appended as a synthetic user turn and the loop runs again. The docs note that Claude Code's Stop shape ({"decision": "block", "reason": "…"}, where blocking the stop means keep going) is accepted too; any other return, or a directive with no message, lets the turn finish.^[6] Consecutive continue directives in one turn are capped by agent.max_verify_nudges (default 3), so a hook that always says continue can never trap the loop.^[6]

The smallest plugin that works, following the layout the plugins page lays out, is a directory under ~/.hermes/plugins/ holding a plugin.yaml and an __init__.py with a register(ctx) function that calls ctx.register_hook(...):

# ~/.hermes/plugins/verify-gate/__init__.py
# the register(ctx) + ctx.register_hook skeleton comes from the plugins page,
# the pre_verify signature from the hooks page

def require_changelog(coding, attempt, changed_paths, **kwargs):
    if attempt or not coding:
        return None                      # one-shot, coding turns only
    if any(p.endswith("CHANGELOG.md") for p in changed_paths):
        return None                      # a changelog entry exists, let it finish
    return {
        "action": "continue",
        "message": "Add a CHANGELOG.md entry for this change before finishing.",
    }


def register(ctx):
    ctx.register_hook("pre_verify", require_changelog)

The first two lines of that function are the docs' own advice: scope on coding and make it one-shot with attempt, because the hook re-fires after each nudge — without the if attempt: return None door it will simply nudge until it hits the cap.^[6] One more thing to know before you drop files anywhere: project-local plugins (./.hermes/plugins/) are disabled by default and need HERMES_ENABLE_PROJECT_PLUGINS=true before starting Hermes, which the docs say to enable only for repositories you trust.^[7]

💡 The gates for work you ARE watching live somewhere else: verify_on_stop and pre_verify are built for turns that edit code. If what you want to check is the quality of an answer in work you are supervising, reach for a different set of tools — a Mixture of Agents preset where several models answer separately before one synthesises, /review to dispatch an independent reviewer, and /goal, whose judge only accepts "done" against real evidence. All three are in #4 The Council, command by command.

5. Reference — Every Door That Can Start Work

This is the one sheet I open when deciding "which door should this work come through". The first two rows are this post's subject; the other four live in other posts and are here so you can see the whole picture:

Read that table down the Memory column and almost every choice explains itself. Work that must "remember what it told you yesterday" belongs in a Routine, not a subagent, because a subagent starts from zero every time by design. Work that must survive a restart and leave a trail a person can step into belongs on the Kanban board, not in either — and the delegation docs point the same way, saying that for durable execution that must survive session closure or a process restart you should use cronjob or terminal(background=True, notify_on_complete=True) instead of delegate_task.^[4]

6. Limits to Know

The three limits below are real as of 7 September 2026, and every one of them changes how you design automated work. I have ordered them by how much they affect ordinary daily use:

• A Bot group room is tied to a Desktop that stays open. Issue #95163 (opened 26 August 2026, last updated 6 September 2026, still open) explains that a group room's rounds are driven entirely by the Desktop renderer, and lists as its first consequence: "Rooms stall when the driving client goes away. Backgrounding or closing the desktop mid-round stops turn delivery until it returns."^[13] Issue #97681, "Bot Group Chats should keep working after Desktop closes" (opened 29 August 2026, last updated 6 September 2026, still open), is the fix path still under way, and the issue itself states that "Work continues without Desktop only while the authority gateway is reachable" and that "Passive history retention is not safe automatic takeover, which remains disabled."^[13] The practical conclusion: do not design overnight work to live in a group room. Use a Routine or the Kanban board instead.
• The subagent model is one global value, not a per-call one. The delegation docs say it literally: "the pin is global: delegate_task has no per-task model parameter, so every child in a batch runs on the configured delegation model". The knobs you get are delegation.model and delegation.provider in config.yaml, and if one sub-task needs a stronger model the docs' own answer is either to leave delegation.model unset for that session or to hand the task to the Kanban board, which does support a per-task model override.^[4] Hence the cost strategy the docs recommend — "frontier planner, inexpensive workers": the parent stays on the strong model while the whole flock of children runs on a cheap one, because that is where most of the tokens land.^[4]
• The delegation defaults still disagree between the docs and the code. I checked three sources on the same day. The delegation docs page says max_iterations defaults to 50 and that 3 tasks run in parallel, but hermes_cli/config_defaults.py on main reads "max_iterations": 250 and "max_concurrent_children": 10, and cli-config.yaml.example carries the same pair.^[4][10] The v0.21.0 release note settles the dispute itself, saying delegation gained "raised defaults (250 iterations, 10 concurrent children)".^[11] So the numbers actually in force are 250/10, and the docs page is the side that has not caught up. Never budget cost against the number 3 — and to read the real value on your own machine, run hermes config get delegation.max_concurrent_children.^[9]

7. Summary

We started with the question of what the machine does while you are not typing, and found three surfaces: a Routine woken by the clock which, since v0.21.0, remembers its last run; a subagent the agent fans out for itself and which you can redirect mid-flight from /agents; and the panes you watch both from. Then we closed the door with verify_on_stop, which forbids the word "done" where there is no evidence, and the pre_verify hook, which turns your team's rule into a real condition in code. Finally we put every door into one table and accepted the three limits that have not gone away today. The next post, #7 Safety, Remote & Recovery, takes on the one question left — how to get everything back when it breaks.