Agent Teams — Subagents, Kanban และสังคมของ BotsAgent Teams — Subagents, Kanban, and a Society of Bots

Imagine you could clone a competent colleague at will — except every clone is born with an empty memory, finishes exactly one task, and then vanishes forever. How do you assemble a team out of creatures like that, one capable of work bigger than a single context window?

That is the central question of every multi-agent system, and it is the same question I explored in the OpenClaw Agent Teams post of my OpenClaw for Organizations series — a world where you compose teams out of sessions, subagents, and gateway message routing, with many of the patterns hand-built. I run an OpenClaw deployment in real work, and I am now examining Hermes Agent from Nous Research seriously — curious how the harness that has collected close to 240,000 GitHub stars answers this question differently.

The short answer: Hermes does not have a multi-agent feature. It has four distinct layers, each solving a different problem — fork-join subagents, a durable SQLite Kanban board, a society of bots that DM each other, and multi-profile serving for a whole team on one machine. Following Hermes 101, this post is the map of all four, with every detail drawn from the official docs and release notes as of v0.21.0 (August 31, 2026).

1. The Four Layers of Multi-Agent Hermes

Before the tour, the map. Most of the confusion I see around multi-agent Hermes comes from mixing layers that were never the same thing. Each layer has its own tool surface, its own lifespan, and its own problem to solve:

The axis to hold onto is that durability climbs as you go down the table — a subagent dies with its session, a Kanban task survives restarts, and a profile is a permanent service-level identity. The layers also compose rather than compete: one bot (layer 3) can spawn subagents (layer 1) to clear a card on the Kanban board (layer 2), on a machine that serves the whole team (layer 4).

💡 The thing most often mistaken for a fifth layer: Mixture of Agents (MoA) is not delegation. The docs classify it as a "virtual model provider" — several reference models act as parallel advisors (no tool schemas) while a single aggregator writes the response and emits the tool calls, configured via moa.default_preset / moa.presets. MoA is many brains in one turn, not many agents doing many jobs.

2. delegate_task: Fork-Join Subagents with Fresh Contexts

The first layer is the delegate_task tool: the agent forks work off to a child with a conversation of its own. The delegation doc is explicit: "Each child gets a fresh conversation and works independently — only its final summary enters the parent's context." The child sees none of the parent's chat history, and the only thing that flows back is the final summary.

# Inside a session — the agent invokes this tool to fork work (pseudo-call)
delegate_task(
  task="Read all of src/billing and summarize the edge cases, citing files"
)
# The child starts from an empty conversation + the project context file only
# The single thing that returns to the parent: the final summary

What flows in, what flows out

The one exception to the empty-memory rule is project context: when a workspace exists, Hermes embeds a context file into every subagent's system prompt, resolved along the priority chain .hermes.md → AGENTS.md → CLAUDE.md → .cursorrules.

The defaults worth knowing

These numbers have shifted across versions before (some release notes quote different iteration ceilings than the docs), so treat the current doc as the authority. As of September 1, 2026, the documented defaults are:

# ~/.hermes/config.yaml — delegation defaults (per the docs, v0.21.0)
delegation:
  max_concurrent_children: 3    # env: DELEGATION_MAX_CONCURRENT_CHILDREN (floor 1, no ceiling)
  max_iterations: 50            # per child
  max_spawn_depth: 1            # flat by default — raise to 2+ for nested orchestration
  worktree_isolation: false
  orchestrator_enabled: true
  child_timeout_seconds: 0      # 0 = no hard timeout (30s floor if enabled)

From single tool to a small team

Three capabilities promote this layer from "temp help" to "small team":

• Batch dispatch — pass tasks=[...] and several jobs run in parallel, up to max_concurrent_children
• Nested orchestration — pass role="orchestrator" so a child can spawn its own workers (raise max_spawn_depth to 2+ first)
• Cheaper workers than the parent — set delegation.model / provider / base_url separately so children run on a lower-cost model

# Batch dispatch — three independent jobs, run in parallel
delegate_task(tasks=[
  "Analyze this week's logs for recurring error clusters",
  "Review PR #42 from a security angle only",
  "Compare library A vs B for the ingest job"
])

# Nested orchestration — a child that manages its own sub-team
delegate_task(
  task="Decompose the module refactor and manage a sub-team to completion",
  role="orchestrator"
)

