Sub-Agent Task Tool Not Exposed When Launching Nested Agents

Feature Request: Enable Nested Task Spawning in Claude Code

Summary

Currently, sub-agents spawned via the Task tool in Claude Code cannot themselves spawn additional sub-agents. This limitation prevents the creation of hierarchical agent workflows that would significantly improve complex task management and help maintain focus for the Sonnet model through proper task decomposition.

Current Behavior

When a sub-agent attempts to use the Task tool, it reports that the tool is not available. As demonstrated in the following logs:

> spawn a sub agent / task, have it write to a file "test_1.txt". Then **that** sub-agent, should spawn 2 more sub agents. Each sub-sub agent should write to respectively test_2.txt and test_3.txt.

⏺ Task(Task: Spawn sub-agents for file creation
      Prompt: You are a sub-agent that needs to:
      1. Write "Hello from sub-agent 1" to a file called "test_1.txt"
      2. After writing that file, spawn 2 more sub-agents using the Task tool
      3. The first sub-agent should write "Hello from sub-agent 2" to "test_2.txt"
      4. The second sub-agent should write "Hello from sub-agent 3" to "test_3.txt"
      
      Important: You must complete step 1 first, then spawn the two additional sub-agents for steps 3 and 4.)
  ⎿  Write(/Users/pasta/workspace/dash/test_1.txt)
  ⎿  Wrote 1 lines to /Users/pasta/workspace/dash/test_1.txt
  ⎿  Done (1 tool use · 14.8k tokens · 21.1s)

When queried about the error, the system revealed:

The first sub-agent reported that it successfully created test_1.txt, but then said: "However, I notice that I don't have access to a 'Task' tool that would allow me to spawn sub-agents. Looking at the available tools, I don't see any tool that would enable me to create or spawn additional agents."

Further investigation confirmed that sub-agents have access to these tools:

• Bash, Glob, Grep, LS, ExitPlanMode, Read, Edit, MultiEdit, Write, NotebookRead, NotebookEdit, WebFetch, TodoWrite, WebSearch

Notably missing: The Task tool itself

Current Workaround: The claude -p Hack

Some users have discovered they can work around this limitation by having sub-agents call claude -p through the Bash tool to spawn non-interactive Claude instances. This creates several problems:

The Hack in Practice:

# Inside a sub-agent, instead of using Task tool:
claude -p "Review the CI logs in /tmp/ci_output.log and summarize failures" < /tmp/ci_output.log > /tmp/ci_summary.txt

Why This Workaround is Problematic:

1. Loss of Visibility: The main Claude instance has no insight into what the nested claude -p call is doing. There's no progress tracking, no ability to interrupt, and no structured output handling.

1. Complex Error Handling: If the nested Claude call fails, debugging becomes a nightmare. Error messages are buried in bash output rather than being properly propagated through the task hierarchy.

1. Resource Management Chaos: Each claude -p call is a completely separate process with its own token usage, rate limits, and resource consumption. There's no coordinated management of these resources.

1. Data Flow Complexity: Information must be passed through files or stdout/stdin pipes rather than structured task results. This leads to brittle parsing logic and potential data loss.

1. No Context Sharing: The nested Claude instance starts with zero context about the parent task, requiring extensive prompt engineering to pass necessary information.

1. Inconsistent Behavior: The CLI interface may have different capabilities, models, or behaviors compared to the Task-spawned agents, leading to unpredictable results.

Why This Matters

The Task tool is critical for keeping the Sonnet model focused and efficient. Without nested task spawning, we're forced to either:

1. Load excessive context into a single agent (leading to context rot and degraded performance)
2. Manually orchestrate all sub-tasks from the top level (breaking encapsulation and creating management overhead)
3. Resort to hacky workarounds like claude -p that compromise visibility, reliability, and maintainability

Real-World Use Case: PR Review Workflow

Consider a Claude workflow designed to review all open pull requests in a repository:

Ideal Architecture with Nested Tasks:

Main Agent (Manager)
├── Fetches list of open PRs
├── Tracks review status
├── Spawns PR Review Agent for each PR
│
└── PR Review Agent (Implementer)
    ├── Reviews code changes
    ├── Checks PR description
    ├── Spawns CI Analysis Task
    │   └── CI Analysis Sub-Agent
    │       ├── Fetches CI results
    │       ├── Parses error logs (potentially thousands of lines)
    │       └── Returns concise summary of failures
    ├── Spawns Test Coverage Task
    │   └── Coverage Analysis Sub-Agent
    │       ├── Analyzes coverage reports
    │       └── Returns coverage delta summary
    └── Compiles final review with all sub-task results

Current Limitation Impact:

Without nested tasks, the PR Review Agent must either:

• Process entire CI logs in its own context (thousands of lines for failed builds)
• Parse complex coverage reports directly
• Risk context overflow and loss of focus on the actual code review
• Or resort to claude -p calls that make the workflow opaque and difficult to debug

This leads to:

• Context rot: The implementer agent becomes overwhelmed with log data
• Reduced accuracy: Important review details get lost in the noise
• Slower performance: Processing unnecessary data in the main context
• Poor modularity: Cannot encapsulate specialized analysis logic
• Debugging nightmares: When using claude -p workarounds, there's no visibility into what went wrong

Proposed Solution

Enable the Task tool for sub-agents, allowing them to spawn their own sub-tasks. This would:

1. Maintain focus: Each agent handles only the information relevant to its specific task
2. Improve modularity: Specialized sub-agents can be created for specific analysis types
3. Reduce context usage: Long logs and reports are processed in isolated contexts
4. Enable true hierarchical workflows: Natural decomposition of complex tasks
5. Eliminate hacky workarounds: No need for opaque claude -p calls with poor observability

Technical Considerations

• Implement depth limits to prevent infinite recursion
• Add resource controls for total number of concurrent sub-agents
• Provide clear error messages when limits are reached
• Consider a permission model where the initial Task spawn can specify whether sub-tasks are allowed
• Ensure proper token accounting across the entire task hierarchy

Conclusion

The ability to spawn nested tasks is essential for building sophisticated workflows with Claude Code. It allows for proper separation of concerns, efficient context management, and maintains the Sonnet model's effectiveness on complex, multi-step tasks. Without this feature, users are forced into suboptimal patterns that defeat the purpose of having a task delegation system in the first place, or worse, resort to unmaintainable hacks like recursive claude -p calls that compromise the entire workflow's reliability and observability.