The §7.3 article covered the Kanban's core features; the §7.4 article covered the cron pairing. This article is the multi-board update — the most recent Kanban release in the channel's coverage, and the one that exposes the load-bearing discipline the entire multi-agent pattern depends on: naming. Each Kanban board runs against its own SQLite database, workspace directory, logs, and HERMES_KANBAN_BOARD env var — workers only see their own board. That isolation breaks the moment two boards share a profile name like researcher or editor. The fix is naming discipline: every profile name must be project-scoped (ai_researcher, not researcher) or context bleeds across boards and the agent loses track of which project it is serving.

This article walks through the multi-board update, the first-class Profiles section, the parent-child retry loop (cross-referenced from §7.3), and the naming discipline rule that is the anchor of the article.

What you'll learn

  • The multi-board update adds a hermes kanban boards subcommand, a New Board UI button, and a first-class Profiles section with a one-click "Copy CLI command".
  • Each board runs against its own SQLite database, workspace directory, logs, and HERMES_KANBAN_BOARD env var — workers only see their own board. The isolation is structural, not just a UI nicety.
  • The isolation breaks the moment two boards share a profile name. The rule: name profiles per project (ai_researcher, crypto_researcher, sports_researcher), not generically (researcher).
  • The first-class Profiles section exposes a per-profile soul.md editor and a Copy CLI command that drops you into nano of the right .env file. Profile management is no longer a terminal-only flow.
  • The parent-child retry loop (6 runs on Space Shooter, 81 runs on a separate test) is the killer feature from §7.3. The multi-board update preserves it; multi-board does not weaken the retry guarantee.
  • Audit every day on VPS. A dead gateway leaves child tasks waiting on the parent forever (cross-referenced from §7.4).

The update you cannot skip

The Kanban now ships with multiple boards, accessible from the dashboard via New Board or from the terminal with the hermes kanban boards subcommand (fKoPRL0dhyk). Before the update, only a single default board existed. As the creator shows on screen, trying to spin up a second board on the old build throws an error. If you see that error, your Hermes is on the old Kanban — run hermes update.

The first command to run after the update is hermes kanban boards — it lists the boards you have and confirms you are on the new build. If the command is missing, the update did not apply cleanly; rerun hermes update and check the changelog.

Profiles are now first-class

The same release adds a Profiles section for multi-agent setups (fKoPRL0dhyk). Each profile gets:

  • A one-click "Copy CLI command". Drops you into nano of the right .env file, so you no longer have to hunt for which API key belongs to which agent.
  • A per-profile soul.md editor. Edit the system prompt directly from the dashboard. Customise the persona, the instructions, the format expectations — all without editing the YAML.
  • A per-profile inference provider and API key. Set the model and the key per profile, not per board. The mixed-model strategy from §7.2 is now a UI feature, not a hand-edit.

The creator's point: these are persistent agents with memory and system prompts, not the disposable sub-agents you get from an orchestrator — sub-agents "get spawned, they do their job, and then they're gone" (fKoPRL0dhyk).

The structural difference: a Kanban profile is a role with a soul; a sub-agent is a task with a prompt. The role persists across tasks; the task does not.

Why the parent-child link matters

The Kanban's core advantage over a normal orchestrator/sub-agent flow is the parent-child dependency. If a run fails midway, the Kanban retries (fKoPRL0dhyk). The creator logged a Space Shooter game build that took 6 runs before he terminated it, and remembers another test that hit 81 runs before succeeding.

A vanilla orchestrator would have notified him and stopped at run 1. The Kanban kept going — the 81st run produced the artefact, and the Worker Logs show the 80 failure modes that preceded it. The full history lives under Worker Logs in the Kanban UI — check it before assuming a pipeline is broken.

This is the cross-reference anchor to §7.3. The parent-child retry loop is the Kanban's killer feature, and the multi-board update does not weaken it. Each board has its own parent-child dependency graph; the retry guarantee is per-board, not global.

Isolation requires naming discipline

This is the anchor of the article. Each board runs against its own SQLite database, workspace directory, logs, and HERMES_KANBAN_BOARD env var — workers only see their own board (fKoPRL0dhyk). That isolation is structural: the database, the workspace, and the env var are all per-board, so a worker that fires on board A has no visibility into board B.

The isolation breaks the moment two boards share a profile name. The structural reason: the profile name is the namespace for the worker logs, the SQLite queries, and the parent-child dispatch. Two boards with a profile called researcher will see each other's worker logs, will dispatch children under the same namespace, and the parent-child dependency graph will be ambiguous — is the parent on board A or board B?