The boundaries are as deliberate as the powers: subagents cannot talk to each other. The doc states "No direct messaging between subagents … all coordination flows through parent's reasoning," and leaf subagents lose a whole set of tools: delegate_task, clarify, memory, send_message, cronjob. An orchestrator gets delegate_task back — bounded by spawn depth — but inherits the other blocks, and both roles keep execute_code.

While children run, you have full visibility: /agents shows a live tree of every child (API call counts, current tool, last activity), /stop cancels background delegations, and a live transcript per task sits at ~/.hermes/cache/delegation/live/<delegation_id>/task-<n>.log.

3. Background Delegation and Live Steering

Originally delegate_task was purely synchronous — the parent sat and waited. The first turning point was v0.17.0 (June 19, 2026), which added background=true: dispatch, get a handle back immediately, and keep working. Per the release notes, "The full result re-enters the conversation as a new turn the moment it finishes."

The second turning point arrived in v0.21.0 (August 31, 2026) under the headline "Steer your subagents while they run": delegate_task gained live orchestration — list running children, steer one mid-flight with a course correction, or stop it early and keep the partial result — plus optional JSON-schema validation on child outputs and per-delegation cost surfaced in results.

# v0.17.0+ — dispatch in the background, handle returned immediately
delegate_task(task="Crawl the whole doc set and build an index", background=true)

# v0.21.0+ — live orchestration while children are still running
delegate_task(action="list")                        # which children are running?
delegate_task(action="steer", subagent_id="abc123",
              message="Skip legacy docs; focus on the v2 API only")
delegate_task(action="stop",  subagent_id="abc123") # stop early, keep partial result

For background jobs that hang, an always-on stall monitor watches: quiet for more than 450 seconds (1,200 seconds while inside a tool call) counts as stalled, with a 120-second grace window to unwind, and structured metadata reporting the stall phase. The hard wall-clock cap (child_timeout_seconds) is opt-in and off by default — and background results persist in the profile's state.db across restarts.

One footnote that captures how fast this project moves: mid-June 2026 third-party writeups (MarkTechPost, kno2gether) described a separate six-tool "async_delegation" surface — delegate_task_async, check_task, steer_task, and friends. None of those names survive in the current official doc; the whole surface appears to have been consolidated into delegate_task itself between June and September. If an older tutorial names tools you cannot find, that is why.

4. Worktree Isolation: Parallel Work Without Collisions

The classic failure mode of several agents in one repo is editing the same files at once. Hermes answers this at two distinct levels that people routinely conflate — and the internet is genuinely confused about their history, so let me untangle both.

CLI-session level — hermes -w

The first level is running several Hermes processes in parallel terminals: the git worktrees doc promises that "every invocation gets its own worktree and branch automatically" — each hermes -w run gets a temporary git worktree under .worktrees/ with an isolated branch.

# CLI-level parallelism — one worktree per terminal, no collisions
hermes -w                      # every invocation gets its own worktree + branch
/worktree new my-experiment    # creates .worktrees/my-experiment/ on branch hermes/my-experiment

# Open several terminals, run several Hermes processes in parallel
# Checkpoint history and /rollback are scoped per worktree

This feature is older than many articles claim: the request is issue #652, opened March 8, 2026, and it was documented by mid-March. The oft-repeated claim that it "shipped in v0.8.0" does not hold up against primary sources — v0.8.0 (April 2026) shipped only "aggressive worktree and branch cleanup." The mid-session /worktree command, which the docs describe as "Inspired by Copilot CLI," was added to the docs in mid-August 2026.

Subagent level — delegation.worktree_isolation

