Delegation: Spawn Isolated Subagents for Parallel Work

Hermes can delegate work to child agents that run in parallel, each with its own isolated context and terminal session. The delegate_task tool spawns a subagent, hands it a goal and supporting context, and receives back only its final summary — keeping your main conversation's context clean and your pipelines moving. When you have several independent tasks, you can launch them as a batch and collect the results once they all finish.

How Subagent Context Works

The most important thing to understand is that subagents know nothing about your conversation. Each starts with a completely fresh context: no awareness of prior tool calls, files discussed, or history before delegation. The only context a child receives is what you pass in the goal and context fields when you call delegate_task.

There is one exception: when the parent has a resolved workspace directory, each subagent's system prompt embeds that workspace's project context files (.hermes.md, the AGENTS.md chain, CLAUDE.md, and .cursorrules). This means subagents working in a repository operate under its conventions automatically. But for everything else, the parent must be explicit — the source documentation shows a bad example, delegate_task(goal="Fix the error") (the child has no idea what "the error" is), versus a good one that spells out the file, the line, and the project setup.

Single Task or Parallel Batch

A single task is straightforward — pass a goal and context. For parallel work, pass a tasks array:

delegate_task(tasks=[
    {"goal": "Research topic A", "context": "Focus on recent primary sources"},
    {"goal": "Research topic B", "context": "Compare the leading explanations"},
    {"goal": "Fix the build", "context": "Project root: /home/user/project"},
])

Hermes runs them concurrently, up to 10 by default (configurable via delegation.max_concurrent_children, with no hard ceiling). Each task can also carry an output_schema — a JSON Schema the child's final answer must satisfy. If validation fails, the parent sends the child one bounded correction turn carrying the errors verbatim. The subagent receives a focused system prompt instructing it to complete the task and report what it did, what it found, files modified, and any issues.

Built for Real Workflows

Delegation shines for workloads that would otherwise flood the parent's context:

• Parallel research — fan out multiple topics at once and collect summaries.
• Code review + fix — hand a fresh context a security review with explicit focus areas, then have it run the test suite.
• Multi-file refactoring — one subagent can rewrite files across src/ and verify with pytest without the parent wading through every diff.

Top-level model calls run in the background automatically. Hermes returns a handle immediately so the conversation continues, then posts the result back as a new message when done. An orchestrator subagent waits for its own workers so it can synthesize their results before returning. By default, batch results arrive as one consolidated message once every task finishes; you can opt into per-task delivery with delegation.independent_completions: true, and group tasks that should be reviewed together.

Tool Access and Safety

delegate_task deliberately does not accept a toolsets parameter — each subagent inherits the parent's enabled toolsets, so a model can never grant a child capabilities the parent lacks. Certain tools are blocked for subagents even when the parent has them:

• delegate_task — blocked for leaf subagents (retained for orchestrators, bounded by a spawn depth)
• clarify — subagents cannot interact with the user
• memory — no writes to shared persistent memory
• send_message — no cross-platform side effects
• cronjob — no scheduling more work in the parent's name

Each subagent has an iteration limit (default 250, set via delegation.max_iterations); a child that exhausts it returns exit_reason: max_iterations and truncated: true, so the parent can tell a budget stop from a completed task. There's no wall-clock timeout by default — children fail only from their own errors — though you can opt into a hard cap with delegation.child_timeout_seconds.

Controlling Cost

Because parallel batches typically consume the majority of a run's tokens, you can pin inexpensive worker models while keeping your main session on a frontier model:

model:
  default: "your-frontier-model"   # parent (planner)
delegation:
  model: "your-inexpensive-model"  # all delegate_task children
  provider: "openrouter"

The resolution order is delegation.base_url, then delegation.provider, and when neither is set, children inherit the parent's credentials. The pin is global — every child in a batch runs on the configured model. When the result comes back, a failed subagent is never silent: the parent's tool result carries a failed status plus the full error, and the CLI prints a concise one-line reason.

Key Takeaways

• delegate_task spawns isolated subagents with fresh contexts that know nothing unless you tell them.
• Run up to 10 tasks in parallel by default and collect one consolidated result per batch.
• Each subagent inherits the parent's toolsets, with high-risk tools like clarify and memory blocked.
• Structured output_schema gives children a verifiable output contract with one bounded correction pass.
• Pin inexpensive worker models to cut spend where the volume is, while keeping the planner on a frontier model.