Hermes Agent Subagents: What They Are, How delegate_task Works, And The Models Behind Them

Hermes Agent subagents are child agents that the main Hermes agent spawns with the delegate_task tool, each with a fresh conversation, its own terminal session and the parent's tools.

Hermes Agent is the free, open-source agent from Nous Research, and subagents let one agent split a job into parts that run in parallel in the background.

The official delegation docs say only each child's final summary returns to the parent, which keeps the main conversation clean.

I've made two videos on subagents, one on async subagents doing the work for you and one on controlling them live.

I'm Julian Goldie, and in this post I'll explain what subagents are and how delegate_task works, then show how the models your workers run on score on GoldieBench.

The Hermes facts here come from Nous's own documentation and my own videos.

Hermes Agent subagents at a glance

This table sums up how subagents work before we go into detail.

What are Hermes Agent subagents?

A subagent is a full child copy of the Hermes agent, not a one-off model call.

The docs say delegate_task spawns child agent instances with isolated context, inherited tool access and their own terminal sessions.

Each one gets a fresh conversation and works independently.

Top-level delegations run in the background automatically, so Hermes returns a handle and you can keep chatting.

When a child or batch finishes, the result arrives as a new message in the same chat.

The docs also say the agent delegates on its own when a task is complex enough.

The problem subagents solve

A single agent doing a big job one step at a time is slow, and its context fills with tool output.

By the end of a long research task, the useful facts are buried under pages of fetched web content.

Subagents fix both problems at once.

The work runs in parallel, and only the summaries come back, so the main agent stays focused.

My first video covers real examples of parallel content and onboarding builds, which is exactly this kind of job.

How to set up Hermes Agent subagents

Subagents are built into Hermes, so there's nothing extra to install for the basics.

First, run hermes update so you have the latest delegation features, including the live controls.

Second, open ~/.hermes/config.yaml and set the delegation: limits you want, which I cover below.

Third, decide whether workers should inherit your main model or run on a cheaper pinned one.

Fourth, give your agent a job that splits cleanly, such as researching three competitors, and ask it to use subagents.

Fifth, open the live roster and watch the first run, steering early if a worker drifts.

Finally, run /review on the result before you rely on it.

In Hermes Desktop, Settings → Model → Subagents holds the same model, turn limit, concurrency, timeout and reasoning settings for each profile.

Real examples of subagents at work

My first video walks through parallel content and onboarding builds, where each piece of the job is independent.

My second video runs three builds with live steering: a roadmap page, an SEO ROI calculator and an audit landing page.

The docs add three examples of their own.

One is parallel research, where three topics are researched side by side, each with its own focus.

Another is a review-and-fix job on an authentication module, handed to a fresh context with the files and the test command.

The last is a multi-file refactor that would otherwise flood the parent's context.

The common thread is that every one of these jobs splits into parts that don't need to talk to each other mid-task.

How delegate_task works

A single task is one goal and one context, and a batch is a tasks list of them.

By default, a batch returns one consolidated message when every task has finished.

Setting delegation.independent_completions: true makes results land as each task or group finishes instead.

Each task can carry an output_schema, which the parent validates, with one correction turn if the answer doesn't match.

Each task can also carry an images list of up to 8 pictures for jobs that need to see a screenshot or mock-up.

The child returns a structured summary of what it did, what it found, which files it changed and any issues.

Why the brief matters more than anything

The docs put this in a warning box: subagents know nothing about the parent's conversation.

A child's only context is the goal and context the parent writes.

The docs show the difference between a useless brief and a good one.

# BAD - subagent has no idea what "the error" is
delegate_task(goal="Fix the error")

# GOOD - subagent has all context it needs
delegate_task(
    goal="Fix the TypeError in api/handlers.py",
    context="""The file api/handlers.py has a TypeError on line 47:
    'NoneType' object has no attribute 'get'.
    The function process_request() receives a dict from parse_body(),
    but parse_body() returns None when Content-Type is missing.
    The project is at /home/user/myproject and uses Python 3.11."""
)

The exception is project context, because children read .hermes.md, the AGENTS.md chain, CLAUDE.md and .cursorrules from the parent's workspace.

