App-managed orchestration runs agents in normal views, tabs, and panes. Asking for visible sessions, a split, or a side-by-side arrangement invokes layout orchestration when the feature is enabled.
The app injects layout-aware context into the provider session. The provider loads the current layout guide, inspects existing views and capabilities, and translates your request into documented sc commands.
Describe the experience
Section titled “Describe the experience”Prompt for the arrangement you want:
Orchestrate this with the lead and active implementer visible side by side. Keep the reviewer in a tab until review begins.
Or invoke orchestration through the layout request itself:
Run Claude and Codex side by side in visible app-managed sessions while they compare these approaches.
You do not need to specify view indexes or launch commands. The provider resolves the current layout before choosing targets.
Choose a container when it matters
Section titled “Choose a container when it matters”| Container | Use it when |
|---|---|
| View | You want top-level work areas visible side by side |
| Tab | You want several full sessions collected in one view |
| Pane | You want closely related sessions visible within one tab |
For example:
Put the lead in the left view and collect implementation roles as tabs on the right.
Keep the API and UI roles in adjacent panes while they settle the shared contract.
If the exact container does not matter, describe visibility and let the provider choose.
Adapt the layout by phase
Section titled “Adapt the layout by phase”The best arrangement can change as work moves from implementation to review:
Keep the lead visible throughout. Bring a blocked role beside it when they need to resolve an issue, then bring the reviewer forward after integration.
Moving a session preserves its context. Relaunch only when you intentionally want a fresh session.
Observe progress
Section titled “Observe progress”Ask for evidence, not just target status:
Summarize each role’s current task, changed files, verification, blockers, and next step. Wait for unfinished roles before reporting final results.
The provider can inspect target state, wait for completion, and read output. A successful launch or message confirms dispatch, not completion.
Redirect work
Section titled “Redirect work”Use interrupt when the current turn must stop before a correction:
Interrupt the backend role, tell it to preserve the existing schema, and continue in the same session.
Queue a follow-up when the current work may finish safely:
Send the finalized API contract to the frontend role after its current check finishes.
Both preserve the session’s context.
Stop, cancel, close, or force-stop
Section titled “Stop, cancel, close, or force-stop”These requests have different effects:
| Request | Intended effect |
|---|---|
| Interrupt | Break the current turn and keep the session for a correction |
| Stop | Cancel an active turn and leave its session visible |
| Cancel the team run | Ask every unfinished role in that run to stop |
| Close | Remove a tab, pane, or view from the layout |
| Force-stop | Kill an unresponsive terminal process as a last resort |
Examples:
Cancel the current team run, but leave its sessions visible for inspection.
Stop the research role normally. Force-stop it only if the terminal does not respond.
Save arrangements
Section titled “Save arrangements”You can ask the provider to save or apply reusable layouts:
Save this arrangement as
cross-provider-feature-teamat user scope.
Apply my worktree-scoped
review-gridlayout, then start one reviewer in each tab.
A saved layout stores the arrangement, not providers, prompts, or workflow policy. Applying one does not launch agents unless you also ask for sessions.
For exact low-level syntax, see CLI automation.