Parallel Delegation: Running Subagent Fleets

From One Subagent to a Fleet

Hermes Agent Advanced introduced delegate_task: the ability to spawn a child agent with an isolated context, give it a specific goal, and wait for its result. In v0.17 and earlier, you could run one background subagent at a time. If you had three independent research tasks to execute in parallel, you ran them sequentially �� each one waiting for the previous to finish.

v0.18 lifts that constraint. The delegate_task tool can now fan out multiple subagents that all run concurrently. Your chat is never blocked. When every subagent finishes, their results come back as a single consolidated turn. The tasks ran in parallel; the results are delivered as a coherent package.

This is a qualitative change in what autonomous delegation can accomplish. Work that previously took N * (time per task) now takes max(time per task) — the wall clock time of the slowest task in the fleet.

How Parallel Fan-Out Works

When you ask Hermes to delegate multiple tasks, it spawns up to max_concurrent_children (default: 3, configurable in config.yaml) child agent instances in parallel. Each child:

• Has a completely fresh conversation — zero knowledge of the parent's history or the other children's work
• Has its own terminal session — file operations do not step on each other
• Has a restricted toolset — by default, children cannot call delegate_task (no recursion), clarify, memory, or execute_code
• Has an iteration limit (default: 50 turns) and an optional wall-clock timeout

Results are sorted by task index when they are returned, regardless of the order in which children actually completed. If you delegate tasks A, B, and C and C finishes first, you still receive results in A, B, C order. This makes it safe to write code that depends on positional output even when execution order is non-deterministic.

Context Isolation: Writing the Goal and Context Fields

The most common mistake with parallel delegation is writing a goal that assumes the child knows things the parent knows. It doesn't. Every child starts with a blank context. Everything the child needs to complete its task must be embedded in the goal and context fields when you call delegate_task.

Concretely: if the child needs to work with a specific file, include the file path (or content) in the context. If the child needs to understand the project structure, summarize it. If the child's output needs to match a specific format, define the format explicitly. A child that receives an ambiguous goal and no context has no way to resolve the ambiguity — it will make its best guess, which may not be what you wanted.

The documentation states this explicitly: "Subagents start with a completely fresh conversation." Treat writing a delegate_task call like writing a cold-start prompt for a colleague who just joined the project and knows nothing about what you have been doing.

The /agents Overlay

When multiple subagents are running, you need visibility into what they are doing and what they are costing. The /agents overlay (alias: /tasks) provides a live tree view of all running agents in the current session hierarchy.

For each running child, the overlay shows:

• The task goal (truncated for readability)
• The current turn count and iteration limit
• Token usage to date: input tokens, output tokens, cache hits
• Cost to date in USD, rolling total
• A kill control to cancel the child if it is going in the wrong direction

The /agents overlay is the difference between delegating work into a black box and having operational visibility into a running fleet. For expensive multi-agent tasks, checking the overlay periodically prevents surprise costs from runaway children.

Model Override for Cheaper Subagents

Not every subtask requires the same model as the parent. If a parent session is running Claude Opus 4.8 for complex reasoning, it does not need to spawn Opus 4.8 children for simple data gathering tasks. The model for child agents can be overridden in config.yaml:

delegation:
  child_model: openrouter:deepseek/deepseek-v4-flash

With this configured, all children use the specified cheaper model regardless of what the parent is using. For a fleet of research subagents gathering information that the parent will synthesize, a fast and cheap child model is usually the right choice. The synthesis happens at the parent level, with the more capable model.

Orchestrator Mode for Nested Delegation

By default, children cannot themselves call delegate_task — they are leaf agents. This prevents uncontrolled recursive delegation. If you have a legitimate use case for nested delegation (a parent that spawns children that themselves spawn workers), you can raise the max_spawn_depth above its default value of 1 in config.yaml, and mark specific children with role: orchestrator to give them delegation capability.

Orchestrator mode is an advanced pattern. Use it only when the task genuinely requires it — when a child needs to further decompose its assignment into parallel sub-tasks and cannot do so sequentially within its iteration limit. The added complexity of nested delegation (and the added cost of the extra levels of agent calls) is only justified when the problem structure demands it.