The creator's rule (fKoPRL0dhyk):

Name profiles per project. ai_researcher, crypto_researcher, sports_researcher — not researcher.

The discipline is not optional. Two boards with a researcher profile will see each other's context. The agent loses track of which project it is serving. The worker logs become a tangled mess. The parent-child dispatch starts misrouting children to the wrong parent.

The discipline applies to all profile names, not just researcher. Every role on every board must be project-scoped:

  • ai_news_researcher — not researcher
  • ai_news_editor — not editor
  • ai_news_publisher — not publisher
  • crypto_researcher — not researcher
  • crypto_analyst — not analyst

The pattern is <project_slug>_<role>. The project slug is the namespace; the role is the function. Two profiles with the same role on different projects are unambiguous because the project slug is in the name.

Why naming discipline is the load-bearing rule

Three structural reasons naming discipline is the load-bearing rule (fKoPRL0dhyk):

  1. Worker log isolation. A researcher profile on board A produces worker logs under the namespace researcher. A researcher profile on board B produces worker logs under the same namespace. The Worker Logs UI cannot distinguish them; the audit trail is meaningless.
  2. Parent-child dispatch. The parent-child dependency graph is keyed by profile name. Two researcher profiles on different boards will produce ambiguous dispatch — the gateway cannot tell which researcher is the parent of which child.
  3. Cross-board context bleed. The HERMES_KANBAN_BOARD env var isolates workers per board, but the profile name is the cross-board identifier. Two researcher profiles share the same cross-board namespace, and the isolation breaks down.

The discipline is the only rule the channel has named that has cross-board consequences. Every other rule in the Kanban is per-board; naming discipline is per-deployment.

The per-profile soul.md editor

The first-class Profiles section exposes a per-profile soul.md editor (fKoPRL0dhyk). The editor is a small textarea in the dashboard that saves directly to the profile's SOUL.md file. The point: profile customisation is no longer a terminal-only flow.

The use case the channel flagged: a crypto_researcher profile with a soul.md that names the specific coins and exchanges the project cares about, a crypto_analyst profile with a soul.md that names the specific on-chain metrics the project tracks, etc. The per-profile soul.md is the role-specific persona; the parent agent's soul.md is the project-wide persona.

The two-level persona structure:

  • Parent agent's soul.md — the project-wide persona, the meta-context, the cross-project rules
  • Profile's soul.md — the role-specific persona, the task-specific rules, the per-profile instructions

The structure composes. The parent agent knows the project; the profile knows the role. The dispatch is unambiguous: project → role → task.

The Copy CLI command

The Copy CLI command is the small but load-bearing UI feature (fKoPRL0dhyk). Click the button next to a profile in the dashboard, and the right command — typically nano ~/.hermes/profiles/<name>/.env — is on your clipboard. Paste it into a terminal, edit the file, save. The command is profile-specific; you no longer have to remember which .env file belongs to which agent.

The friction it removes: with 5+ profiles on a board, hand-tracking which .env is which is a real source of errors. The Copy CLI command makes the per-profile .env management a one-click flow, and the per-profile inference provider is right there in the same file. Set the model and the key in the same edit; the next dispatch picks up the new routing.

Audit every day on VPS

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." Lazy users can audit weekly, but on a VPS the audit is the difference between a 24/7 pipeline and a 24/7 zombie.

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. Cross-referenced from §7.4.

What multi-board does not fix

Three things the multi-board update does not fix (fKoPRL0dhyk):

  • The four cron bugs from §7.4. Gateway exits early, duplicate parent tasks, no cron-to-Kanban dedup, task accumulation — all four persist. The multi-board update is orthogonal to the cron pairing.
  • The "no delete" UI gap. The dashboard still lets you block but not delete tasks. Task accumulation is still a real concern.
  • The "no native dedup" gap. The agent still does a manual dedup check before spawning. The native dedup has not shipped.

The multi-board update is a board-management improvement, not a cron-management improvement. If your problem is cron + Kanban, the §7.4 bugs are still the blockers.

Try it yourself

