Feature Request: Project Orchestrator Mode

[ian-klopper]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

There's no way to have a persistent planning agent that coordinates multiple cloud agents while maintaining maximum context for decision-making.Current limitations:

Cloud agents work in isolation with no central coordinator tracking them No agent maintains awareness of all active + historical agent sessions No visibility into feature branch → dev merge workflow across agents Planning context gets polluted with implementation details When using Cursor's "move to background" feature, the entire agent transfers to cloud—there's no stationary orchestrator that stays aware of all work.

Proposed Solution

A dedicated Project Orchestrator Mode where one agent:

Plans only - Cannot use Edit/Write/Bash tools, only dispatch and coordinate Tracks all agents - Registry of active, completed, and blocked agents with their feature branches Maximum context - Holds project docs + full agent history + developer conversation Receives summaries only - Completion reports, not execution logs

Alternative Solutions

Current subagents: Don't persist across sessions, no registry of historical work Manual tracking: Developer becomes the orchestrator (defeats the purpose) Cursor background: Moves entire agent, loses the coordinator File-based coordination: Clunky, requires polling, no real-time awareness

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Example workflow: Developer: "Add authentication"

Orchestrator: → Spawns 3 agents on feature/auth-* branches → Updates DECISIONS.md with approach → Reports: "Agent-1 merged schema to dev, Agent-2 on middleware, Agent-3 blocked on design" → Can explain any agent's approach from summary context

Additional Context

This enables a "tech lead" agent pattern where one agent maintains project-level understanding while delegating implementation to specialized workers.

[github-actions[bot]]

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/5898

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ian-klopper]

To prevent auto-closure: This issue is not just related to subagents which Claude skills solved, but also cloud agents.

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

[DrJLWilliams]

Great proposal! I had a similar idea (#20095, now closed as duplicate) and wanted to add a few features that might enhance this:

1. Context Limit Management & Worker Recycling

The orchestrator should monitor worker context usage and automatically recycle sessions before they degrade:

workerHealth: {
  contextUsage: 0.72,      // 72% of context window
  warningThreshold: 0.75,  // warn at 75%
  criticalThreshold: 0.90  // force recycle at 90%
}

Recycling flow:

1. Detect worker approaching context limit
2. Capture current state (task, progress, files changed)
3. Spin down old session
4. Spin up fresh session with summarized handoff
5. Worker continues seamlessly

This solves the "session getting tired" problem automatically.

2. Orchestrator Self-Monitoring

The orchestrator itself has a context window. It should:

• Track its own usage and warn when getting full
• Export state for manual resume when critical
• Gracefully hand off to a fresh orchestrator session

3. Direct Communication Mode

Sometimes you want to bypass the orchestrator and talk directly to a worker:

/direct agent-2
[Now talking directly to agent-2, orchestrator monitors silently]

/coordinator  
[Back to orchestrator mode]

The orchestrator becomes a "supervisor" that can interject with useful context ("Agent-1 solved this yesterday, check commit abc123") but stays quiet otherwise.

4. Multi-LLM Orchestrator Option

The orchestrator's job (task decomposition, routing, summarization) is different from the workers' job (coding). Consider allowing different models:

• Orchestrator: Sonnet (fast, cheap, good at meta-work)
• Workers: Opus (best at complex coding)
• Or even GPT-4 as orchestrator + Claude Code workers

This could optimize cost and leverage different model strengths.

---

Happy to elaborate on any of these. Full spec doc with architecture diagrams available if helpful.