Kanban + cron: turning a 14-step pipeline into 9 parallel workers - Sub-agents & the Kanban

The §7.3 article covered the Kanban's core feature set — the four-step setup, the parent-child retry loop, the Worker Logs audit trail. This article covers the cron pairing — the layer that turns a one-shot Kanban into a 24/7 production pipeline. The headline from the source video is dramatic: a 14-step sequential cron becomes a 9-worker parallel pipeline. The reality is sharper: the cron pairing works, but it ships with four known bugs that the channel has named explicitly. The bugs are: gateway exits early, duplicate parent tasks on test runs, no cron-to-Kanban dedup, and task accumulation (the creator hit 63 orphan children in a week).

This article walks through the old setup vs. the new setup, the four bugs, and the recommendation from the channel: start with a non-cron project in a dedicated workspace folder, not a scheduled pipeline.

What you'll learn

The old cron was 14 sequential web searches daily; the new pipeline is 5 parallel search workers + 2 editors + 2 publishers, all dispatched by a parent task on a Kanban board.
The pairing works because the cron only fires the parent task; the Kanban dispatches the child workers in parallel. The two layers are different surfaces with different responsibilities.
Bug 1 — Gateway exits early. Ready child tasks never get dispatched after the parent completes. Fix: a systemd service keeps the gateway alive 24/7.
Bug 2 — Duplicate parent tasks on test runs. May 6, 2026 at 9:10 a.m. produced two completed task sets and two Discord pings. There is no native dedup yet.
Bug 3 — No cron-to-Kanban dedup. Every scheduled run creates a fresh task set regardless of what's already on the board. Fix: the agent now does a dedup check before spawning.
Bug 4 — Task accumulation. After one week, the board had 7 parent tasks and 63 children; the dashboard currently lets you block but not delete tasks.
The recommendation: start with a non-cron project, not a scheduled pipeline. The cron pairing is Story 3 — only attempt it after Story 1 has worked twice in a row.

Old setup vs. new setup

The source video's framing is direct: the old cron was fragile (iN2fD36Sgdg).

Old setup. A single cron fired daily at 9:00 a.m. Hong Kong time and spawned a single sub-agent that ran 14 web searches sequentially, wrote the report, updated the HTML landing page, and posted to Discord. The problems:

One failed search stalled everything (the chain was sequential, not parallel)
The shell date syntax was passed literally into search queries (a quoting bug in the cron command)
Reports had been getting shorter since May 2nd (the model was running out of context by step 14)

The old setup is the vibe-coded slop failure mode at cron scale: a single chain of work, no parallelism, no retry, no audit trail beyond the cron log.

New setup. The same cron, but the parent task dispatches to a Kanban board:

5 parallel search workers (model releases, tool releases, agent frameworks, trending workflows, plus one for active inputs)
2 editors that filter duplicates and rank by importance
2 publishers that update the HTML and fire the Discord notification

Output is now structured with tables, categorisation, and 48-hour verification (iN2fD36Sgdg).

The 14 sequential steps become 9 parallel workers. The "9" is the unique worker count, not the total task count — the parent task itself counts as task 1, the 5 search workers are tasks 2-6, the 2 editors are tasks 7-8, and the 2 publishers are tasks 9-10. The "14" in the old setup included the sequential search steps; the "9" in the new setup is the unique worker roles, with parallelism on the 5 search workers.

The speedup is the parallel-execution win from §7.2. 5 search workers running in parallel complete in ~20% of the time of 5 sequential workers. The editors and publishers run in parallel with the tail of the search; the publishers run after the editors. The total wall-clock is bounded by the slowest search worker plus the editors plus the publishers, not the sum of all 14 steps.

How to actually get it running

The source video's practical advice: don't assume the agent knows its own features (iN2fD36Sgdg). The creator's first prompt was literally:

Can you study and understand the official documentation of the Kanban features?