The hands-on goal: stand up a multi-board setup with three boards, prove the per-board isolation, and verify the naming discipline rule by inspecting the worker logs.

  1. Run hermes update. Confirm hermes kanban boards is present. If not, the update did not apply cleanly.
  2. Create three boards with project-scoped names. ai-news, food-tracker, boxminingai-site. The board names are the namespace for the per-board isolation.
  3. Create project-scoped profiles on each board. On ai-news: ai_news_researcher, ai_news_editor, ai_news_publisher. On food-tracker: food_tracker_logger, food_tracker_analyst. On boxminingai-site: boxminingai_researcher, boxminingai_writer. No generic profile names.
  4. Set the inference provider and API key on each profile. Use the Copy CLI command to drop into nano of the right .env file. Set the model and the key per profile.
  5. Smoke-test the per-board isolation. Drop a task on ai-news and verify the worker logs are under ai_news_researcher, not researcher. Drop a task on boxminingai-site and verify the worker logs are under boxminingai_researcher, not researcher. The two profiles should have no cross-visibility.
  6. Run the naming-discipline test. Try to create a profile called researcher on a second board. The dashboard should warn you about the namespace collision. If it doesn't, you are on the old build.
  7. Audit the worker logs. Confirm the worker logs are per-board and per-profile. Two boards with project-scoped profiles have unambiguous worker logs; two boards with generic profiles have a tangled mess.
  8. Audit the gateway daily. 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.
  9. Re-evaluate the four cron bugs. The multi-board update does not fix Bug 1-4 from §7.4. Re-check the channel's coverage in 4–8 weeks for fixes to the cron pairing.

Common pitfalls

  • Using generic profile names. researcher, editor, publisher are not acceptable on a multi-board setup. The naming discipline rule is: <project_slug>_<role>. Two boards with a generic profile will see each other's context.
  • Skipping hermes update. If hermes kanban boards is missing, you are on the old Kanban — the multi-board UI will throw on board #2.
  • Forgetting the per-profile inference_provider. Each profile is a separate agent with its own inference_provider and API key. The parent agent's key is not inherited. Set the model and the key on every profile by hand.
  • Editing SOUL.md in the terminal instead of the dashboard. The first-class Profiles section has a per-profile soul.md editor; use it. Hand-editing the file in the terminal works, but the editor is the documented UI.
  • Reading "multi-board" as a fix for the cron bugs. The multi-board update is orthogonal to the cron pairing. Bug 1-4 from §7.4 are still the blockers for production-grade cron + Kanban pipelines.
  • Skipping 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.
  • Trusting "block" to clean up. 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.
  • Running multi-board on a single-board use case. The multi-board update is a board-management improvement. If you only have one project, the multi-board UI is overhead you do not need. Stay on the single-board setup from §7.3.
  • Sharing the Copy CLI command across profiles. The Copy CLI command is profile-specific — it points to the right .env file. Pasting the command from profile A into profile B's edit will edit the wrong file. The Copy CLI command is a per-profile handle.
  • Reading the parent-child retry loop as a board-level feature. The retry loop is per-board, not global. Each board has its own parent-child dependency graph; the retry guarantee is per-board. Two boards with the same project-scoped profile have separate retry histories.

Sources

  • Hermes Agent Kanban UPDATE: Multiple Boards Setup — 3,350 views · video_id: fKoPRL0dhyk · cited: multi-board update, hermes kanban boards subcommand, first-class Profiles section, per-profile soul.md editor, Copy CLI command, 6-run Space Shooter build, 81-run test, daily gateway audit, naming discipline rule (ai_researcher not researcher)
  • Hermes Agent Kanban Setup Guide (Multi-Agent Task Board) — 16,341 views · video_id: R_aLVXYzDac · cited: profile directory tree, artefact output path, 4 use cases (Story 1-4)
  • Hermes Agent Kanban + Cron Job is POWERFUL (Setup Guide) — 5,119 views · video_id: iN2fD36Sgdg · cited: 4 known cron bugs (gateway exits early, duplicate parent tasks, no cron-to-Kanban dedup, task accumulation)
  • Source MD — /home/ubuntu/boxai3/docs/courses/_archive-2026-06-18/03-hermes-agent.md §3.3.3 (multi-board update), full. Every concrete claim in this article is sourced from §3.3.3: the multi-board subcommand, the New Board UI button, the first-class Profiles section, the per-profile soul.md editor, the Copy CLI command, the 6-run Space Shooter build, the 81-run test, the daily gateway audit, the per-board isolation (SQLite database, workspace directory, logs, HERMES_KANBAN_BOARD env var), and the naming discipline rule (ai_researcher not researcher for cross-project isolation).
  • Cross-references — §7.3 for the parent-child retry loop; §7.4 for the four cron bugs; Course 3 §3.3 §3 for the multi-board framing from the "what is Hermes" angle.