Coordinator

Coordinator

Keep the current session in the main seat. The main owns the plan, interfaces, review, verification, and final decision. Workers implement bounded units; they do not own git or silently change the plan.

current main session
├── native specialists: evidence, review, testing, domain expertise
├── native worker-controllers: visible supervision in the host UI/workflow
│   └── cheaper implementation workers: bounded code volume
└── optional advisor: read-only opinion at a commitment boundary

Invoking Coordinator is itself a routing decision: spend the main model on judgment and route bounded implementation to the cheapest authorized worker without waiting for the user to say "cheap workers" or "model arbitrage."

For independent advice at a real decision boundary, use advisor; do not consult by default. For a fan-out larger than the available host slots, also load wave-coordinator.

Progressive loading

Do not read every harness guide. Load only the resources needed for this run:

1. Always read the dispatch contract before sending implementation work.
2. Read exactly one current-host guide: Claude Code, Codex, Grok Build, or OpenCode.
3. For each external worker actually selected, read only its guide: Codex / Sol / Luna / Astra, Grok CLI, Muse Code, or OpenCode CLI. When dispatching raw Codex CLI, also load references/workers/cli-dispatch.md.

Example: a Claude main dispatching an OpenCode worker reads this file, the dispatch contract, the Claude host guide, and the OpenCode worker guide. It does not load Grok, Codex, or Muse instructions.

Ownership boundary

Use a worker only when it is materially cheaper or better for the bounded unit. Every dispatch has a context, specification, and review cost. Split at coherent API or file-ownership boundaries, not into tiny tasks merely to create a graph.

Select a lane

Choose implementation lanes by economics first. Preserve a user-selected cheap lane; otherwise use the cheapest authorized, preflighted worker that can meet the acceptance criteria. A user may attach an expiry or another stop condition to that preference. Record it, honor the override while it is active, then run normal lane selection again when it expires; do not bake a session-specific deadline into the reusable skill. If provider authorization or preference is unresolved, ask once. Do not silently implement on the premium main or native lane.

Prefer native specialists for evidence, investigation, review, testing, and tool- or domain-bound judgment. Match that work against ../deploy-agent-team/references/agent-roster.md; use a generic specialist only when no roster specialist fits. This native-first rule does not apply to routine implementation volume.

External quality lanes are Grok, GPT-5.6 Sol, and GPT-6 Astra (3D / animation / gamification / creative implementation). GPT-5.6 Luna at extra-high reasoning and Muse Spark 1.3 are cheap-volume choices. OpenCode is a portable lane whose provider and model must be pinned. Prefer an already authorized, configured cheap lane over a quality lane when both can satisfy the spec. Never infer or replace the user's current main model.

If the work has deterministic stages, loops, or voting, use a native workflow only when the current host guide says the primitive exists and the user opted into multi-agent work. The script may own control flow; the main still owns the plan, evidence, and ship decision.

Keep external work visible

When the current host supports native subagents, spawn one native worker-controller per independent implementation unit. Give it the spec and the selected worker guide; instruct it to preflight, launch, monitor, and report the external worker without writing the implementation itself. This keeps the cheap worker visible in the host's subagent panel and lets native workflows own its lifecycle. The wrapper is control plane; the cheaper model remains the implementation plane.

Use direct external dispatch from the main only when the host has no usable native child primitive. Do not claim the external model appears as a native agent—the visible item is its controller, and its final report must identify the actual provider/model that performed the implementation.

External-provider boundary

Before first use of an external lane, state which provider will receive the prompt, specification, and selected repository content. Obtain approval unless the user already authorized that lane for the task. Never send secrets, credentials, unrelated proprietary content, or a broader snapshot than the assignment requires. An OpenCode model uses the provider behind its pinned provider/model; verify that destination instead of treating OpenCode itself as the provider.

Run sequence

1. Inspect the task, repository instructions, current state, and the premise behind the requested change.
2. Choose the current-host adapter and the smallest useful worker lane.
3. Read the dispatch contract plus only those selected guides.
4. Preflight the lane. A missing binary, model, authentication, or write policy makes the lane unavailable; never silently absorb the work in the main.
5. Write a precise spec and partition concurrent file ownership.
6. Spawn a native worker-controller when supported; it dispatches in the background while the main keeps useful work moving.
7. At the hard barrier, run an independent read-only review: inspect the actual diff and worker report. Treat missing evidence as unverified.
8. Re-run acceptance unpiped in the main environment, then commit and ship from here. Only the main commits, pushes, or opens a pull request.

Failure behavior

• Infrastructure failure is not a quality failure. Preserve the spec and retry or explicitly reroute it.
• The review and test path share one corrective allowance: re-dispatch the same maker once with concrete feedback. After a second failure, control returns to the main to fix or stop.
• Reject environment-driven workarounds such as replacing dependencies, changing bundlers, removing remote assets, or weakening tests.
• Do not let a worker commit, push, or merge.
• Do not install CLIs, change global configuration, or increase agent depth without user authorization.
• When an advisor was consulted, its disagreement with worker or review output must be explained and reconciled with direct evidence, not ignored.

Final report

Tell the user which lanes actually ran, which provider received content, what each worker returned, what changed, which verification passed, and what remains unresolved. Never imply that a worker or specialist ran when it did not.