Paste the doc links and ask how they apply to your pipeline. Let the agent create specialist profiles and tool sets via TUI. Two profile-config gotchas from the source:

Profile .env files start empty even when a key exists in the main agent's dotenv. Remove empty API key fields from config.yaml and copy the real key into each profile.
Reuse the same key across roles. This is the move if you are on a Kimi coding plan and want to fan out — one API key, multiple profiles, parallel dispatches.

Token budget suggestions (proposed by the agent itself in the source): 90–100 for researchers, mid-range for editors, 20–30 for publishers. The budget maps to the context-window math from §7.1: researchers need more context for source variety, publishers need less because the output is structured.

Bug 1 — Gateway exits early

The first known bug (iN2fD36Sgdg):

Gateway exits early. Ready child tasks never get dispatched after the parent completes.

The bug is a process-management issue, not a Kanban issue. The hermes gateway start command starts a process; the process is the runtime that dispatches child tasks. If the process exits — because the shell session ended, because the tmux wrapper was killed, because the SSH connection dropped — the child tasks never get dispatched even though the parent completed.

Fix: a systemd service keeps the gateway alive 24/7. The service definition is straightforward — ExecStart=/usr/local/bin/hermes gateway start, Restart=always, RestartSec=10 — and survives SSH disconnects, reboots, and tmux kills. The creator warns this will burn electricity on a local machine — VPS is the right place to run this.

The §3.2 article in Course 3 flagged that the tmux new -s hermes -d 'hermes dashboard --no-open --bind ...' wrapper survives a logout "roughly 50% of the time." The 50% survival rate is the same failure mode the §7.4 bug is naming — a tmux wrapper is not a real supervisor. Systemd is the real supervisor.

Bug 2 — Duplicate parent tasks on test runs

The second known bug (iN2fD36Sgdg):

Duplicate parent tasks on test runs. May 6, 2026 at 9:10 a.m. produced two completed task sets and two Discord pings.

The bug is a cron-edge-case. The May 6, 2026 run was a test re-run that the cron was supposed to skip; the cron fired anyway, and the Kanban dispatched the parent task twice. Two completed task sets, two Discord pings, two daily reports delivered to subscribers. The bug is a notification duplication — the artefacts are correct, but the user-visible side effects (Discord pings) are doubled.

Status: there is no native dedup yet. The creator is waiting for a fix. In the meantime, the workaround is to manually disable the cron before a test run and re-enable after.

The structural lesson: the cron and the Kanban are two separate surfaces, and the cron does not know what the Kanban is doing. A cron that fires "daily at 9:00" has no way to ask the Kanban "did the previous run complete successfully?" — it just fires. A multi-run test that doesn't disable the cron is a multi-run test that produces duplicates.

Bug 3 — No cron-to-Kanban dedup

The third known bug (iN2fD36Sgdg):

No cron-to-Kanban dedup. Every scheduled run creates a fresh task set regardless of what's already on the board.

This is the same bug as Bug 2, but at the task-set level, not the parent-task level. Bug 2 is "the cron fires twice." Bug 3 is "even when the cron fires once, the Kanban doesn't check whether a previous task set is still in flight."

Fix: the agent now does a dedup check before spawning. The dedup check is a query against the Kanban DB — "is there a parent task for this cron with status doing?" — and if yes, the new parent task is not created. The dedup check is a workaround, not a native feature; the native dedup has not shipped yet.

The structural lesson: the cron is a trigger, not an orchestrator. The orchestrator is the Kanban. The cron does not know what the Kanban is doing, and the Kanban does not know what the cron is firing. The dedup check bridges the two surfaces manually.

Bug 4 — Task accumulation

The fourth known bug (iN2fD36Sgdg):

Task accumulation. After one week, the board had 7 parent tasks and 63 children; the dashboard currently lets you block but not delete tasks.

The bug is a UI gap, not a logic gap. The Kanban tracks every task — parent and child — and the dashboard exposes block as the only destructive action. After a week of daily 9:00 a.m. runs, the creator had 7 parents (one per day) and 63 children (9 workers × 7 days, modulo a few early failures). The board is cluttered; the historical data is preserved; the user experience is degraded.

