Hermes Agent Automation: Cron, Kanban, and Sub-Agents (2026)

Last tested and updated: June 2026

Cron is how Hermes runs while you’re not at the keyboard. Once a routine runs without you, the agent stops being a tool you use and becomes a worker you hire.

Prereqs: L02 install, L04 Skill Bundles, L05 MCP catalog (Model Context Protocol), L07 security for 24/7 VPS runs.

Who this is for

You have used the Hermes TUI for at least a week and want the agent to run tasks without you at the keyboard. This lesson assumes muscle memory: you can run a slash command, you know what a Skill Bundle is, and you’ve built one in L04.

Not for: anyone who hasn’t installed Hermes (L02) or built a Skill Bundle (L04). Those come first.

What you’ll be able to do

By the end of this lesson you can configure one reliable daily cron job, pick the right Hermes automation pattern for a new task, and avoid the three silent-failure modes that catch first-time automation users.

Learning objectives

• Configure a daily cron job inside Hermes that runs reliably while your laptop is closed.
• Compare the cron, Kanban, and sub-agent patterns and pick the right one for a given task.
• Debug the silent-failure traps (no log file, fresh-session Skills, race conditions) that hide a broken job for days.

The hook

Pick a task you do every weekday. “Open five tabs, scan the AI news, write a summary, paste it into the team Discord at 7am.” The whole point of running Hermes is that it does this without you.

Figure 1: The three pieces — a cron trigger (left), a Skill Bundle brain (middle), and a Discord webhook delivery (right). No glue code.

That’s the picture. A trigger (cron). A brain (a Skill Bundle from L04). A delivery (a Discord webhook from L05). You wire three existing pieces together — no glue code. The rest of this lesson is the three pieces and the gotchas that make the wiring fail.

The mental model

Hermes has three automation patterns. They look similar — “the agent does something without you” — but they answer three different questions.

Pattern 1 — Cron jobs. A scheduled trigger. “Run this command at 7am every day.” Best for: simple, repeatable, single-task automation. A daily research summary. An hourly price check. A weekly newsletter draft. The job is small and well-defined. Its value is that it runs even when your laptop is closed.

Pattern 2 — Kanban boards. A multi-agent project board. Each task has an assignee profile — a separate Hermes instance with its own config, API keys, and specialisation. Multiple named workers collaborate. You watch progress on a live dashboard. Best for: multi-step workflows with defined roles. “Research → draft → review → publish.”

Pattern 3 — Sub-agents. A worker spawned by your main agent within the same session. It has no persistent state, no specialisation, and no separate config — just quick parallel work. Best for: “search three sources at once and combine the result” inside one workflow.

Figure 2: A Kanban board with three columns (To do, In progress, Done) showing task cards owned by named worker profiles @researcher, @drafter, @reviewer. The board itself is the role trigger.

The shapes map onto different problems: cron is a time trigger, Kanban is a role trigger, sub-agents are a parallelism trigger. Confusing them is the most common beginner mistake.

hermes cron --help

Figure 3: The hermes cron subcommand tree. hermes cron status is your smoke test — if it says the scheduler is not running, nothing else matters.

Pick your tool

Decide by asking three questions in order.

1. Is the work a single recurring task with no human review? → Cron.
2. Is the work a multi-step project with defined roles and visible progress? → Kanban.
3. Is the work a quick parallel fan-out inside one session? → Sub-agent.

Task	Pattern	Why
Daily 7am summary or hourly price check	Cron	Single recurring task, runs on a schedule, no review needed
Research → draft → review → publish pipeline	Kanban	Multiple roles, visible state, possible retries
”Search three sources in parallel and combine”	Sub-agent	One session, fan out, gather
Weekly newsletter draft or 24/7 VPS assistant	Cron now, Kanban later	Cron is fine while you’re solo

For 90% of beginners, the right answer is cron. Don’t reach for Kanban until you have a multi-step project that benefits from visible progress.

The cron skill

Cron is the simplest pattern. Three steps: define the work as a Skill, schedule it, verify it runs. The Skill Bundle pattern from L04 lines up perfectly here — one slash command replaces five manual steps, and cron fires it for you.

The minimum viable cron job looks like this:

# Pick a Skill Bundle you already trust manually (L04).
# Test it interactively first. If it doesn't work in your terminal,
# it won't work in cron.

# Register the schedule with Hermes:
hermes cron create \
  --name morning-summary \
  --cron "0 7 * * *" \
  --command "/morning-brief"

# Verify it actually exists and will fire:
hermes cron list
hermes cron status

The first thing to notice: cron is a first-class subcommand on the Hermes CLI, not a wrapper around the system cron daemon. The scheduler runs inside Hermes, so jobs share its config, API keys, and logs. If Hermes restarts, jobs pause until it comes back up.

The five habits that prevent silent failures:

• Use the absolute command path. hermes cron status from your shell may resolve $PATH; the scheduler may not.
• Pass the working directory explicitly. Cron starts in $HOME. If your Skill reads ~/projects/news/, tell it so.
• Log to a file. Append stdout and stderr. Check it the next morning.
• Test the Skill manually first. If /morning-brief fails interactively, it will fail in cron.
• Schedule a canary. Have a weekly job post a heartbeat to Discord — “I’m alive” — so you know the scheduler itself is running.

The kanban gotcha

Kanban is powerful but it is not what you should ship first. Per the source video, do not pair Kanban with cron until Hermes ships reliable delete and dedup logic — duplicate tasks pile up and workers race to write the same file.

The right order: ship one cron job first. Watch it run for a week. Then start a Kanban board for one project (Story 1 in the source video’s taxonomy). Graduate to multi-role pipelines only after that.

The sub-agent gotcha

Sub-agents are the fastest pattern but the most fragile. Per the L06 source video, parallel research with cheap models took 14 minutes — longer than doing it directly.

Sub-agents are a tool for inside a workflow, not for replacing it. If you want sub-agents for long-running automation, you probably want cron or Kanban instead.

Common pitfalls & troubleshooting

Each pitfall uses symptom, cause, fix in that order.

Pitfall 1 — Pairing Kanban with cron before delete + dedup ships

• Symptom: duplicate cards pile up on the board; two workers race to overwrite the same output file; the cron tick fires before yesterday’s Kanban story moves out of In progress.
• Cause: Hermes doesn’t yet ship reliable delete + dedup. Pairing the two sources (per iN2fD36Sgdg) recommended running them separately until that lands.
• Fix: run cron and Kanban against separate profiles. Don’t wire hermes cron run to feed a Kanban Story until the crew ships dedup.

Pitfall 2 — Sub-agent that loops on the same question six times

• Symptom: a sub-agent asks the same clarifying question repeatedly, burns tokens, and produces no output. Your bill spikes; nothing lands on disk.
• Cause: the prompt is ambiguous and the sub-agent has no iteration cap to force a decision (cxF_F217r6I, 701XCzDQVhA).
• Fix: set a hard iteration cap (3–5 is plenty), tighten the prompt so the question has a forced choice, and verify sub-agent outputs — not the chain of reasoning.

Pitfall 3 — Burning 81 runs without a budget

• Symptom: the same automation fails again and again with slight variations; you’re still “just one more tweak” away; cost climbs into real money.
• Cause: no iteration budget. The source’s own creator needed 81 runs (SdahAks9ffE). Without a cap, beginners burn the same 81.
• Fix: decide up front how many attempts you allow (10–15 is sane). When you hit the cap, change something structural — different Skill, different pattern — not just a rephrase.

Pitfall 4 — Cron surviving a VPS reboot but the working directory doesn’t

• Symptom: the job ran for weeks, then a VPS reboot happens; the next tick fails or runs in the wrong directory reading the wrong files.
• Cause: cron entries survive on disk, but the working directory the Skill reads may have moved, an absolute path may have changed, or environment variables aren’t set on the new boot.
• Fix: always pass --workdir (or the equivalent in your build) and use absolute paths inside the Skill. Run hermes cron status after every reboot as a smoke test.

Pitfall 5 — Manual TUI session racing the cron job

• Symptom: cron runs while you have the TUI open on the same profile; the lockfile complains, the cron tick is skipped, or your manual session sees a half-applied state.
• Cause: both processes want exclusive access to the same agent profile — a classic lockfile race.
• Fix: use separate profiles per Kanban story and for cron; close the TUI before you trigger hermes cron run --debug. Never run manual and cron work on the same profile at the same time.

Pitfall 6 — “I thought it was working” because nobody checked the log

• Symptom: the job fires every morning but the expected output never appears. Nothing visibly breaks, so you don’t notice.
• Cause: you skipped step 4 of hermes cron create — --log — and the agent is failing into /dev/null. Silent failure is the #1 source of automation frustration.
• Fix: always pass --log ~/.hermes/logs/<name>.log. Add a morning habit: open the log once a week, scan for the last 7 days of runs, fix anything red.

Pitfall 7 — Skill that works once interactively but fails in cron

• Symptom: you test /morning-brief in the TUI, it works, you wire it into cron, and the first scheduled tick fails or produces garbage.
• Cause: cron sessions are fresh — no chat history, no warm context, no human clarification. A Skill that relies on follow-up questions will silently fail.
• Fix: rewrite the Skill to run end-to-end from zero state. If it cannot, the Skill is not ready for cron — fix it before you schedule it.

Key takeaways

• Cron is the right starting tool for 90% of beginners. One Skill, one schedule, one log file. Ship that first.
• Kanban is a role trigger, not a time trigger. Use it when you need visible progress and defined roles.
• Sub-agents die with the session. They are parallelism inside a workflow, not a replacement for cron.
• Logs prevent silent failure. Every cron job gets --log and a weekly check.
• Don’t pair Kanban with cron yet. Until Hermes ships delete + dedup, run them separately.

