Orchestration

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

Projects — a chunk of work with its own context

Orchestrate → Projects. A project is a brief plus the shared knowledge its team works from. Close it and the whole thing is archived — then the same running agents are handed a cleared workspace and the new brief. Nothing restarts; only their context changes. Agents carry an index of archived projects (names and one-line goals), so one knows a closed project exists without its content being loaded; ask and it can be opened again.

Pipelines — the plan that already worked

The Foreman decides a plan each time. A pipeline is the plan you keep: agent steps you design once on a canvas and re-run, with gates where you want a say, checks a step's "done" has to survive, per-step tool scope, and containers for the steps that need a stack up. Full guide →

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).

• Workers count against a max workers cap you set (default 4).
• Send the plan back with feedback instead of approving — the Foreman revises.
• The Foreman talks to AIOAT through a local, per-run-token API; it can't do anything you couldn't do in the UI.
• No repo? No problem. Choose No repo — git-free and workers run in scratch folders instead of worktrees: no branches, no diffs, shared knowledge at the workspace level. Good for research, writing, and anything that isn't a codebase.
• The Foreman runs locally (it needs AIOAT's tool server). For a team on a remote host, launch a remote Claude with team files provisioned — it delegates to its own subagents there.

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.