Hermes Agent Kanban UPDATE: Multiple Boards Setup

## The update you can't skip The Hermes agent Kanban now ships multiple boards, accessible from the dashboard via New Board, or from the terminal with the hermes kanban boards subcommand. Before this update, only a single default board existed — and as the creator shows on screen, trying to spin up a second board threw an error until he updated Hermes. If you see that error, your Hermes is on the old Kanban.

## Profiles are now first-class The same release adds a Profiles section for multi-agent setups. Each profile gets a one-click Copy CLI command that drops you into nano of the right .env file, so you no longer have to hunt for which API key belongs to which agent. You can also edit each profile's soul.md directly from the dashboard to customize the system prompt. 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."

## 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 — 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 just notified him and stopped. The full history lives under Worker Logs in the Kanban UI.

## Isolation requires naming discipline Each 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 creator's rule: name profiles per project (e.g. ai_researcher, crypto_researcher, sports_researcher) or context bleeds and the agent loses track of which project it's serving.

## Audit every day He runs a daily audit of the AI-news pipeline that verifies the gateway is up — critical on VPS, because if the gateway dies, the child task "will forever wait for the parent task." Lazy users can audit weekly.