It means a subagent cannot answer a question that depends on something the parent read off-screen, because the parent has to put the answer into the context block. It means a subagent cannot pick up the implicit thread of a multi-turn negotiation, because the negotiation happened in the parent's thread. It means that prompts like "fix the error" without context produce a subagent that guesses. The documented counter-example shows what good looks like: an explicit goal, an explicit error, an explicit file path, an explicit runtime, and a brief sentence about the project's location and tooling (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation).
The four execution surfaces and which to pick
Hermes Agent exposes at least four ways to get work done, and the delegation choice is one of them. Tools are the cheap path for single-turn side effects. The execute_code surface collapses multi-step tool loops into one LLM turn. Cron drives time-based autonomous work. Subagent delegation drives parallel research and review on isolated context (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation, https://hermes-agent.nousresearch.com/docs/user-guide/features/code-execution, https://hermes-agent.nousresearch.com/docs/user-guide/features/cron).
| Surface | Use when | Avoid when |
|---|
| Single tool call | One deterministic side effect | You would call three or more tools in sequence with branching |
| execute_code | Three or more tool calls with processing between them | You genuinely need each intermediate result to steer the next user-visible turn |
| Cron | Time-based autonomy, watchdog, daily brief | You need an answer right now or want recursive scheduling |
| Subagent delegation | Parallel workstreams or isolated context the parent should not see in full | The task is so cheap that recreating context costs more than just doing it inline |
The interesting column is the last one. Subagent delegation is most often wrong when the cost of writing the context block exceeds the cost of doing the work inline. It is most often right when the parent agent would otherwise be forced to read or write hundreds of files into its own context window.
Sizing tasks for subagent isolation
Good subagent tasks share three properties. They are sized so that a focused system prompt plus a generous context block can finish them. They are scoped so that the subagent does not need to know about anything outside the goal and context fields. They are reviewable, meaning the parent's downstream behavior should depend on a short, structured summary rather than a sprawling log (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation).
A bad subagent task is "investigate the bug and fix whatever you find." A good subagent task is "investigate the failing test in tests/test_auth.py:42, identify the root cause, propose a fix in src/auth.py, do not change other files, return a structured summary with root cause, fix, files touched, and tests you would add." The structural difference is that the second version lets the parent treat the subagent as a function with a typed return rather than as a colleague to be re-interviewed.
The toolset restriction field is part of sizing. Passing only the toolsets the subagent actually needs (for example, "terminal" and "file" for a code review, or "web" for a research sweep) shrinks the blast radius and reduces the surface for accidental side effects (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). The default is to inherit, but the documented best practice is to be explicit.
Parallel groups and the concurrency ceiling
The documented default for parallel subagents is three concurrent children, with no hard ceiling (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). The default is what makes research-style sweeps feel natural: kick off three threads, collect three summaries, merge them in the parent. The default is also what makes "let me spawn ten at once" feel like a great idea until the parent's context budget is consumed by ten return paths.
The right pattern is to sequence in rounds of three and to treat the round count as a budget knob. If you have nine research targets, run them in three sequential rounds of three, merging between rounds, rather than nine concurrent subagents. The merge step is what gives the parent a chance to re-prioritize based on what the first round returned. That is a property of the design you want, not a property you want to fight.
How to write a context block the subagent can actually use
The single highest-impact habit a builder can build is writing context blocks as if they were the only thing the subagent will ever read. The published examples show concrete patterns: file paths, line numbers, exact error text, the runtime, the framework, and the prompt constraints (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). None of that is hand-wavy.
A useful mental test is to ask: if a new engineer joined the team today, sat down at a clean checkout, and read only the context block, could they do the task? If the answer is no, the subagent cannot either. The block does not need to be polished; it needs to be complete.
The other high-value habit is to specify the shape of the return. The documentation describes a structured summary with what the subagent did, what it found, what files it modified, and what issues it encountered (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). Spelling that out in the goal field turns the delegation into a typed function call. Leaving it implicit turns the delegation into a guessing game whose summary you will have to re-parse anyway.
A delegation pattern that holds up
The pattern that holds up under production load has four steps. First, identify the slice of work that the parent agent should not be forced to think about inline (a long file scan, a multi-page research sweep, a focused refactor across many files). Second, write the goal as a single verb-noun phrase with explicit constraints and a defined return shape. Third, write the context block as a self-contained briefing that names files, errors, runtimes, and boundaries. Fourth, merge the returned summary into the parent's working context and decide what to do next, which is the parent's job, not the subagent's.
This pattern scales because each piece is small enough to reason about and the interface between pieces is short and explicit. It breaks when the parent tries to be clever by skipping the context block, when the subagent tries to be helpful by exceeding its scope, or when the merge step gets skipped and the parent's next turn ignores the summary entirely.
The implementation review checklist
Before a delegation goes to production, an operator or builder should review it against the checklist below. The checklist is short on purpose; the goal is to surface the recurring failure modes before they cost a real incident.
| Review item | What to look for | Failure mode it prevents |
|---|
| Goal field has a single verb-noun shape | Reads as an instruction, not as a description | Vague goal -> vague subagent output |
| Return shape is named in the goal | Lists what the subagent should print | Parent context flood from unconstrained subagent return |
| Context block names files, line numbers, errors, runtime | A new engineer could do the task from the block alone | Subagent context starvation |
| Toolset restriction is explicit, not inherited | Lists exactly which toolsets the subagent should see | Subagent toolset overreach and accidental side effects |
| Concurrency is bounded | Stays within the documented default unless there is a reason | Parent context and budget overrun from unbounded parallelism |
| Merge step is in the parent's prompt | Names how the summary will be used next | Silent ignore of subagent return and wasted compute |
| Rollback path is named | Says how to undo the subagent's changes if needed | Permanent state change from a subagent that should not have written |
FAQ
What is the difference between execute_code and a subagent?
execute_code collapses multiple tool calls into a single LLM turn inside the parent's context (https://hermes-agent.nousresearch.com/docs/user-guide/features/code-execution). A subagent starts a fresh conversation with isolated context and returns a summary (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation).
How many subagents can run at once?
Three concurrent by default, with the limit configurable per the public delegation documentation (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). Going beyond the default is usually better expressed as sequential rounds with merge steps than as a single large parallel group.
No. Subagents begin with a fresh conversation and only receive the goal and context fields the parent passes in (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). Anything the subagent needs has to be in the context block.
The delegation test
A delegation is well-designed when the parent could throw away its own conversation history and the subagent could still finish the task from the context block alone. If that property holds, the implementation scales. If it does not, every delegation is a hand-off that the parent will have to repeat. Each delegation is also a tradeoff between isolation and coordination, and a good delegation names the source of every fact in the context block so the facts are unambiguous on the receiving side. The limitations of the fresh-conversation rule are the right counterweight for the isolation property, and the right delegation surfaces both rather than hiding one.
A delegation review most teams skip is the one where they read the last ten subagent returns and ask whether each one would still work if the parent's conversation were deleted. That audit is the implementation review that catches context starvation before it ships, and the cited reference for every fact in the context block is the only thing the subagent can actually trust. The evidence artifact should also record the permission boundary, rollback path, and threshold for stopping parallel work before the operator delegates again.