Orchestration overview

Orchestration lets a provider coordinate visible agent sessions through super.engineering. You ask for an outcome in ordinary language; the provider chooses the documented sc commands needed to create sessions, route work, collect results, and manage the layout.

LeadOwns scope and integration

Parallel roles

APIServer contract

UIUser flow

TestsFocused checks

ReviewerChecks the integrated result

The lead assigns independent work, integrates the results, and starts a fresh review.

How invocation works

The most reliable invocation names both the tool and the action:

The following signals also activate app-managed orchestration:

Say orchestrate or orchestration.
Name another provider or model, or ask for several providers or models.
Ask for app-managed UI behavior such as visible sessions, tabs, panes, views, splits, or side-by-side agents.

Ordinary requests for “agents,” “subagents,” “delegation,” “parallel work,” or a “team” use the current provider’s native agent tools. They do not invoke super.engineering orchestration. An explicit request for native subagents always stays native.

What the app injects

When orchestration is enabled, super.engineering injects a small, trusted tool-use contract into each new Chat UI and Terminal agent session. The provider learns:

which human requests authorize app-managed orchestration;
when to use native subagents instead;
that it must load the current orchestration and layout guides before changing managed state;
that it must discover live providers, models, surfaces, and existing targets;
that enabling the feature does not grant standing permission to use it; and
that worktree creation is never an implicit delegation mechanism.

The app injects this context alongside your request. You do not need to paste CLI commands, reproduce the contract, or tell the provider how to implement fan-out and fan-in. The provider loads detailed instructions on demand and translates your intent into the current sc workflow.

Durable team runs add a second layer of role-specific context. Each teammate receives its role label, run ID, reporting path, and completion contract automatically. You do not need to teach individual roles how to report.

Get the current CLI documentation

The CLI documents the installed app version. Run these commands yourself, or ask the provider to run them when you need to inspect or troubleshoot its workflow:

sc help
sc help team
sc help agent
sc instructions
sc instructions orchestration

sc help prints the command surface. sc help <command> provides focused syntax and behavior where available; useful topics include team, agent, agents, worktree, and coordination-state.

sc instructions lists the agent-facing operational guides. sc instructions orchestration explains when and how a provider should use app-managed orchestration. The related layout, worktree, and review guides cover their managed state.

The provider’s injected context tells it to load the relevant guide before acting. This on-demand documentation keeps prompts short and prevents copied command sequences from becoming stale.

Write prompts around intent

A useful orchestration prompt has three possible parts:

Invocation: make app-managed orchestration explicit.
Outcome: state the result and what “done” means.
Material constraints: include only choices that would change the workflow or result.

For example:

Use the sc CLI to orchestrate the checkout feature through implementation, verification, and an independent review. Preserve the public API, and ask before adding dependencies.

This prompt leaves team size, labels, command selection, and report mechanics to the provider. Add those details only when you care about them.

Useful constraints include:

Concern	Example
Autonomy	“Proceed autonomously, but ask before schema changes.”
Providers or models	“Use Claude to lead and a fast Codex model for narrow implementation tasks.”
Substitution	“Do not substitute a provider or model without asking.”
Visibility	“Keep the lead and active implementer visible side by side.”
Sequence	“Finish implementation before launching an independent reviewer.”
Verification	“Run the repository checks and verify review findings before applying them.”
Scope	“Use the existing worktree and do not create branches.”

Let the provider choose the mechanics

Avoid prescribing a team topology before the provider inspects the task. A request for four roles, exact labels, and a particular command sequence can create needless handoffs or force dependent work to start in parallel.

Prefer:

Use the sc CLI to orchestrate this change. Inspect the repository, choose the smallest useful team, and carry it through verification.

Use a more specific prompt when the structure itself matters:

Use the sc CLI to orchestrate a strict design → implementation → review sequence. Pause for my approval after the design.

The provider should decide whether to use a durable parallel team run or manually sequenced sessions. It should also choose labels, inspect capabilities, wait for completion, read results, and verify agent claims.

Initial requests and follow-ups

Every standalone initial request needs an invocation signal. After the provider has created labeled sessions, follow-ups can refer to the live workflow directly:

Ask the backend role to preserve the existing schema.

Wait for implementation to finish, then begin the independent review.

Bring the blocked role beside the lead.

Use a fresh session when independent context matters. Reuse an existing role when continuity matters.

If the provider does not invoke orchestration

Repeat the recommended invocation and distinguish it from native subagents:

Use the sc CLI to orchestrate this with app-managed sessions, not native subagents.

If the provider still describes a plan without acting, add an operational nudge:

Run sc instructions orchestration, then begin the app-managed workflow.

Exact commands are most useful for automation, diagnostics, or deliberate low-level control. They should not be required in an ordinary orchestration prompt.

Explore orchestration

Prompt patterns explains how much direction to include and offers adaptable examples.
Team workflows covers parallel work, sequential handoffs, integration, and review.
Cross-provider teams covers provider and model routing, including fast models.
Agent communication covers peer questions, lead-owned decisions, and follow-ups.
Layouts and control covers visible sessions, observation, redirection, and cancellation.
Coordination state explains when shared machine-readable state helps.

See CLI automation when you need the exact public command surface.