Feature Request: Enable Task tool for subagents to support hierarchical agent workflows

Summary

Subagents spawned via the Task tool cannot use the Task tool themselves, preventing hierarchical agent workflows. This is a critical limitation for building sophisticated multi-agent systems.

Previous Issues

This issue was previously tracked in:

• #4182 - Closed as duplicate of #5528
• #5528 - Closed as duplicate of #4182

Both issues were closed in a circular reference (each marked as duplicate of the other), leaving no active issue tracking this feature request.

Current Behavior

When a subagent attempts to use the Task tool, it reports the tool is unavailable. Subagents have access to:

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

Missing: Task tool

Real-World Impact: PR Review Workflow

I have a github-pr-reviewer agent with instructions to:

### Phase 4: Pre-PR Python Test Analysis
- Use the Task tool to launch the python-test-analyzer agent
- Run tests to establish baseline results

### Phase 6: Post-PR Python Test Analysis
- Use the Task tool to launch the python-test-analyzer agent
- Compare against baseline from Phase 4

Result: The agent silently skips these phases because it cannot access the Task tool. Users expect their agent instructions to work, but nested Task calls are impossible.

Expected Architecture:

Main Conversation
└── github-pr-reviewer (subagent)
    ├── Analyze PR changes
    ├── python-test-analyzer (nested subagent) ❌ BLOCKED
    │   └── Run tests, report coverage
    └── Compile review with test results

Current Workaround Required:

Main Conversation
├── github-pr-reviewer (subagent) → Returns partial review
├── python-test-analyzer (subagent) → Manually triggered separately
└── User must mentally combine results

This defeats the purpose of agent orchestration.

Proposed Solution

Enable the Task tool for subagents with appropriate safeguards. Some considerations:

• Depth Limiting - Configurable maximum nesting depth (e.g., 2-3 levels) to prevent runaway recursion
• Resource Controls - Limits on concurrent nested agents, token budgets, and timeout inheritance
• Permission Model - Per-agent configuration for whether nesting is allowed
• Observability - Parent agents can monitor nested agent progress with clear error messages when limits are reached

Why This Matters

1. Agent Composability - Agents should be building blocks that can orchestrate other agents

1. Separation of Concerns - Specialized agents (test-runner, linter, security-scanner) shouldn't be duplicated into every parent agent

1. Context Management - Nested agents prevent context overflow in parent agents

1. User Expectations - The .claude/agents/ system implies agents can be composed; current behavior is surprising

Alternatives Considered

| Approach | Problem |
|----------|---------|
| claude -p via Bash | No visibility, no progress tracking, resource chaos |
| MCP server workaround | Complex setup, no depth limiting, hacky |
| Flatten all agents | Defeats purpose of modular agent design |
| Manual orchestration | Poor UX, user must coordinate multiple calls |

Request

1. Reopen and properly track this feature request
2. Provide official guidance on whether nested agents are planned
3. If not planned, document clearly that subagents cannot spawn subagents so users don't waste time writing impossible workflows

Environment

• Claude Code version: 2.1.22
• OS: macOS Sequoia 15.7.2

Related Issues

• #4182 (closed - circular duplicate)
• #5528 (closed - circular duplicate)