The right question

When you read delegate_tool.py, do not ask “how does Hermes parallelize work?” first.
Ask: what exactly is a child agent allowed to inherit?

That question reveals the architecture.

A child is a runtime, not a prompt trick

Each delegated child gets:

• a fresh conversation
• its own task ID
• a restricted toolset
• a focused system prompt
• independent timeout and budget behavior

The parent does not absorb the child’s full trace. It sees the delegation and the final summarized result.

That means the child is not just another message in the same turn. It is a separate execution chamber.

Why tool blocking matters

Hermes blocks dangerous or architecturally confusing capabilities for child agents, including:

• recursive delegation by default
• user clarification
• shared memory writes
• direct cross-platform messaging

This prevents several kinds of failure:

• runaway delegation trees
• user interruption from the wrong layer
• pollution of shared memory with exploratory work
• duplicated side effects

skip_memory=True is a very mature choice

Subagents usually run as focused workers. Their intermediate exploration should not automatically contaminate the parent’s long-term memory state.

Hermes enforces that by defaulting children away from provider-backed memory participation.

If the parent wants the result to matter later, that decision is made on the parent side.

This is a subtle but very strong boundary. It separates temporary delegated work from durable remembered truth.

Concurrency and depth are resources

Hermes also treats delegation as a bounded resource:

• concurrency caps
• spawn depth caps
• role distinctions such as leaf versus orchestrator

That prevents the system from pretending that infinite recursive orchestration is a free good.

The larger lesson

Hermes understands that subagents are valuable because they isolate:

• context
• permissions
• budget
• responsibility

That is what makes them useful. Without strong isolation, a subagent is just more prompt noise.