Learning Objectives
  • Know when a quick delegated call is enough, and when you need the Kanban board instead.
  • Understand Auto vs Manual orchestration and what the decomposer actually does.
  • Walk through a working multi-agent research pipeline, profiles, models, and the prompt that reliably fans it out.
  • Find and read the output of a running or completed task.

Why Split Work Across Agents

One agent trying to hold several personas or modes at once tends to drift. Splitting work across narrowly scoped profiles fixes that, and brings a few other benefits along for free.

01

Focus. A profile scoped to one job, facts only, no speculation, stays on task better than one agent juggling several roles.

02

Parallelism. Two profiles researching independently run at the same time. A single agent is architecturally sequential, one reasoning stream at a time.

03

Fault isolation. If one worker crashes, only its task blocks, not the whole pipeline.

04

Matching model to task. A cheap, fast model for a simple judgment call, a stronger one only where it's actually needed, rather than paying premium rates for every step.

$ Cost efficiency falls out of specialization, it isn't the main reason to split work, but it's real. MCP connections and toolsets are scoped per profile too, so a narrowly configured worker also carries a smaller context footprint than one profile trying to do everything.

delegate_task vs the Kanban Board

Hermes gives you two different ways to hand work to another agent. They solve different problems.

Aspect delegate_task Kanban board
Shape A function call A work queue
Blocking Parent blocks until the subagent returns Fire-and-forget
Identity Anonymous, in-memory subagent Named profile, its own OS process
Durability Result lost once the conversation compresses Resumable after a crash, full audit trail
Best for A quick reasoning answer inside one conversation Work that crosses agent boundaries or needs a human in the loop

The Kanban board is a durable task board, backed by a single SQLite database and shared across all profiles on a machine. Every task is a row, every handoff is a comment anyone can read.

Auto vs Manual

This setting answers one question: does the board split work across agents on its own, or do you have to do it yourself?

01

Auto (default)

Drop a task into Triage and the dispatcher's decomposer reads your profiles' descriptions and fans the goal into a task graph on its own. The "drop a goal, walk away" flow.

02

Manual

Tasks sit in Triage until you click Decompose on the card, or run hermes kanban decompose <id>.

Routing quality in Auto mode depends on each profile having a description of what it's good at. Fill these in, or use hermes profile describe <name> --auto to generate one from its SOUL.md, rather than leaving them blank.
!
A vague, single-threaded goal often decomposes into just one worker. To force real parallel behavior, be explicit:
  • Ask for multiple independent subtasks
  • Ask for parallel work
  • Ask for different angles
  • Ask for a final synthesis step

A Working Research Pipeline

One goal fans out into two parallel research tracks, which converge into a synthesized answer, then get judged for completeness.

goal dropped into Triage agent-orchestrator owns root task, fans out agent-literal factual research track agent-creative perspective research track agent-summarizer synthesizes both into one brief judges completeness
Profile Model Role
agent-literal gpt-5.4-mini Verified facts and documented detail only, no speculation.
agent-creative gpt-5.4-mini Differing expert opinions and open debates, actively seeks disagreement.
agent-summarizer gpt-5.4 Reconciles overlaps, flags contradictions instead of picking a side.
agent-orchestrator gpt-5.4-nano Judges whether the combined output actually answers the goal. Nano tier, this is a simple judgment call, not deep reasoning.

In the Kanban dashboard's Orchestration settings: Orchestrator Profile set to agent-orchestrator, Auto-decompose on, so a task dropped in Triage fans out automatically.

Config gotcha: decomposer defaulting to no key
Auxiliary decomposer and triage helpers don't inherit the main model by default. Without an explicit auxiliary.kanban_decomposer.provider: main in config.yaml, they can default to a provider with no key configured. Pin model.default explicitly per profile too, and verify with hermes -p <profile> doctor rather than trusting the dashboard after rapid edits.

A prompt that reliably forces the split

Paste into the Triage task's Title field, there's no separate body box:

Prompt
Research a topic using two independent tracks, then synthesize.

1. Factual track:
   - Verified facts, documented technical details, definitions
   - Confirmed capabilities only, no speculation
   - If something is disputed or unconfirmed, say so plainly

2. Perspective track:
   - Differing expert opinions, open debates, controversies
   - Speculative angles, actively seek disagreement

Once both tracks are complete, synthesize into one cohesive brief:
   - Reconcile overlaps
   - Flag direct contradictions explicitly
   - Produce a single neutral-toned summary of what's known versus what's debated

Finding Task Output

From the dashboard or the CLI, take your pick.

CLI
hermes kanban show <task_id>    # status, assignee, diagnostics, latest_summary
hermes kanban tail <task_id>    # live progress stream
hermes kanban log <task_id>     # raw worker log, full error traces

In the dashboard, click a card for the same information rendered live, editable title, assignee, and priority, a dependency editor, a Result section once complete, and the comment thread. The board updates over WebSocket, no refresh needed. If a task looks stuck, click Nudge dispatcher instead of waiting for the next tick.

! A card marked "blocked" with "Agent crash x2" means the worker process exited abnormally twice, hitting its failure limit. Check hermes kanban log <task_id> for what it said right before dying, in practice this is usually a normal API error (auth, bad parameter, rate limit), not a mysterious crash.