--- title: How to Dominate Projects with the Hermes Agent Kanban Board summary: >- One agent is the wrong unit once work grows teeth. This field manual shows how to use Hermes Kanban — boards, tasks, claims, blocks, schedules, and receipts — to give long-running multi-agent work durable coordination that survives a dead shell. author: Tony authorUrl: 'https://x.com/tonysimons_' category: Orchestration difficulty: Intermediate readingTime: 5 date: '2026-06-17' tags: - kanban - orchestration - multi-agent - task-management - workflow - recovery integrations: - Hermes Kanban - CLI --- ## One agent is the wrong unit Long-running work has a quiet failure mode. A task can look "running" for forty minutes while the worker has already died, and another task can land on the wrong board because one shell was still pointed at an old slug. Nothing dramatic happens — the afternoon just leaks out through stale state, one plausible lie at a time. The context window isn't a manager. It's a box with limits. The fix isn't a smarter prompt; it's **a board, a contract, and receipts**. This flow is a practical field manual for using the Hermes Agent Kanban board to coordinate real, multi-step work across agents and humans. The core thesis from Tony: > One agent is fine until the work grows teeth. After that, you don't need a smarter chat — you need durable coordination. ## The context window isn't a manager Running real work inside one giant chat feels fast at the start: one prompt, one worker, one tidy stream of output. It falls apart once the work grows — the transcript gets long, someone wants parallel research, someone wants review, a worker crashes. The session ends up carrying half the project in prompt residue and half in hope. That's **context soup** — a memory leak with nice formatting. Hermes Kanban exists to make work survive that reality. It is not a fancier chatbot: - **Boards** isolate workstreams. - **Tasks** carry state. - **Profiles** name the worker shape. - **Parent links** define order. - **Workspaces** decide where files land. - **Runs, logs, and events** are the receipts. If you need to know what happened, who did it, how long it ran, and what the worker said before it finished, the board gives you that trail. The chat doesn't. ## Build the board like you mean it Don't over-design the first board. Start with the dumbest useful setup: \`\`\`bash hermes kanban boards show hermes kanban boards switch hermes-kanban-field-manual hermes kanban boards create hermes-kanban-field-manual \ --switch \ --default-workdir /home/tony/projects/hermes-kanban-field-manual \`\`\` - \`boards show\` tells you where you are. - \`boards switch\` moves the active board for subsequent calls. - \`boards create ... --switch --default-workdir ...\` gives the board a home so new work doesn't fall into a ghost pile of scratch output nobody can find later. That \`--default-workdir\` matters more than it looks. If the board knows where work should live, you stop asking "wait, where did the files go?" That's a path problem, not a philosophical one. If you're bouncing across shells, switch the board on purpose before you create anything. Now create something small enough to finish and loud enough to verify: \`\`\`bash hermes kanban create "Survey the source notes" \ --assignee hkg-researcher \ --workspace dir:/home/tony/projects/hermes-kanban-field-manual \ --max-runtime 30m \ --json \`\`\` Use \`--json\` when you care about the task id not getting buried in scrollback — for chained work, machine-readable output is the difference between a clean graph and a terminal full of vibes. If the request is still mush, park it in triage instead of pretending it's ready: \`\`\`bash hermes kanban create "Clean up the request" \ --assignee hkg-director \ --triage \ --json \`\`\` Use \`--triage\` for half-baked requests that need a spec before they need labor. Use \`--initial-status blocked\` when the work is real but you need a human decision before the worker can move. Treat runtime as real, not decorative: \`--max-runtime 300\` for a quick pass, \`--max-runtime 30m\` for a real survey, \`--max-runtime 2h\` for a draft or review gate. The point is to stop runaway tasks from squatting forever. ## Small contracts beat giant prompts This is what turns a chat into coordination. The pattern is **survey first, draft second**. A survey task collects facts, a draft task turns those facts into prose, a review task checks the handoff — and none of them re-litigate the whole project. \`\`\`bash hermes kanban create "Survey the source notes" \ --assignee hkg-researcher \ --workspace dir:/home/tony/projects/hermes-kanban-field-manual \ --max-runtime 30m \ --json hermes kanban create "Draft the article from the survey" \ --assignee hkg-writer \ --parent \ --workspace dir:/home/tony/projects/hermes-kanban-field-manual \ --max-runtime 2h \ --json hermes kanban create "Review for drift and repetition" \ --assignee hkg-reviewer \ --parent \ --workspace dir:/home/tony/projects/hermes-kanban-field-manual \ --max-runtime 30m \ --json \`\`\` Use \`--parent\` at creation time when you already know the dependency — the graph exists from birth. Use \`hermes kanban link \` after the fact when both tasks already exist or you're stitching an older graph back together. **\`--parent\` is creation-time intent; \`link\` is repair mode.** If you need a different worker shape, make a different profile instead of stuffing one profile full of every possible skill. Profiles aren't stickers — they're state boundaries. A survey worker, a writer, and a reviewer don't need the same assumptions just because their tasks live on the same board. ## Claim, block, schedule, then stop improvising This is the part that makes the board feel like a working system instead of a nice list. When a task lands, claim it. The TTL is a lease, not ownership — if the worker vanishes, the claim ages out instead of hanging around like a ghost: \`\`\`bash hermes kanban claim --ttl 900 \`\`\` If the task needs a decision before it can move, block it and say why. Blocking isn't failure; it's a clean admission that human input is the dependency: \`\`\`bash hermes kanban block "Need the source notes before drafting" \`\`\` If the only thing missing is time, schedule it instead of clogging the board with fake urgency: \`\`\`bash hermes kanban schedule "Waiting on answer at 3 PM" \`\`\` "Waiting on a person" and "waiting on the clock" are not the same thing — one needs a comment thread and patience, the other needs a reason to wake up later. When the upstream work is done, promote the card (use \`--force\` only when you intentionally override dependencies — it's a crowbar, not a lifestyle): \`\`\`bash hermes kanban promote "Survey complete, drafting can start" --json \`\`\` When the work is actually done, close it with a real handoff. The summary is for humans; the metadata is for downstream workers and future you: \`\`\`bash hermes kanban complete \ --summary "Drafted article-v5 from review notes" \ --metadata '{"changed_files":["drafts/article-v5.md"],"tests_run":0,"decisions":["kept title and opener","added lifecycle section","trimmed repetition"]}' \`\`\` Then archive the card if you want the board clean: \`\`\`bash hermes kanban archive \`\`\` That's the operating rhythm: create board, create task, claim, block or schedule if input or time isn't there, promote when the dependency clears, complete with metadata, archive when the story is over. ## Receipts beat vibes Dashboards can make you feel coordinated while the actual worker state is stale, stuck, or dead. When something smells wrong, don't guess — pull the state: \`\`\`bash hermes kanban show --json hermes kanban runs --json hermes kanban log --tail 4000 hermes kanban tail \`\`\` - \`show\` tells you the task, its comments, and its events. - \`runs\` tells you whether there was an actual attempt. - \`log --tail\` shows the last chunk of worker output without scrolling through a wall of noise. - \`tail\` follows the event stream if the task is still changing under your feet. Then check the actual process, because a card that says *running* isn't proof of life: \`\`\`bash pgrep -af 'hermes.*kanban.*' ps aux | grep 'hermes.*kanban' | grep '' \`\`\` If the board says running but there's no live process and \`runs\` doesn't show a healthy attempt, you probably have a stale lock or a dead worker. Don't debate the UI — reclaim it with a reason: \`\`\`bash hermes kanban reclaim --reason "stale lock, no live process" \`\`\` The full diagnostic sequence worth running before you panic: check the board, show the task, check runs, tail the log, follow events if state is still moving, check the live process table, and reclaim only if the board says one thing and the process table says another. ## The three dumb failures that keep eating afternoons Most Kanban pain is three dumb failures wearing different hats. **1. The wrong board.** You're moving fast across shells and one terminal is still pointed at an old board. The title looks right, the task id looks right, the work lands in the wrong queue anyway. That's why \`boards show\` and \`boards switch \` exist. Switch on purpose and stop trusting the accident of whatever shell you opened last. **2. The scratch ghost.** The worker finishes, the summary looks clean, then you go looking for the file and realize the output landed in scratch or some dead-end workspace nobody is watching. That's why \`dir:\` and a board default workspace matter. If output needs to land in a visible project tree, say so in the task — don't make the worker guess where reality lives. **3. The stale lock.** This one lies politely: the card says running, the dashboard feels alive, but the log stopped a while ago and the process table is empty. The receipts earn their keep here. If the board says running and the process table says dead, reclaim the task and give it a reason. Keep the states distinct — blurring them turns a system into a superstition machine: | State | Meaning | | --- | --- | | **Triage** | The spec is mush. | | **Blocked** | A human decision is missing. | | **Scheduled** | Time is the dependency. | | **Running** | A process is alive right now. | ## When NOT to use a board Honesty keeps the recommendation believable: **tiny one-shot tasks don't deserve a board. Everything else does.** Use chat for the small stuff — a one-off lookup, a quick edit, a help-text check, a tiny answer that finishes before the coffee cools. Wrapping ceremony around that isn't discipline, it's self-importance with extra clicks. Reach for a board when the work needs any of these: - parallel workstreams - review gates - crash recovery - durable handoff - specialist profiles - state that has to survive a shell dying on you - work that stretches across hours or days The cutoff in plain English: if the job ends before the espresso cools, keep it in chat. If it needs memory, gates, retries, or someone else picking it up later, put it on a board. ## The operator still owns judgment This part is non-negotiable. Agents can do work, recommend scope, carry out a contract, and hand off cleanly. They don't get to decide the brief, the sequencing, or whether the board is worth it. That's not a limitation — it's the design. - A task that needs a board gets split because **the human** decided it needs durable coordination. - A task that needs review gets gated because **the human** decided the output needs another set of eyes. - A task that needs time gets scheduled because **the human** decided the clock matters. - A task that's too small stays in chat because **the human** decided the ceremony isn't worth it. Even the ugly calls are human calls: block a draft that's missing source notes, schedule a job that just needs to wake up later, link or recreate a malformed graph, archive a dead task and start over. That isn't the agent being weak — it's the agent staying inside a contract. ## Wrapping up One agent is the wrong unit once the work needs parallelism, review, recovery, or durable handoff. After that point, the board isn't overhead — it's the thing that keeps the work alive. Receipts beat vibes, and durable coordination beats hoping one agent remembers everything. > This article was co-written by Tony's Hermes Agent. *Originally written by [Tony](https://x.com/tonysimons_).*