Feature: Dynamic agent spawning — agents that can create sub-agents at runtime

[aviraldua93]

Feature Request: Dynamic sub-agent spawning

Problem

Conductor workflows define their full topology at design time in YAML. This means:

• The number of agents is fixed before execution
• A VP agent can't decide "I need 3 ICs, not 2" based on the work
• A researcher can't spawn a follow-up deep-dive agent
• The workflow author must predict every possible execution path upfront

This works for predictable workflows but breaks for complex, adaptive ones — which is exactly where multi-agent systems shine.

What other frameworks do

Framework	Dynamic spawning?	How?
CrewAI	Yes	Supervisor agents can delegate to new worker agents at runtime
AutoGen	Yes	Conversational protocol allows agents to invoke new agents
LangGraph	Partially	Fixed graph, but dynamic routing + tool calls can fork work
Copilot CLI	Yes	Main session spawns sub-agents via task tool
Conductor	No	Topology is 100% defined in YAML at design time

Use cases

1. VP scopes, then deploys ICs: VP agent analyzes the work, decides it needs 3 ICs (backend, frontend, infra). Currently you must pre-define all 3 in YAML even if the VP might decide differently.

2. Researcher spawns deep-dives: Research agent finds an interesting lead, wants to spawn a focused sub-agent to explore it. Currently impossible.

3. Adaptive team sizing: For a for-each over dynamic items, the agent count isn't known until runtime. (for-each partially solves this, but only for data-parallel work, not decision-parallel.)

Proposed design

Option A — Tool-based spawning: Give agents a spawn tool that creates a sub-agent:

agents:
  - name: vp_engineering
    tools: [spawn]  # special built-in tool
    prompt: |
      Analyze the work and spawn IC agents as needed.
      Use the spawn tool: spawn(name, prompt, output_schema)

The spawned agents appear on the DAG dynamically and their outputs feed back to the parent.

Option B — Template expansion: Agent output includes a structured "team request" that Conductor expands:

agents:
  - name: vp_engineering
    output:
      team_request:
        type: array
        description: ICs to spawn
        items:
          properties:
            name: { type: string }
            assignment: { type: string }
    routes:
      - to:   # special directive: spawn agents from team_request

Trade-offs

	Fixed DAG (today)	Dynamic spawning
Predictability	Full — you know exactly what runs	Partial — agents decide
Debuggability	Easy — DAG is static	Harder — DAG changes at runtime
Cost control	Full — token budget is known	Needs limits (max spawns per agent)
Power	Limited to predicted paths	Adapts to actual work

Safety

• Max spawns per agent (default: 5)
• Max total agents per workflow (default: 50)
• Spawned agents inherit parent's timeout and token limits
• All spawned agents visible on dashboard (no hidden sub-agents)

Relationship to existing issues

• Feature: Should there be an optional parameter to pass to conductor to load in a workspace's default instructions? (i.e. AGENTS.md, etc...) #34 (load workspace instruction files) — spawned agents could auto-load .agent.md personas
• Support staged re-invocation of agents (bidirectional workflows) #65 (staged re-invocation) — dynamic spawning is a superset: if agents can spawn, they can spawn "themselves" at a later stage

Environment

Conductor v0.1.2