Status: the delete button has not shipped yet. The creator is waiting for a fix. In the meantime, the workaround is to block old task sets to declutter the UI — blocked tasks are hidden from the default view, but they are still in the database and still count toward the worker logs.

The structural lesson: the Kanban is a durable system — tasks are preserved across restarts, gateway crashes, and daily cycles. Durability is the feature, but it is also the bug: nothing is garbage-collected. A production Kanban needs an explicit retention policy ("block task sets older than 30 days") and a delete primitive that the dashboard does not yet ship.

The recommendation: start with a non-cron project

The creator is explicit (iN2fD36Sgdg):

Start with a non-cron project in a dedicated workspace folder, not a scheduled pipeline.

On a rebuild, he would skip the cron pairing entirely until the delete button and native dedup ship. The cron pairing is Story 3, and Story 3 is only worth attempting after Story 1 has worked twice in a row and Story 2 has been validated.

The four bugs are the reason. The cron pairing works, but it ships with:

A process-management requirement (systemd, not tmux)
A cron-edge-case that produces duplicate pings
A dedup gap that requires a manual workaround
A UI gap that requires manual cleanup

For a daily 9:00 a.m. news briefing where the deliverable is a Discord ping, the bugs are tolerable. For a 24/7 production pipeline where the deliverable is a paid customer notification, the bugs are blockers. The channel's recommendation is to not ship a cron + Kanban pipeline to production until the four bugs are addressed.

The cron schedule that works

The schedule that worked in the source video: daily at 9:00 a.m. Hong Kong time (iN2fD36Sgdg). The cron expression is 0 9 * * * in the local timezone, with the timezone set on the server. The 9:00 a.m. cadence matches the §7.2 blueprint's "daily" tier — 100% of runs had 50+ items, good for comprehensive reports.

The blueprint's 6-hour cadence (0 */6 * * *) is a more aggressive schedule; the cron + Kanban pairing in the source video is the daily cadence. The 6-hour cadence is for research workflows that need trend detection; the daily cadence is for news briefings that need comprehensive coverage. The cron + Kanban pairing works for both, but the bug profile is the same.

The gateway audit

The creator runs a daily audit of his AI-news pipeline that verifies the gateway is up (fKoPRL0dhyk). The audit is critical on VPS, because if the gateway dies, the child task "will forever wait for the parent task."

The audit is a single shell command — systemctl status hermes-gateway — wrapped in a daily cron that pings Discord if the gateway is not running. The audit is the difference between a 24/7 pipeline and a 24/7 zombie. Lazy users can audit weekly, but on a VPS the audit is the price of unattended operation.

Try it yourself

The hands-on goal: stand up a Story 1 Kanban (from §7.3), prove the parent-child retry loop, and only then layer a cron on top.

Do not start with a cron. The §7.3 Try-it-yourself sequence is the prerequisite. Get a Story 1 Kanban working twice in a row before you attempt a cron + Kanban pairing.
Set up the gateway as a systemd service. The §7.4 Bug 1 fix. The service definition:
```
[Unit]
Description=Hermes Kanban Gateway
After=network.target

[Service]
ExecStart=/usr/local/bin/hermes gateway start
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
```
Run systemctl enable hermes-gateway && systemctl start hermes-gateway. Verify with systemctl status hermes-gateway.
Create the cron entry. Pick a daily or 6-hour cadence based on your use case. The §7.2 cadence table is the reference: hourly is too sparse, 6-hour is optimal, daily is comprehensive.
Test the cron once before going live. Disable the cron, manually trigger the parent task via the Kanban UI, verify the dispatch, verify the artefact. Re-enable the cron and let it run once on schedule. Compare the artefacts.
Set up the dedup check. The §7.4 Bug 3 workaround. The agent does a query against the Kanban DB before spawning — "is there a parent task for this cron with status doing?" If yes, skip the spawn.
Run a daily gateway audit. Wrap systemctl status hermes-gateway in a daily cron that pings Discord if the gateway is not running. The audit is the difference between a 24/7 pipeline and a 24/7 zombie.
Block old task sets weekly. The §7.4 Bug 4 workaround. Once a week, block task sets older than 30 days to declutter the UI. The blocked tasks stay in the database; they are just hidden from the default view.
Monitor for the four bugs. If you see duplicate Discord pings (Bug 2), task sets piling up (Bug 4), or child tasks not dispatching (Bug 1), check the gateway first, then the worker logs, then the dedup check.
Re-evaluate when the delete button and native dedup ship. The four bugs are blockers for production-grade cron + Kanban pipelines. Re-check the channel's coverage in 4–8 weeks for fixes.