The second level is newer and finer-grained: flip delegation.worktree_isolation: true (default false) and every subagent from section 2 gets its own git worktree at <repo>/.worktrees/subagent-<id> on branch hermes-subagent/subagent-<id>, branched from current HEAD (the doc credits the inspiration to Muse Code's --subagent-worktree-isolation). Clean, commit-less worktrees are pruned automatically.

# ~/.hermes/config.yaml
delegation:
  worktree_isolation: true   # default: false

# Each child's result gains a "worktree" field:
#   path:    <repo>/.worktrees/subagent-<id>
#   branch:  hermes-subagent/subagent-<id>
#   commits ahead of base / dirty / pruned

5. Hermes Kanban: A Durable Task Board Your Agents Share

Everything in the previous two sections shares one weakness: it dies with the session. Close the process and the sub-team evaporates. That is the gap Hermes Kanban was built to close — first shipped in v0.13.0 (May 7, 2026) under a headline that names the problem precisely: "Multi-agent Kanban — delegate to an AI team that actually finishes."

The heart is a single SQLite database at ~/.hermes/kanban.db. The docs compress the philosophy into one line: "Every task is a row … every handoff is a row anyone can read and write." Work is not state floating in some agent's head — it is rows any profile can inspect.

The dispatcher mechanics

A dispatcher embedded in the gateway (kanban.dispatch_in_gateway: true) wakes every 60 seconds to (1) reclaim tasks whose worker heartbeat has been silent for over 4 hours, (2) promote tasks whose dependencies have cleared, and (3) atomically claim ready tasks and spawn workers as full OS processes: hermes -p <assignee> chat -q <prompt>, with injected KANBAN_GUIDANCE and environment variables like HERMES_KANBAN_TASK, HERMES_KANBAN_DB, HERMES_KANBAN_WORKSPACE, HERMES_PROFILE, and HERMES_TENANT so each worker knows its own context.

# ~/.hermes/config.yaml — the main Kanban knobs (documented defaults)
kanban:
  dispatch_in_gateway: true
  dispatch_interval_seconds: 60          # dispatcher tick
  dispatch_stale_timeout_seconds: 14400  # 4h — reclaim tasks from silent workers
  failure_limit: 2                       # per-task circuit breaker
  max_in_progress: ~                     # default: unlimited board-wide
  max_in_progress_per_profile: ~
  auto_promote_children: true

The protocol workers must honor

The board's reliability comes from a strict protocol: a worker must end its run with exactly one of kanban_complete, kanban_request_review, or kanban_block. Exit without one and the task is classified crashed / gave_up / timed_out, with up to 2 automatic nudges and a bounded retry budget (default: 3 consecutive protocol violations and you are out). The release notes summarize the machinery as "Heartbeats, reclaim, zombie detection, retry budgets, and a hallucination gate keep the team honest."

Kanban-side orchestrators work purely through creation verbs — decomposing goals into child cards and wiring dependencies, with no implementation tools in hand:

# An orchestrator fans a goal out into child cards, wired with parents
kanban_create(title="Collect the v0.21.0 changelog", assignee="researcher")
kanban_create(title="Draft the internal announcement from it",
              assignee="writer",
              parents=["<task-id-of-the-first-card>"])
# Child cards automatically receive "## Parent task results"
# (the parent's summary + metadata) in their worker context

Each card picks one of three workspace kinds: worktree (a git worktree at .worktrees/<id>/, preserved on completion), scratch (deleted on completion), or dir:<path> (shared, preserved). And goal-mode cards (--goal / goal_mode=True with --goal-max-turns) run a Ralph-style loop confined to a single card, an auxiliary judge checking output against acceptance criteria every turn — when the budget runs out before the criteria pass, the card blocks for human review instead of failing silently.

Kanban vs delegate_task — the official comparison

The docs compare the two layers head-on; here is the substance of that table:

The docs also codify 8 collaboration patterns — fan-out, pipeline, voting/quorum, long-running journal, human-in-the-loop, @mention, thread-scoped workspace, and fleet farming (the docs' example: one profile running 50 social accounts) — plus soft multi-tenancy via --tenant: "One specialist fleet can serve multiple businesses (--tenant business-a) with data isolation," each tenant getting its own workspace path and memory key prefix.

You can even run the board from your phone: every verb is reachable as /kanban from any gateway platform (Telegram, Discord, Slack, WhatsApp, Signal, Matrix, and more), and the originating chat auto-subscribes to the task's terminal events — choose plain notify, notify+wake, or wake so the agent rouses itself to act when a task completes, blocks, or crashes.

6. Bot Mode: Named Agents, Group Chats, and Peer DMs

The third layer is what makes "a society of bots" in this post's title literal rather than a metaphor. Bot Mode began life as a one-day public beta plugin by Teknium (a Nous co-founder), was — per MarkTechPost's reporting — bundled default-on in Hermes Desktop around v0.20.3 in mid-August, and was formalized in v0.21.0 "The Pantheon Release" (August 31, 2026), which describes it as "a society of named agents with their own faces and group chats, where your bots talk to each other — and to you — like a team, not a toolbox."

A Bot is a Profile

The one sentence to remember: a Bot IS a Hermes profile — isolated config, memory, skills, credentials, and chat history under ~/.hermes/profiles/<name>/. You can pin a model/provider per bot, write its persona in a SOUL.md, and enable skills, toolsets, and MCP servers per bot. Everything has CLI parity: hermes -p <bot> chat, hermes profile create, hermes cron list. A bot's recurring "routines" are plain Hermes cron jobs namespaced as [bot:<name>] <routine>.

message_agent and group chats

Bots DM each other through the message_agent tool (gated by agent.bot_mode_protocol: true, injected automatically in canonical Bot Chats): delivery is fire-and-forget, with the reply arriving as a background completion notification. A failed delivery retries at most once, with typed failure reasons such as provider_auth_or_access, provider_quota_limit, and context_overflow.

# One bot messaging another
message_agent(target="researcher",
              message="Give me the 5 latest bullets on A2A adoption")
# Fire-and-forget: the reply arrives as a background completion notification
# On failure: at most 1 retry, with a typed failure reason

Group chats are engineered against flooding: each send triggers at most 3 serial rounds of member turns, capped at 10 messages, and a bot "replies only when it has something new to add and passes otherwise" — with @user always available to escalate to a human. Rooms can span machines via the Desktop relay.

Peers and A2A — across machines, across harnesses

No Desktop? Gateways can talk to each other directly over the api_server platform with a strong key:

# Gateway-to-gateway, no Desktop required
hermes peer add spark --url http://spark.lan:8377 --key <API_SERVER_KEY>
hermes peer dm spark "Summarize the latest pipeline status for me"
hermes peer run spark "deploy staging" --idempotency-key deploy-20260901

# Peer keys live in ~/.hermes/.env as HERMES_PEER_<NAME>_KEY
# URLs sit under bot_peers in config.yaml

And for the world beyond Hermes: v0.20.0 "The Herald Release" (August 3, 2026) bundled an A2A v1.0 plugin — closing issue #514, which the release notes call "one of the oldest open feature requests in the repo" — so Hermes can "discover, talk to, and be driven by other A2A-compatible agents," alongside signed (HMAC) outbound lifecycle webhooks. Heterogeneous multi-agent systems that mix harnesses finally get a standard wire protocol to meet on.

7. Always-On Work: cron Jobs vs Session Heartbeats

A good team does not only work when commanded. Hermes has two "wake yourself up" mechanisms with exactly opposite philosophies — and picking the wrong one is the classic beginner's bug.

cronjob — durable but isolated

The cronjob tool (actions: create / list / update / pause / resume / run / remove) accepts schedules in four dialects, and the gateway daemon ticks the scheduler every 60 seconds:

# The schedule forms cronjob accepts — pick one
cronjob(action="create", schedule="in 30m",          prompt="...")  # relative one-shot
cronjob(action="create", schedule="every 2h",        prompt="...")  # interval
cronjob(action="create", schedule="weekdays at 9am", prompt="...")  # natural language
cronjob(action="create", schedule="0 9 * * *",       prompt="...")  # cron expression

Every run happens in a fresh, isolated session — no chat history comes along. And to stop an agent from scheduling itself into infinity, cron-management tools are disabled inside cron executions (override: cron.allow_agent_scheduling, default false), with concurrency capped by cron.max_parallel_jobs.

Isolated does not mean amnesiac — two mechanisms carry memory across runs:

• continuity=True — injects the job's own most recent output into each subsequent run (ideal for scouts that must deduplicate what they already reported)
• context_from="<job_id>" — chains jobs: Job A's latest output becomes context for Job B

# A recurring scout that remembers its last round and posts to a team thread
cronjob(action="create",
        schedule="every 6h",
        prompt="Scan for new multi-agent papers; reply [SILENT] if nothing new",
        continuity=True,                    # remembers last output — no repeats
        deliver="telegram:-100123456:42")   # chat_id:thread_id addressing

Delivery is flexible: deliver accepts origin (the default on messaging platforms), local, telegram / discord / slack / email / sms, all, and bot-chat — and a final response of [SILENT] suppresses delivery entirely. Pure-script jobs run with no_agent=True, no LLM invoked at all. And v0.21.0 just fixed the layer's oldest weakness under the headline "Cron jobs that remember": cron agents now load and update persistent memory, and get a durable notepad scratchpad of their own.

/heartbeat — in-context but mortal

The opposite pole is the session heartbeat: a prompt that re-enters the current session on a cadence, with the full conversation history in view — but requiring a live process to come home to.

/heartbeat every 10m Check the Kanban board — any cards stuck in blocked?
# Minimum 60s · runs only while idle, never interrupts active processing
# Missed ticks are coalesced into one
# State persists in SessionDB.state_meta under heartbeat:<session_id>

8. Serving a Whole Team: Profiles, Gateways, Allowlists

The first three layers are agents working with agents. The last layer answers the question organizations ask me most often: can one machine serve many people, in many roles? Hermes' answer is yes — by composing profiles, gateways, and allowlists.

One profile per role

The default is one gateway process per profile — the docs' example: "A personal assistant on one Telegram bot and a coding agent on another." The payoff is hard crash-domain isolation, and each profile installs as a permanent service with hermes -p <name> gateway install (generating the systemd unit or LaunchAgent for you).

Multiplexing — one gateway, many profiles

If you would rather not spend a process per role, opt in to sharing:

# ~/.hermes/config.yaml — one gateway process serving several profiles
gateway:
  multiplex_profiles: true
  profile_routes:
    - platform: discord
      guild_id: "111111"
      profile: research-team     # the whole guild → this profile
    - platform: discord
      chat_id: "222222"
      profile: ops               # more specific than guild → wins
    - platform: telegram
      thread_id: "333"
      profile: finance           # most specific: thread beats chat beats guild
# Credentials are never unioned · session keys are namespaced per profile
# A duplicate bot token across profiles fails at startup

Routing is most-specific-first (thread_id beats chat_id beats guild_id). And the detail I like most with my security hat on: the docs guarantee credentials "are never unioned into a shared environment" — sharing the process does not merge the privileges, and duplicate tokens are caught at startup, not at incident time.

Multi-user on a single platform

The other axis is one bot serving a whole team. The team Telegram assistant guide lays out the pattern: each person gets their own conversation session, access is controlled one of two ways, and a shared home channel receives scheduled output:

# Option 1 — static allowlist
TELEGRAM_ALLOWED_USERS=1001,1002,1003

# Option 2 — DM pairing codes (expire in 1 hour)
hermes pairing approve telegram <CODE>
hermes pairing list
hermes pairing revoke telegram <USER>

# The team's shared channel for scheduled output
TELEGRAM_HOME_CHANNEL=@team-agent-output   # or type /sethome in the chat

9. Choosing the Right Layer

Nous publishes an official delegation patterns guide naming five patterns: Parallel Research, Code Review (an audit with fresh-context eyes — the same principle behind the /review command, which spawns a background subagent over the last 10 messages), Compare Alternatives, Multi-File Refactoring ("split a large refactoring task across parallel subagents, each handling a different part of the codebase"), and Gather Then Analyze.

The same guide's rules of thumb: delegate reasoning-heavy subtasks and anything that would flood the parent's context, plus independent parallel workstreams — but purely mechanical work is cheaper as a direct execute_code call. Most important of all: delegation is "tied to the owning session and Hermes process" — work that must survive a closed session belongs in cronjob or terminal(background=True).

My own decision ladder condenses to this:

• Fits in one session, parallelizable → delegate_task (turn on worktree isolation if children touch the same repo)
• Spans days, needs an audit trail and human review → the Kanban board
• A persistent multi-role team that talks to itself, across machines → Bot Mode / hermes peer / A2A
• Many people on one machine → profiles + a multiplexed gateway + allowlists
• Work on a clock → cronjob · self-reminders in an open session → /heartbeat

A closing observation, as someone who operates an OpenClaw deployment: what Hermes adds to the multi-agent picture is not smarter individual agents but durability of team structure. Kanban turns the ephemeral subagent into a row in SQLite that a human can comment on and unblock at any point — precisely the piece that the patterns I described in my OpenClaw agent-teams post still had to be assembled by hand. As for how these teams manage what they remember — that is the entire subject of post #3 in this series.