Team workflows

An orchestration request can leave the workflow open or constrain the parts that matter. In most cases, describe dependencies, ownership, and approval points; let the provider choose the sessions and commands.

Let the lead choose

Use this when the outcome matters more than the team design:

Orchestrate this feature through implementation and verification. Inspect the repository and choose the smallest useful team.

The provider may decide that one session should do the work. Orchestration authorizes app-managed coordination; it does not require delegation.

For a read-only proposal first:

Use orchestration to inspect this task and propose a workflow, ownership split, and verification plan. Wait for my approval before launching sessions or editing files.

Parallel work

Ask for parallelism when assignments can start independently:

Orchestrate a parallel review of this diff for correctness, security, and reliability. Give every reviewer the same verified checkpoint, require evidence, and return one deduplicated result.

For implementation:

Orchestrate this feature. Parallelize only work with clear, non-overlapping ownership; keep shared contracts and integration with the lead.

Under the hood, the provider can use a durable team run. It launches all roles together, gives each role reporting context, and returns their terminal reports to the creating lead. A launch confirms dispatch, not completion; the lead must collect and verify the results.

Parallel fan-out is a poor fit when one role needs another role’s unfinished output. State the dependency instead of naming a command.

Sequential handoffs

Ask for a sequence when one phase must finish first:

Orchestrate a strict design → implementation → review workflow. Show me the design and wait for approval before implementation. Start the independent review only after implementation passes verification.

Without a human checkpoint:

Orchestrate this change through implementation and a fresh independent review. Complete and verify each phase before starting the next.

The provider implements a sequence with labeled sessions, completion waits, and result reads. A durable team run starts all roles at once, so it cannot enforce a strict handoff by itself.

Lead and implementers

A lead is most useful when work shares contracts or needs integration:

Orchestrate the checkout feature. Let the lead own decomposition, shared decisions, integration, and final verification. Delegate only bounded work with clear ownership.

Name likely boundaries without forcing them:

Consider separate API, UI, and test ownership if repository inspection shows clean boundaries. Reduce the team if those areas overlap.

This tells the provider what good decomposition looks like while preserving its ability to adapt to the code.

Independent review

Fresh context matters more than a large review panel:

Orchestrate implementation through independent review. After integration and passing checks, use a fresh read-only session to look for concrete regressions, missing tests, and unsupported assumptions. Verify each finding before changing code.

Reuse an existing implementer when sending back confirmed findings. Create a fresh reviewer when you want an independent perspective.

Direct collaboration

You can choose how decisions flow:

Let roles resolve routine questions about shared interfaces directly. Escalate changes to architecture, scope, or ownership to the lead.

Or keep control centralized:

Route all design and ownership decisions through the lead. Peers may exchange factual information directly.

The provider assigns stable role labels and uses app-managed messages. You do not need to specify addressing commands.

Existing worktrees

Orchestration can target worktrees that already exist:

Orchestrate a comparison of the two existing worktrees I named. Verify both independently and explain the tradeoffs without merging either branch.

Creating a worktree or branch always requires a separate explicit human request. Orchestration does not create one merely to gain parallelism.

Adjust a running workflow

After sessions exist, short follow-ups preserve their context:

Ask the UI role to wait for the API contract, then continue in the same session.

Stop the research role, but leave its session visible.

Start a fresh reviewer focused on backward compatibility.

Use the existing role for corrections and continuity. Ask for a fresh role only when new context or independent judgment matters.