Multi-Agent Workflows: Profiles and Delegation

The Tool That Makes This Work

delegate_task spawns a child AI agent with a completely isolated context. The documentation is direct about this: "Subagents start with a completely fresh conversation" -- they have zero knowledge of the parent's conversation history. Whatever the parent agent knows that the child needs to know has to be explicitly passed through the goal and context parameters. Nothing carries over implicitly.

How Execution Actually Works

Subagents are not independent background processes running alongside the parent. They run synchronously, within the parent's current turn, and the parent blocks until they finish. There is no "check back later" -- the parent is waiting the whole time. A consequence worth knowing: subagents cannot keep running after the turn ends, and if you interrupt the parent agent, every active child is cancelled along with it.

Each subagent gets its own terminal session, separate from the parent's, a focused system prompt built specifically from the goal and context it was given, and a genuinely fresh conversation with no prior history at all.

Two Delegation Patterns

• Single task -- one subagent, a specific goal, a specific toolset
• Parallel batch -- multiple subagents running concurrently, up to 3 by default (configurable)

What Children Cannot Do

Subagents have a deliberately restricted toolset compared to their parent. They cannot access: delegation (no spawning their own children, by default), clarify, memory, code_execution, or send_message. What they typically get instead is a focused subset matched to the actual task -- ["terminal", "file"] for code work, ["web"] for research, ["file"] alone for read-only analysis.

The restriction on memory access in particular is worth sitting with: a subagent cannot read or write your persistent memory from Hermes Agent Fundamentals. Anything it learns during its task dies with that task unless the parent explicitly carries the result forward in its own response.

There is one exception to the no-delegation rule: orchestrator-role children retain delegation capability themselves when max_spawn_depth is configured greater than 1 -- enabling genuinely multi-level workflows where a child can itself spawn grandchildren, rather than every delegation chain being exactly two levels deep.

Real Examples From the Documentation

• Parallel research across several topics simultaneously, each subagent investigating one topic with web access while the parent waits for all of them to report back
• Code review and security fixes, delegated with full project context so the child can actually act on what it finds, not just describe it
• Multi-file refactoring -- for example, replacing every print() call in a codebase with proper logging module calls, where the parent can fan the work out across files

When to Reach for This vs. Doing It Yourself in One Conversation

Delegation makes the most sense when a task genuinely decomposes into independent pieces -- parallel research across unrelated topics is the clearest case, since nothing one subagent finds depends on what another is doing. It makes less sense for work that is inherently sequential or where each step needs full context from every prior step; a fresh-context subagent without that history will not do that kind of work well, by design.

The next lesson moves to a different kind of interaction entirely: giving your agent voice, so a conversation can happen out loud instead of through text.