Subagent Delegation

A single agent working through a long task runs into a wall: context. Every tool call, every result, every reasoning step piles into the context window, and by task 4 of 10 the agent starts to lose track. Or worse, the tasks are independent but the agent insists on running them sequentially because that is the only mode it knows. Delegation is the escape hatch. Instead of one agent doing everything, you split the work across child agents that run in parallel and report back.

What you'll learn

• delegate_task is a built-in tool that spawns child agents with their own isolated context, running independently of the parent
• Delegation supports three modes: single (one child), batch (multiple children, collected when all finish), and background (fire-and-forget)
• Every subagent can be a leaf (does work, returns result) or an orchestrator (delegates further), with configurable depth and concurrency limits
• Delegation is process-local, child agents live inside the parent process and die when it dies. For persistent parallel workers, use multi-agent tmux spawning instead

The problem

You give Hermes a job like "audit every service in this monorepo for outdated dependencies." There are 12 services. A single agent will check service 1, then service 2, then service 3 , sequentially, each one adding its output to the context window. By service 7 the context is 80% audit results from earlier services and the agent starts hallucinating package names it saw three services ago. By service 10 it might skip a check entirely because the model is overwhelmed.

The fix is to treat each service audit as an independent sub-task. Spin up a child agent for each one, let them run in parallel, and collect the results. The parent never sees the internal tool calls of each child, only the final summary. Context stays clean, and 12 audits that took 20 minutes sequentially take 4 minutes when 3 run at once.

Options & when to use each

Approach	Good for	Costs you	When to pick it
Single delegate	One cleanly separable sub-task	A child agent spawn and a context round-trip, negligible for most tasks	"Check this one thing and come back" , sub-tasks that are independent but not numerous enough to batch
Batch delegate	Multiple independent tasks of similar shape	Concurrency limited by max_concurrent_children (default 3); total children capped by context budget of the parent's collect step	Parallel audits, multi-file refactors, any "do this N times across different inputs" pattern
Background delegate	Tasks where the parent does not need the result	No result collection, the child runs and the parent moves on immediately	Notifications, log writes, side-effect work like "post this summary to Slack while I keep working"
No delegation (sequential in the parent)	Tasks that genuinely depend on each other's output	Context bloat, wall-clock time	When task B needs the exact output of task A to even know what to do

Build it

Step 1: Single delegation, the basic pattern

Start an interactive session and give the parent agent a task with a separable sub-task:

hermes

Then at the prompt:

Audit the three largest Python files in the current project for type annotation coverage.
For each file, delegate the actual annotation check to a subagent.
Each subagent should return: file name, total functions, functions with annotations, coverage percentage.
Collect all results and present a summary table.

Hermes will use delegate_task to spawn one child per file. You will see the tool calls appear in sequence or in parallel depending on the model's decisions.

Step 2: Understanding delegate_task parameters

The tool signature the agent sees looks like this:

delegate_task(
  task: str,              # The prompt for the child agent
  role: "leaf" | "orchestrator",  # leaf = do the work; orchestrator = can delegate further
  mode: "single" | "batch" | "background",  # execution mode
  max_concurrent_children: int = 3,  # How many children can run at once (batch mode)
  max_spawn_depth: int = 2,          # How deep the delegation tree can go
)

• role: leaf agents do the work and return. orchestrator agents can call delegate_task themselves, creating a tree. Set role="leaf" for most sub-tasks, orchestrators are for when the sub-task itself benefits from further parallelism.
• mode: single spawns one child. batch spawns multiple children from a list of tasks and collects results when all finish. background spawns and immediately returns, the parent does not wait.
• max_concurrent_children: The parallelism cap. Default is 3. If you batch-delegate 12 tasks, 3 run at a time and the rest queue up.
• max_spawn_depth: Prevents runaway delegation trees. If an orchestrator spawns a child that spawns a child that spawns a child, the depth counter stops it.

Step 3: Batch delegation with explicit tasks

For more control, structure the batch delegation explicitly:

Here is a list of directories that need linting:
- /home/molsen/projects/api-gateway
- /home/molsen/projects/auth-service
- /home/molsen/projects/billing-worker
- /home/molsen/projects/notification-service
- /home/molsen/projects/user-dashboard

For each directory, delegate a lint audit to a leaf subagent.
Each subagent should:
1. Run the project's linter (check for a Makefile target, package.json script, or pyproject.toml config)
2. Count total warnings and errors
3. Return: directory name, tool used, warning count, error count

Use batch mode with max_concurrent_children=3.
Collect all results into a markdown table sorted by error count descending.

The parent agent will call delegate_task once in batch mode with all five tasks, and Hermes will run them 3 at a time.

Step 4: Background delegation for fire-and-forget

Background mode is for side effects, the parent needs the thing to happen but does not need the result inline:

Refactor the database connection pool module.
As you work, every time you make a change, delegate a background task that writes a summary of the change to ~/refactor-log.md.
Do not wait for the log write before continuing, use background delegation.

The parent keeps working while the log writes happen independently.

Step 5: The orchestrator pattern

When a sub-task is itself parallelizable, use the orchestrator role:

We need to migrate 3 microservices from Flask to FastAPI.
Delegate the overall coordination to an orchestrator subagent.
The orchestrator should spawn one leaf subagent per microservice.
Each leaf subagent analyzes its service and returns a migration plan.
The orchestrator collects the plans and returns a unified migration schedule.

The tree looks like: parent → orchestrator (1 child) → leaf agents (3 children). The parent only sees the orchestrator's final output, not the individual leaf plans unless the orchestrator includes them.

What goes wrong

Mistake	How you notice it	The fix
A child agent runs forever	The parent hangs waiting for batch collection, and the spinner never stops	Check the child's output with process(action='list') if running in the terminal. In a cron job, the 3-minute hard interrupt catches it. Set a timeout in your prompt: "If any sub-task takes more than 60 seconds, return a timeout error"
Batch delegation with too many children	The parent's context fills with 20 child results and the summary step hallucinates data from early children	Cap batch size at 5–8 children. If you genuinely need more, split into two batches or use multi-agent tmux spawning instead
Children inherit a skill the parent loaded, but the skill is wrong for the child's task	A child agent blindly follows skill instructions meant for a different domain, producing nonsense results	Skills attach to the parent session. If children need different skills, the parent should specify those in the delegation prompt. Alternatively, use profiles with different skill sets
An orchestrator spawns deeper than max_spawn_depth allows	The deepest child fails with a depth-limit error, and the orchestrator swallows the error in its summary	Check max_spawn_depth before designing an orchestrator tree. Default is 2 , parent → orchestrator → leaf is the deepest supported out of the box. Raise it with max_spawn_depth=3 if you need another level
Background delegation that should have been synchronous	The parent finishes and exits, and the background child is still running, its result is lost when the process ends	Delegation is process-local. Background children die when the parent process exits. If you need the result later, use synchronous delegation or spawn a separate Hermes process through tmux

Confirm it worked

# Start an interactive session
hermes

# Give it a batch delegation task:
# "For each of these 3 directories ,  /tmp, /var/log, ~/.cache , 
#  delegate a leaf subagent that reports the total size and file count.
#  Use batch mode. Collect and present a summary table."

# Verify:
# 1. You see delegate_task calls in the tool output
# 2. The final summary includes data from all three directories
# 3. The summary is in the format you requested (a table)

# If all three checks pass, delegation is working.

Next: Multi-Agent Workflows , spawning persistent parallel workers in tmux sessions that survive the parent process.