Contained Sub-Agents: Delegating Work to Isolated Workers

9 min read Module 4 of 9 Topic 12 of 25

What you'll learn

  • Explain what problem contained sub-agents solve that inline tool calls don't
  • Recognize the kinds of tasks worth delegating to a sub-agent
  • Trigger sub-agent delegation deliberately with delegate_task
  • Understand how sub-agents interact with the terminal backend and memory system
Building this at your company? For enterprise and company teams taking this to production: book a 30-minute session with our AI engineers for architecture guidance, code review, and a rollout plan for your use case.
Book a Team Session

The Problem Inline Tool Calls Don’t Solve

You’ve now seen two ways Hermes handles work: direct tool calls (Module 3) for a discrete action, and skills (Lesson 11) for a repeatable procedure. Neither is ideal for a task that is large, exploratory, and disposable in its details, “research these five competitors,” “read this 40-file codebase and report what the authentication flow looks like,” “try three different approaches to this bug and tell me which works.”

Handling tasks like that entirely inline means every intermediate search result, every file you skimmed and discarded, every failed approach, becomes part of the main conversation’s permanent history. That’s expensive, and it crowds out the context budget (Lesson 6) that should be reserved for things that actually matter to the ongoing conversation.

What a Contained Sub-Agent Is

A contained sub-agent is a short-lived, isolated worker, spun up by the main agent, dedicated to one sub-task, with its own focused context. It does its work, reports back a distilled result, and is torn down. Its exploratory mess never pollutes the main conversation.

flowchart TB
    MAIN["Main conversation\n(your session)"] -->|delegate_task| SUB1["Sub-agent A:\nresearch competitor 1"]
    MAIN -->|delegate_task| SUB2["Sub-agent B:\nresearch competitor 2"]
    MAIN -->|delegate_task| SUB3["Sub-agent C:\nresearch competitor 3"]

    SUB1 -->|distilled summary only| MAIN
    SUB2 -->|distilled summary only| MAIN
    SUB3 -->|distilled summary only| MAIN

    style MAIN fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style SUB1 fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style SUB2 fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style SUB3 fill:#f0fdf9,stroke:#0D9488,color:#0F172A

Note that sub-agents can run independently of each other, which is part of what makes this pattern efficient for fan-out work like the competitor-research example: three isolated workers researching in parallel, each reporting back only its conclusion.

When to Delegate

Not every multi-step task needs this. A rough guide:

Delegate to a sub-agentHandle inline
Exploratory research with many discardable intermediate stepsA single well-defined tool call
Independent, parallelizable sub-tasks (research N things)A short, linear sequence of dependent steps
Work whose detailed process doesn’t matter, only the conclusion doesWork where the user needs to see and steer each step
Large codebase exploration before a focused changeA change to a file you’ve already identified

Common pitfall: delegating a task the user actually wants to watch unfold step by step. Sub-agents report back a distilled result, not a live narration, which is exactly wrong for a task where visibility into the process matters as much as the outcome. Use direct tool calls or a skill for those instead.

Triggering Delegation

In most cases, the orchestration layer decides on its own whether a request warrants delegation, the same routing decision from Lesson 3’s request-flow diagram. You can also request it explicitly:

Delegate this to a sub-agent: read through the src/auth/ directory
and report back how token refresh currently works, in three sentences.

Internally, this corresponds to a delegate_task invocation, conceptually similar to a tool call, except what it returns is a full sub-agent’s distilled output rather than a single function’s return value.

Sub-Agents and the Terminal Backend

Context isolation and execution environment are two different things, and it’s worth not conflating them. A sub-agent’s conversational context is fresh and scoped to its sub-task. But depending on your terminal backend (Module 5 covers this in depth), the underlying execution environment can persist across delegation: the Docker backend, for example, runs a single long-lived container for the whole Hermes process, so a package a sub-agent installs, or a working-directory change it makes, carries over to the next sub-agent or back to the main agent, even though each one’s conversational memory of how it got there does not.

This matters in practice: if a sub-agent needs a specific tool or package installed to complete its work, that installation is not wasted effort local to the sub-agent, it persists for whatever runs next in the same Hermes process.

Exercise: give Hermes a task with three independent, parallelizable parts (for example: “look up the current stable release version of Python, Node, and Rust, and give me a one-line summary of each”). Watch whether it delegates to sub-agents or handles it inline, and ask it afterward which approach it took and why. Compare that reasoning against the guide table above.

Knowledge Check

3 questions to test your understanding

1 You ask Hermes to research five competitors and summarize each. Why might the orchestration layer delegate this to sub-agents rather than doing all five lookups inline in the main conversation?

2 What does 'contained' specifically refer to in 'contained sub-agent'?

3 The Docker terminal backend documentation notes that working-directory changes and installed packages carry over across delegate_task sub-agents within the same Hermes process. What does this tell you about how sub-agents relate to the terminal backend?

Go further with expert guidance

Ready to build production AI?
Talk to our R&D team.

These courses give you the foundation. Our embedded AI teams take you from prototype to production in 30–90 days, with your team, your codebase, your goals. Book a free strategy call to see how we can accelerate your AI initiative.

30 minutes · No obligation · Expert AI engineers, not sales reps

AI Architecture Review

Audit your current stack and identify high-impact improvements

Project Review

Get expert feedback on your AI implementation and codebase

Team Mentoring

Upskill your engineers with hands-on AI coaching sessions

AI Strategy

Define your AI roadmap, prioritization, and implementation plan