Try it

Build a daily 7am summary cron

Pick one Skill Bundle you already trust manually — a research summary, a saved-links digest, a calendar preview. You built one in L04 if you followed that lesson. If not, write one now: the exercise below assumes a Bundle called /morning-brief.

Step 1 — Verify the Skill works manually.

hermes
> /morning-brief

Watch the output. If it fails here, no amount of cron will save you. Fix it until it produces the output you want.

Step 2 — Confirm the cron scheduler is running.

hermes cron status

You should see “scheduler running.” If not, see L07 on daemon recovery and per-user service setup.

Step 3 — Register the cron job.

hermes cron create \
  --name morning-summary \
  --cron "0 7 * * *" \
  --command "/morning-brief" \
  --log ~/.hermes/logs/morning-summary.log

Step 4 — Confirm it’s listed.

hermes cron list

You should see morning-summary with the 0 7 * * * schedule.

Step 5 — Force a tick.

hermes cron run --debug morning-summary

This fires the job immediately so you don’t have to wait until 7am. Watch the log file:

tail -f ~/.hermes/logs/morning-summary.log

Step 6 — Verify the Discord post.

If your Skill is wired to Discord via L05, the post should appear in your channel within a minute of the tick. If it doesn’t, check three places in order: the webhook URL, the MCP server auth, the Skill’s output format.

Success criteria

You have shipped your first cron when all five of these are true:

• The Skill works manually.
• hermes cron list shows your job.
• hermes cron status says the scheduler is running.
• hermes cron run <name> produces the expected output in the log.
• The next 7am fires on its own without you touching the keyboard.

If the first run is silent, the most common cause is the Skill failing in a fresh session. Run hermes cron run --debug morning-summary to see the full trace.

Do this today

• Pick one Skill Bundle you trust manually (the one you tested in L04).
• Run it interactively in the TUI; fix it until it produces what you want.
• Confirm hermes cron status says the scheduler is running.
• Register the cron entry with a --log path under ~/.hermes/logs/.
• Force a tick with hermes cron run --debug <name>; tail the log.

What’s next

• L07 — security essentials if cron breaks after a VPS reboot
• L09 — Hermes Agent vs Claude Code vs Mavis vs Gemini before you add a Kanban Story 3+ pipeline

If you want to go deeper

• The Hermes GitHub repo — docs on cron persistence, scheduler recovery, and the long-running Kanban Story config. Canonical source for --log flag semantics and profile isolation.
• The sub-agent iteration cap, in Ron’s words: video 701XCzDQVhA — the “asked the same question six times” short. Source for the loop gotcha in Pitfall 2.
• Iteration cost in numbers: video SdahAks9ffE — “It Took 81 Runs to Get the Automation Right.” A case for setting a hard iteration cap (Pitfall 3).

Watch the full walkthrough

Check your understanding

Quiz: see quiz.json (6 questions, valid JSON).

Post your first cron screenshot or the canary Discord message in the community Discord — the best ones get featured next week.

FAQ

Q: Do cron jobs run when my Mac is asleep?

No — and yes, depending on where Hermes runs. The cron scheduler lives inside the hermes process. If your laptop is closed or the process is paused, the job misses its tick. Run cron on a 24/7 host (a VPS, a mini PC, or a desktop you don’t sleep) if you want the 7am job to fire while you sleep.

Q: Can a Kanban story call another Kanban story?

Not directly, as of June 2026. Each Kanban story is owned by an assignee profile that runs to completion — stories do not chain into other stories on their own. If you need a “research → draft → review → publish” pipeline, wire the dependencies with cron: job A writes the handoff file, job B reads it. Or wait for the chaining operator — the skeleton flags this as a known gap.

Q: How do I see what my sub-agent is doing?

You see the task assignment on the Kanban dashboard, not the reasoning. Sub-agents have their own context window that is not exposed to you. Verify outputs (the final answer, the file produced), not processes (did it ask a clarifying question, did it loop, did it pick the cheap model). If you need the thinking, run the same prompt in your main agent.

Q: Cron vs Kanban for a beginner — what’s the difference?

Cron is a time trigger: one job, one Skill, fires on a schedule. Kanban is a role trigger: many workers, named assignee profiles, a visible board. If your work is one recurring task a single Skill can handle, cron is enough — start there. If your work needs visible progress, retries, and defined roles, Kanban earns its complexity. Most beginners never need Kanban.

Glossary

• Cron job — a scheduled task. “Run this command at 7am every day.” Named after the Unix cron daemon. In Hermes, it lives inside the hermes process.
• Kanban — a visual task board. Each story has a status (To do / In progress / Done) and an assignee profile.
• Sub-agent — a worker agent spawned by your main agent within the same session. Its own context window, no persistent state — dies with the session.
• Assignee profile — a separate Hermes instance per worker. Each has its own config, API keys, working directory.
• Loop — a workflow that retries until a success check passes. Sub-agents live inside a loop; Kanban stories run to completion.