Reusable multi-agent orchestration workflow

Claude Code issue draft: reusable multi-agent orchestration workflow

Problem

Claude Code can use subagents, commands, hooks, and model routing, but users
still need to manually describe a repeatable orchestration process for large
parallel tasks.

The desired workflow is:

• strongest model plans and decomposes work;
• cheaper subagents execute isolated tasks;
• subagents start with zero context but receive detailed packets;
• subagent questions route to the orchestrator;
• the user is asked only when the orchestrator cannot answer;
• final validation is run by independent verifier agents.

Proposed Claude Code capability

Add a project-level orchestration command such as /orchestrate backed by
project subagents and hooks.

The command should:

1. Read project instructions and inspect the repository.
2. Build a parallel work graph with dependency ordering.
3. Generate task packets for each subagent:

• goal and success criteria;
• write scope;
• forbidden paths;
• exact commands to run;
• assumptions/default decisions;
• when to escalate;
• final output contract.

1. Route implementation to cheap models by default.
2. Reserve the best model for decomposition, conflict resolution, integration,

and final review.

1. Spawn validation agents after implementation.

Claude-native mapping

• .claude/agents/: define reusable worker profiles such as planner,

implementer, validator, and integrator.

• Slash commands: expose /orchestrate, /orchestrate:plan, and

/orchestrate:validate.

• Hooks:
• SessionStart: load orchestration defaults;
• SubagentStart: inject task packet and local rules;
• SubagentStop: collect result summaries;
• Stop: continue integration if pending worker output remains.
• Skills: package task-packet templates and validation checklists.
• Model routing: use cheapest viable models for bounded tasks and stronger

models for planning/integration.

Question policy

Subagents should not ask the user directly. They should either use the documented
default or return:

QUESTION_FOR_ORCHESTRATOR:
<specific missing decision>
<why no safe default exists>
<what options are viable>

The orchestrator answers from local context when possible and asks the user only
when the decision is genuinely external.

Acceptance criteria

• A project can define the orchestration process once and reuse it.
• Subagents receive zero-context task packets that are detailed enough for cheap

model execution.

• Work is parallelized without write-scope conflicts.
• The orchestrator integrates results and runs validation waves.
• User interruptions are minimized without bypassing necessary product/risk

decisions.