Common pitfalls

Starting with a cron + Kanban pairing. The four bugs are blockers for production. Get a Story 1 Kanban working first, then layer a cron on top.
Using tmux instead of systemd. The tmux new -s hermes -d 'hermes gateway start' wrapper survives a logout ~50% of the time. Systemd is the real supervisor. On VPS, use systemd; on Mac, the in-platform supervisor.
Skipping the dedup check. Bug 3 will produce duplicate parent tasks and the cron will fire twice. The dedup check is a one-time setup; not implementing it is a guaranteed production bug.
Forgetting the daily gateway audit. A dead gateway on a VPS leaves child tasks waiting on the parent forever. The audit is the difference between a 24/7 pipeline and a 24/7 zombie.
Reading "block" as "delete." The dashboard lets you block tasks but not delete them — task accumulation is a real concern until the delete button ships. Block old task sets weekly to declutter the UI.
Letting the cron fire on a test run. Disable the cron before any test; re-enable after. Bug 2 is a cron-edge-case that the cron itself does not know about.
Using hourly cron for news monitoring. The §7.2 blueprint's data: 30% of hourly runs return <5 new items. 6-hour is the sweet spot for news; daily for comprehensive reports.
Reading the four bugs as a reason not to use cron + Kanban. The bugs are known, not unfixable. The fixes are documented in the source video and in this article. The cron + Kanban pairing is production-grade with the fixes; the bugs only bite the unprepared.
Skipping the manual profile creation per assignee. Cron + Kanban requires a profile per assignee — researcher, editor, publisher. The dashboard does not auto-create profiles; manual hermes profile create <role> is required.
Trusting the 9-worker speedup without measurement. The "9 parallel workers" framing is the unique worker count, not the task count. Measure the wall-clock on your specific pipeline before claiming a speedup; the speedup depends on the slowest worker.

Sources

Hermes Agent Kanban + Cron Job is POWERFUL (Setup Guide) — 5,119 views · video_id: iN2fD36Sgdg · cited: 14-step sequential vs. 9-worker parallel pipeline, 4 known bugs (gateway exits early, duplicate parent tasks, no cron-to-Kanban dedup, task accumulation), systemd fix, dedup-check workaround, "start with non-cron project" recommendation
Hermes Agent Kanban UPDATE: Multiple Boards Setup — 3,350 views · video_id: fKoPRL0dhyk · cited: daily gateway audit, audit-the-gateway rule, "child task will forever wait for the parent task" failure mode
Source MD — /home/ubuntu/boxai3/docs/courses/_archive-2026-06-18/03-hermes-agent.md §3.3.2 (kanban + cron, the pairing story), full. Every concrete claim in this article is sourced from §3.3.2: the 14-step vs 9-worker framing, the 4 bugs, the systemd fix, the dedup-check workaround, the "63 orphan children in a week" anchor, the "start with non-cron project" recommendation, and the daily gateway audit.
Cross-reference — Course 3 §3.3 §2 for the cron-pairing framing from the "what is Hermes" angle; Course 2: AI Models for the model-routing choices on a per-profile basis.