[FEATURE] Project Contractor Mode — make task and agent orchestration an implementation detail

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

Claude Code is already extremely capable, but the user still has to act as the project manager for the agents.
For a substantial project, I have to decide how to decompose work, when to create tasks, when to use subagents or Agent Teams, which model should handle each job, when to start a new context, when to request an independent review, how to manage worktrees, and even when part of a repository has effectively become a separate project.
This creates a significant entry barrier for less experienced developers, domain experts and vibe-coding users. The difficulty is increasingly not “can Claude do this?” but “do I know how to organise Claude so it does this efficiently?”
There is also a real usage cost. In my own workflows I have seen parallel/subagent approaches consume dramatically more tokens than doing the same bounded work in the main session. This has led me to actively discourage Claude from spawning agents unnecessarily.
The user should not need to become an expert in agent orchestration just to use increasingly capable models efficiently.

Proposed Solution

Add an optional persistent Project-level orchestration mode, which I think of as a Contractor Mode.
The user would work with one persistent project-level Claude:

1. Discuss what they want to build.
2. Explore the architecture and constraints together.
3. Develop and approve the project plan.
4. After approval, let Claude orchestrate execution.

The Project agent could then:

• create and maintain appropriate issues/tasks;
• decide sensible task boundaries;
• choose models and reasoning levels where applicable;
• decide whether work should be sequential, delegated or parallel;
• use subagents/Agent Teams only when their expected benefit justifies the additional usage;
• manage dependencies and worktrees;
• commission independent reviews;
• track project state across individual execution contexts;
• recognise when architectural or repository boundaries should change;
• update the plan when the user changes direction.

Tasks, subagents and Agent Teams would still exist. They would simply become execution mechanisms managed by the Project agent, rather than mechanisms the user has to operate manually.
The analogy is a contractor: I discuss the project, priorities and changes with the contractor. I am not expected to coordinate every individual worker myself.
User manages project intent → Project Claude manages the workflow → task agents execute the work.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I am developing a project that gradually grew into several distinct components. I started with almost no practical software-development experience and did not even know how to use Git or GitHub properly, so I had to learn project structure, task management and agent orchestration while building the product itself.
As the project grew, I initially kept everything in one repository and tended to perform planning and implementation inside one or two very long Claude Code sessions.
Today I understand that I should analyse the architecture, establish repository boundaries, create migration plans, break those into issues, execute them in isolated contexts, and independently review each migration.
Claude is already capable of doing all of those things. The problem is that I currently have to know that this is the correct workflow and manually orchestrate it.
In Project/Contractor Mode I could instead say:
“This repository appears to have evolved into several separate projects. Help me determine the correct architecture and migrate it safely.”
Claude and I would agree on the plan, and after approval the Project agent would manage the execution workflow economically and safely, returning to me only when a genuine project-level decision is needed.

Additional Context

I see this as an optional layer, not a replacement for Claude Code’s existing workflow. Advanced users should retain direct control over sessions, tasks, agents and teams.
It would be particularly useful for users who know the outcome they want but do not yet know software-engineering and agent-orchestration best practices.
The Project agent should optimise for:
quality + reliability + total usage + latency
rather than maximising agent count or parallelism.
Several existing requests address pieces of this:

• #24798 — inter-session communication and dependency sequencing
• #56913 — persistent orchestration with PM/worker roles and reduced orchestration overhead
• #60995 — an architectural planning layer above Plan Mode

This proposal is one abstraction level above those. It is not primarily asking for more orchestration controls. It is asking Claude Code to operate those controls on behalf of the user, through one persistent project-level relationship.
I think the current models are already powerful enough that reducing this orchestration learning curve could materially expand who can use Claude Code effectively. The models have lowered the barrier to writing software; the next barrier is learning how to manage the models themselves.