Orchestration

Beyond launching agents by hand: delegate whole goals, follow a phased plan, and see everything at once.

The Foreman β€” delegate a goal

Orchestrate β†’ Foreman (or pick the πŸ— Foreman role in + New Agent): give it a high-level goal and a repo. The Foreman is a coordinator agent that reads the shared context, proposes a task plan, and β€” only after you approve the plan β€” spawns worker agents, each in its own worktree, visible as normal sessions. It tracks task status as workers finish and can be stopped at any time (workers keep running; they're yours).

Specialists

The Foreman assigns each worker a specialty that fits its task: Planning & architecture, Frontend, Backend, Code review, Testing & QA, Reports & docs, DevOps & tooling. The worker's prompt opens with that role's briefing, and its card is labeled accordingly ("Frontend β€” settings page"). Your own subagents join the roster automatically: import your .claude/agents/*.md definitions and the Foreman can assign, say, freja by name β€” the imported definition becomes the role briefing.

GSD planning

If a repo uses the GSD framework (a .planning/ folder with phases and a STATE file), AIOAT surfaces it: Orchestrate β†’ GSD planning shows the phase board with per-phase status read from what's actually on disk, the parsed STATE card with progress, and the planning file tree. /gsd-* commands are one palette-press away (typed into the active session), a GSD install command sits in the pane, and agent cards show their repo's active phase. The Foreman has a GSD mode that drives work phase-by-phase through the framework's own commands.

Canvas β€” the overview mode

Orchestrate β†’ Canvas lays every live session out as cards on an infinite pan/zoom surface: state, last output, and the relationships between them β€” who spawned whom, who handed a selection to whom, who shares context with whom. Drag cards to arrange; save arrangements as named Spaces per workspace. Right-click a card for close/kill/remove. Good on a second monitor while you work in the main window.

Busy sessions also show a βš™ sub-process line β€” what's actually running underneath them (nodeΓ—2 Β· git Β· esbuild), with memory per process in the tooltip. Note that an agent's internal subagents aren't separate OS processes, so what you see is the real child processes it spawned: builds, tests, git, nested CLIs.

A/B agents

Palette β†’ β€œAgents: A/B test”: the same task runs twice on twin branches (agent/ab-…-a and -b) with different configurations β€” different CLIs, models, or extra prompt guidance per variant. Both land in the review inbox; compare diffs and test results, merge the winner, discard the loser.

Cross-AI peer review

From the review inbox: Peer review hands a branch's capped diff to the other installed agent CLIs as read-only reviewers β€” Codex and Gemini critiquing Claude's branch, or any combination. Reviews arrive as normal sessions you can read and forward.

Model routing & escalation

Launches accept a model override, and the failure-tier helper suggests the next rung up your ladder (e.g. sonnet β†’ opus) when a task keeps failing β€” spend the expensive model where the cheap one struggled.