Limits you can set

delegation.max_iterations caps each child's tool-calling turns, and the default is 250. delegation.max_concurrent_children sets how many run at once, and an oversized batch returns an error rather than being cut short. delegation.max_spawn_depth defaults to 1, which keeps delegation flat so children can't delegate further.

Raising it to 2 lets a child spawned with role="orchestrator" run its own workers.

The docs warn that depth 3 with 3 children per level can reach 27 concurrent leaf agents.

One-shot runs such as hermes chat -q are capped separately by delegation.oneshot_max_children, which defaults to 2.

Watching, steering and stopping subagents

My second video shows the live controls with three builds: a roadmap page, an SEO ROI calculator and an audit landing page.

In the classic CLI, Ctrl+T or F6 opens a live roster, and the TUI has an /agents overlay with per-branch cost and token rollups.

Desktop shows a Subagents frame above the composer with Steer and Stop buttons for each worker.

Steering is queued, so a worker reads your guidance at its next checkpoint, and a late steer is reported as missed_steer.

Stopping a worker keeps its partial output, which returns with status="interrupted".

Every task also writes a readable log under ~/.hermes/cache/delegation/live/, and those logs are pruned after 7 days.

Safety, failures and restarts

Leaf subagents can't ask you questions, write to shared memory, message anyone or schedule work in your name.

They inherit the parent's enabled toolsets, and the model can't widen them per call.

delegation.worktree_isolation: true gives each child its own git branch, so parallel code edits don't collide.

There's no wall-clock timeout by default, but a child with no progress for 450 seconds, or 1,200 seconds inside a tool, is interrupted.

Failed children are always reported, with status: "failed" and the error text for the parent.

A Hermes restart doesn't resume a running child, so the docs point to cronjob for durable work.

The /review reviewer

Typing /review sends an independent background subagent to check the work your conversation just produced.

It starts from the last 10 messages, gets the full subagent toolset and opens the actual files or PR.

Its review lands back in the same chat so your main agent can act on it.

It runs on your main model unless you pin auxiliary.review.

Delegation or execute_code?

The docs say to use delegate_task when a subtask needs reasoning, judgment or multi-step problem solving.

They say to use execute_code for mechanical pipelines, because it returns only stdout and uses far fewer tokens.

Hermes Agent subagents: why the worker model matters

Hermes doesn't ship its own model, so every subagent thinks with whatever model you connect.

By default that's the parent's model, and the docs say a parallel batch of subagents typically burns the large majority of a run's tokens.

So the worker model decides both the quality of the parts and most of the bill.

GoldieBench scores models on real one-shot builds, which is close to what a build-heavy subagent does, and these are current averages from the live board.

These scores measure one-shot builds, so a lower-scoring model can still be fine for summaries with a tight brief.

For workers that build pages, tools or code, the gap between the top and the bottom of this table is the gap you'd see in the output.

To pin a worker model, set delegation.model, and I've explained every option in my Hermes subagent model explainer.

To give different tasks different models, see my Hermes advanced delegation explainer.

For private workers, my local models page shows what runs on your own hardware, and the wider shortlist is in my best Hermes Agent model explainer.

Verdict

Hermes Agent subagents are a mature way to run parallel work, with background batches, live steering, structured output and clear failure reporting.

Brief them fully, set the limits, and pick worker models from the live board rather than leaving every child on your most expensive model.

Also On Our Network

• Agent Operatorsthe six-step Hermes Agent subagents operator setup
• AI Income Deskreal ways businesses and creators use Hermes subagents
• AI Tool Verdicttwelve Hermes subagent features, scored with a verdict
• agentos.guidethe Hermes Agent subagents quick start for an Agent OS
• agentos.guidethe Hermes swarm system guide on agentos.guide

If you run an agency and want a clear plan for putting agents to work on client SEO, you can book a free strategy session with my team.

If you'd like help choosing models for your workers, you can also claim a free SEO strategy session and we'll look at it together.

Brief every worker fully, watch the first run live and pick strong worker models, and you'll get real value from Hermes Agent subagents.