Workflow / from mission to reviewed change
Multi-agent work & Swarm
One lane owns the mission. Subagents handle bounded pieces. You stay close to the decisions, the evidence, and the final diff.
Two levels of parallel work
Several lanes: separate tasks, each with its own parent agent and, by default in a Git repo, an isolated worktree. The home board helps you find what needs attention.
Several subagents inside a lane: the parent delegates focused work through the optional pi-subagents package, answers scope questions and integrates results. A child is not another top-level lane. Child isolation and workflow policy belong to pi-subagents, not a second Phosphor scheduler.
Authorize proactive delegation
Use a Phosphor build that includes the Swarm switch. Updating the app does not retrofit its command into an already-running Pi process.
- Install
pi-subagentsfrom Settings → Extensions if it is not already available. Start a new lane or reload/restart Pi in an existing one. - Open the lane’s composer and turn on Swarm. The highlighted switch, amber outline and title badge reflect Pi’s acknowledgement, not just a local preference.
- Give the parent a goal, ownership boundaries, acceptance criteria and a verification plan. Swarm authorizes delegation when useful; it does not immediately launch a team.
/phosphor-swarm onThis slash command is an alternative to the switch, not a shell command. If it is missing, the lane’s Pi process needs a reload/restart. Activation is unavailable when the pi-subagents tool surface is missing or excluded.
A change during a run stays pending until a safe turn boundary. Swarm survives resume and compaction on that session branch. Forks, clones and Rewind start off under their new session identity.
Off is not Stop
Turning Swarm off removes its standing authorization from future requests. It does not cancel existing children, erase past messages, remove already-loaded tools or undo token spend. Explicitly requested delegation and project-authorized delegation still follow normal rules. Use the existing Stop controls when you want execution to stop.
Choose models for the job
For example, use Astra to explore the architecture, Opus 5.5 to orchestrate and integrate, and Sol 6.1 for scoped implementation and separate reviewer runs. These are example assignments, not automatic routing, default presets or a claim that one model is always best.
The parent model is selected in Phosphor. Child models and thinking levels are selected through pi-subagents’ run options or configured role policies. Do not assume a child inherits the parent’s live thinking level. Only ask for models available in your pi configuration.
Claude Pro/Max can supply Opus through pi-claude-cli and the Claude Code CLI. Pi still owns the tools and agent loop; Phosphor is not a separate Claude model client. Set up providers and subscriptions.
A mission brief you can adapt
Build the machine-enrollment feature.
Plan the boundaries first. Use Astra for architecture exploration,
Opus 5.5 for orchestration, and Sol 6.1 for implementation and
independent review if those models are configured. Ask before substituting.
Split independent work into enrollment API, Host lifecycle,
Desktop status, and docs. Give each worker owned files and
acceptance criteria. Require approval for shared-file changes.
Preserve work and decisions if a worker fails. Review each result
independently, integrate accepted changes, then validate the whole.
Do not deploy or merge without my approval.This is a prompt example, not an installer or a built-in workflow. The parent chooses concrete tool calls under the available extension’s contract.
Inspect work, not just activity
- The current-work summary separates parent activity from reported foreground and background work. Task links open the corresponding inspection, even when another pane was open.
- The Subagents pane keeps navigation separate from scrolling activity. Dock, resize or fullscreen it without making a new runner.
- Missing status is unavailable, not proof of completion. A long-running tool is not automatically stalled. Attention signals are addressed to the parent.
- A completed execution is not independent acceptance, and accepted pieces are not proof that the integrated change passes. Keep those checkpoints separate.
- Save a bounded inspection snapshot when you want to retain that evidence in Artifacts. Review the final diff and the project’s checks before approving a merge.
Real example: Phosphor Remote Hosts
The homepage uses selected records from Phosphor’s own Remote Hosts lane. Astra and Opus 5.5 appear in the parent’s recorded model metadata at different stages; Sol 6.1 was assigned to workers and independent reviewers. This was explicit delegation before the Swarm switch existed, not a demonstration of that switch running.
In one recorded phase, the parent coordinated four pieces: enrollment API, Host lifecycle, Desktop live status and documentation. A worker requested an exception to its owned files for shared shutdown behavior. The parent approved a minimal hook with unchanged defaults and tests. Another worker lost its connection; a replacement resumed retained work with the prior decisions in its brief.
The public implementation trail includes the control schema, Linux credential storage, Desktop machine approval, the combined site/API server, and Host identity. These are evidence of individual changes, not a claim that every Remote Hosts capability is complete or deployed.
What the image represents
It is a curated replay in the actual renderer, not an untouched live screenshot. The excerpt is shortened, section headings are editorial, task labels are expanded, and identifiers, local paths, unrelated projects and deployment details are omitted. The four workstreams’ historical activity comes from the parent’s recorded report. No timing, token savings or speedup benchmark is claimed. No private transcript is distributed.
Power without hidden promises
Worktrees separate changes, not permissions. Agent tools run with your access unless you install a permission gate. More agents can consume more tokens, memory and provider quota. Swarm adds no hard spawn budget, cloud runner, automatic model assignment or automatic approval to deploy or merge.
Remote-access development is separate from local delegation. Check the current remote-access contract before treating a planned capability as available.
The exact Swarm state, branch and timing rules live in Swarm authorization. For installation, see the subagents package guide.