One agent doing everything eventually hits a wall. Your context window fills up with intermediate junk, and independent tasks that could run side by side end up crawling one after another. Delegation is the fix: your agent spins up a team of subagents that work in isolation, in parallel, and report back with just the result. This is the jump from a solo assistant to a team you orchestrate.
It assumes you are comfortable with tools and ideally skills — subagents inherit both.
What delegate_task does
The core of delegation is one tool: delegate_task. When the agent calls it, Hermes spawns a child agent — a subagent — with its own conversation, its own terminal session, and its own toolset. The child does the work, and only its final summary comes back into your conversation. All the messy intermediate tool calls never touch your context window. That last part is the quiet superpower: delegation keeps your main thread clean.
A single delegated task looks like this:
delegate_task(goal="Debug why the tests fail",
context="Error: assertion in test_foo.py line 42")
The headline feature: parallel work
Hand delegate_task a list and the children run concurrently:
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"},
])
By default Hermes runs up to 10 subagents per batch. You can raise or lower that, and there is no hard ceiling; ask for more than your limit and you get an error instead of a silently shortened list. The batch returns one handle immediately, runs everything in parallel, and posts a single consolidated result once every child has finished. Three jobs done at once instead of one after another.
The golden rule: a subagent knows nothing
This trips everyone up once. A subagent starts with a completely fresh conversation. It has zero knowledge of your history, your earlier tool calls, or anything you discussed. Its only context is the goal and context you pass in the call.
So you must pass everything the child needs: absolute file paths, the exact error, the project layout, the output format you want. And there are things a subagent deliberately cannot do:
- It cannot
clarify— it can never stop to ask you a question. - It cannot use
memory,send_messageorcronjob. - A leaf subagent cannot delegate further.
The upside of this constraint: delegation forces you to articulate the problem completely, which is often when you realise you did not fully understand it yourself.
Leaf vs orchestrator
By default children are leaf agents — they do the work and cannot spawn their own workers, so delegation stays flat. If you set role="orchestrator", a child keeps the delegation toolset and can spawn its own team. That is gated by delegation.max_spawn_depth (default 1, meaning flat), so an orchestrator does nothing until you deliberately raise the depth. Keep it flat until you have a real reason not to.
It runs in the background — but it is not durable
Top-level delegation runs in the background automatically: Hermes hands you a handle and posts the result as a new message when it is done, so you keep working. But backgrounded children are process-local. Running work is cancelled when you:
- type
/stop; - type
/newin the terminal; - close or reset the session itself;
- restart Hermes (a running child is not resumed).
Just closing the Desktop window does not cancel it. For anything that must survive those boundaries, use a cronjob or a backgrounded terminal task with completion notification instead.
Steering a running subagent
You are not locked out while children run. In Desktop:
- Expand Subagents above the composer.
- Pick a worker.
- Click Steer to send a course correction, or Stop to end it early.
In the terminal, Ctrl+T opens the same live monitor. A stopped child’s partial result still comes back into the conversation.
Each task also writes a live, human-readable transcript to disk under the delegation cache, so you can tail -f a child and watch it think in real time.
delegate_task vs execute_code
Delegation is not always the right hammer. If the job is mechanical — ten cheap, sequential steps with a bit of logic — execute_code runs a Python script and returns only the output, far cheaper than a full agent loop. Use delegate_task when the subtask needs genuine reasoning and judgement; use execute_code for mechanical pipelines. A common pattern combines them: gather with execute_code, then delegate the single expensive reasoning step onto clean context.
The cost angle: frontier planner, cheap workers
Decomposing a problem needs strong-model judgement; executing a well-specified subtask usually does not. Hermes lets you pin a cheaper model for all subagents while your main agent stays on a frontier model. In Desktop:
- Open Settings → Model → Subagents.
- Under Routing, leave Default selected. Every subagent then runs on one model.
- Under Subagent defaults, pick a Subagent Provider and a Subagent Model.
- Click Apply.
- Optional: set Parallel Subagents to how many may run at once.
The other two routing options, Model routes and Profile routes, need the Advanced Delegation plugin.
In config.yaml, the Default route is these keys:
# ~/.hermes/config.yaml delegation: max_concurrent_children: 10 # parallel children per batch (default 10) max_spawn_depth: 1 # keep delegation flat model: "your-inexpensive-model" # every subagent runs on this
This one setting is where delegation quietly saves money, not just time. It is a big enough topic that it has its own article on model routing and cost.
Three kinds of “team” — do not confuse them
Hermes has three different mechanisms that can all feel like “a team.” They are not the same, and picking the right one matters:
- delegate_task subagents — child agents in the same process, isolated context. For parallel subtasks inside the session you are in.
- Bots (profiles) — named, persistent specialists, each with its own personality, model, memory, and skills. For standing roles and routines. A bot is just a profile:
hermes -p <bot> chat. - Scheduled tasks (cron) — work that has to survive a closed session or a restart, on a schedule or as a one-off. See scheduling tasks in Hermes.
For a while I ran four specialist bots this way: research, writing, infrastructure and code. For one person it cost more tokens and time, and the output got worse. I went back to one frontier model with scheduled tasks and a folder of written steps it follows.
Always verify the self-report
One habit that saves you: a subagent reporting “fixed it, tests pass” is a self-report, not proof. Read the diff, run the tests, check the source. Isolation makes subagents powerful, but it also means they can be confidently wrong in their own little bubble. Trust, then verify.
Delegation is where “an assistant” becomes “a team.” Before you hand work to a team, make sure your agent itself runs safely: secure Hermes Agent local mode in 10 minutes.
This article is part of the Agentic AI series.
Discover more from Factnetize
Subscribe to get the latest posts sent to your email.
Liked this? There's more where it came from.
Get our digest — articles worth your time, no spam, unsubscribe in one click.
Subscribe to Factnetize →