hermes - 💡(How to fix) Fix feat: /swarm slash command for in-harness multi-agent orchestration

Feature Description

Add a /swarm slash command that lets users invoke the kanban multi-agent swarm from inside a Hermes session — no terminal escape, no manual --worker/--verifier/--synthesizer flags. The command parses a natural-language goal, decomposes it into a task graph via the auxiliary LLM, routes tasks to specialist profiles by their descriptions, creates the kanban swarm, and reports back.

Currently, invoking a swarm requires dropping to a shell and running:

hermes kanban swarm "goal" --worker researcher:"title" --verifier reviewer --synthesizer writer

This requires knowing every profile name, writing worker titles manually, and remembering the flag format. The /swarm command eliminates all of that — the user says /swarm Research X and write it up and the LLM handles decomposition and routing.

Motivation

The kanban swarm system (v1, shipped in v0.15.0) is Hermes's most powerful multi-agent orchestration primitive, but its UX barrier is high. The May 2026 blog post about kanban swarm explicitly called out: "This is still an explicit CLI action. There is no /swarm slash command inside a Hermes session" as a known gap.

This feature bridges the gap between the CLI power-user path and the in-session experience. All the infrastructure already exists — kanban_swarm.py:create_swarm(), the profile description system, the kanban decomposer's LLM routing — but there's no in-harness trigger that composes them.

The /swarm command would be the third tier in progressive disclosure:

• Tier 1: /swarm Research X — fully automatic (this feature)
• Tier 2: hermes kanban swarm --worker ... — CLI with manual control (exists today)
• Tier 3: kanban decompose + auto-dispatch — fully autonomous (gateway dispatcher)

Proposed Solution

A new module hermes_cli/kanban_swarm_command.py that implements the handler, plus a CommandDef registration and CLI dispatch wiring. The handler:

1. Parses the user's natural-language goal from the command arguments
2. Calls the auxiliary LLM (reusing the kanban_decompose pattern) to decompose the goal into a topology with profile assignments — passing the full profile roster (name + description) as context
3. Creates the swarm via the existing kanban_swarm.create_swarm()
4. Reports back with task IDs, the topology rationale, and estimated completion flow

The system prompt describes available topologies (full with verifier gate, or research-only with parallel workers only) and routing rules. Invalid profile names fall back to the default assignee, same pattern as kanban_decompose.py.

The module is already implemented and tested on the magnus919/hermes-agent-1 fork branch fix/aux-extra-body-passthrough:

• 292 lines in the handler module
• 317 lines of tests (16 tests, 3 test classes)
• All 16 tests pass locally and in clean-room Docker

How Competitors Do It

No direct competitors implement this exact pattern, but the closest analogs inform the design:

• OpenAI's Swarm (experimental Python framework) uses a function-calling approach where agents hand off to each other via tool calls — no persistence, no state machine, no human review gates. The kanban swarm's SQLite persistence and gated topology are fundamentally different design choices.

• LangGraph offers a state-machine approach to agent orchestration, but requires defining graphs explicitly in Python code — there's no natural-language-to-graph decomposition. The /swarm command's LLM-based decomposition is a higher-level abstraction.

• CrewAI uses role-based teams with a manager agent, but the topology is always manager→worker, not the flexible parallel-workers→verifier→synthesizer pattern that kanban swarm supports.

The /swarm command's approach — LLM decomposition + kanban persistence + existing dispatcher — is native to Hermes's architecture and differentiates from all three.

Alternatives Considered

1. CLI-only. Keep the existing hermes kanban swarm as the sole interface. Rejected because it requires knowing profile names and remembering CLI flag syntax — the blog post explicitly identified this as a UX gap.

2. A skill-based approach. Create a swarm-orchestration SKILL.md that walks the user through invoking the CLI. Rejected because skills can't create kanban tasks directly — they'd still need to drop to terminal.

3. Extend /goal. Make /goal optionally spawn a kanban swarm. Rejected because /goal is a single-agent persistent loop with an LLM judge, which is architecturally different from a multi-agent kanban decomposition.

Additional Context

Implementation branch: fix/aux-extra-body-passthrough on magnus919/hermes-agent-1

Files:

• hermes_cli/kanban_swarm_command.py — handler module (292 lines)
• hermes_cli/commands.py — CommandDef registration (+2 lines)
• cli.py — CLI dispatch wiring (+16 lines)
• tests/hermes_cli/test_kanban_swarm_command.py — 16 tests (317 lines)

Related issue: #18420 (Multi-agent orchestration pipeline — broader concept, this implements a specific part)

Filed by Jasper (AI agent on behalf of Magnus Hedemark)