Implementation for M1–M5 controls + UX polish (/oss / /deterministic ADI pools, mid-turn /btw steering, /interrupt, live /captain director helm, runnable-director selection) has landed in source. What follows separates shipped foundations from remaining evidence and packaging. Dates and completion criteria are planning guides, not release promises.

Already implemented

Captain combines native CLI workers and configured API models, routine value ranking, director-planned teams, eligible provider-failure recovery, model chains with test gates and local run records. The routine ranking uses expected quality, estimated cost, observed duration and inferred subscription pressure. Local assessments and reliability affect later choices. The director helm only settles on a leg that can actually run on the machine.

Also in source today: decision evidence (captain why), capability registry and doctor probes, quota telemetry, shared attempt/cost budgets (captain budget), bounded escalation, worktree isolation, patch manifests, durable lifecycle/cancel/resume, structured handoffs, versioned task API, captain task mcp, Go host helpers (captain host …), outcome/calibration/policy plumbing, ADI feed + /oss / /deterministic pools (captain adi), mid-turn /btw steering (claude + opencode legs), /interrupt with handoff or partial keep, and live director helm via /captain.

Provider session reuse exists, but a handoff to a different provider does not transfer its hidden state or cache. Dollar cost caps are tracked; they are enforced as a hard gate only in strict mode against cost-reporting adapters.

Still open (evidence & packaging)

• Publish the M1 baseline report from the 12-task pilot (including blinded human review and cost attribution against an accounting-capable brain).
• Productize Pi / Jido / editor packaging beyond the Go helpers and live-brain certification.
• Surface correction-time outcomes in the TUI (CLI outcome commands already exist).
• Keep dollar-cap honesty: admission vs strict mode remains the documented contract.

1. Make the promise reproducible

Outcome: a builder can install Captain and verify what routing gains or costs on a representative workload.

• Finish public-release preparation and provide versioned installation instructions with a worker compatibility checklist.
• Compare automatic routing, a fixed frontier worker, a fixed economical worker and explicit workflows on the same tasks.
• Measure accepted results, total time and manual corrections. Count planning, reviews, retries, context transfer and cached tokens when reported.
• Separate API spend, subscription fees and quota consumption; show unknown usage explicitly.

Complete when: a clean macOS/Linux setup passes the documented path, and a reproducible evaluation reports quality and full task economics by task category. Publish savings claims only for conditions supported by those results.

2. Give routing a clear contract

Outcome: you can understand a pick and control the resources it may consume.

• Expand existing routing reasons into a view of candidate tradeoffs, evidence freshness and uncertainty.
• Make frontier selection a capability-based policy across available workers. Today, /frontier specifically requests Claude at maximum effort; explicit worker names should remain available.
• Add supported provider quota readings where available, retaining inferred or unknown status elsewhere.
• Share resource limits across planning, workers, reviews and retries. Offer hard API spend ceilings only where an adapter can enforce a bound across the full run; label estimated budgets and use time/attempt limits elsewhere.
• Use failed checks and user rejection to trigger a bounded escalation policy. Keep successful inexpensive attempts inexpensive.

Complete when: routing reasons are inspectable, quota data is labeled by source and freshness, and fault-injection tests show the documented budget policy holds through retries and cancellation. Tests also demonstrate that escalation improves acceptance on the evaluated tasks without hiding its additional cost.

3. Make multi-agent execution dependable

Outcome: independent workers can make changes without trampling each other’s files or repeating completed work after a restart.

• Add per-worker worktrees or isolated execution, explicit merge review and consistent permission boundaries across adapters.
• Persist workflow checkpoints, artifacts and cancellation state. Resume unfinished stages with replay protection for commands that may have side effects.
• Reuse native sessions when valid and send compact, structured handoff briefs between runtimes.
• Evaluate persistent reviewer/worker pairs and switching costs before introducing more mid-task routing.

Captain owns execution checkpoints and patch integration. Worktrees isolate file changes; process and network boundaries depend on the adapter. If an interrupted action's outcome is unknown, recovery must reconcile it before retrying.

Complete when: concurrent-edit, crash, timeout and provider-limit scenarios preserve the correct artifacts and surface merge conflicts. Resuming a workflow must not silently repeat completed side effects. A cache optimization ships with measured benefit.

4. Bring Captain into other harnesses

Outcome: use Captain’s coordination without adopting its terminal as your primary interface.

• Stabilize a versioned task API, then expose a scoped MCP bridge for planning, execution, status, cancellation and artifacts. Shipped as captain task mcp and /v1/task.
• Carry project scope, permissions, budgets and request identity through every delegation. Prevent a worker from recursively delegating back to itself.
• Validate a small set of integrations first: Pi, Jido and an editor MCP client.
• Explore an Omnigent routing adapter and native workers for tuned harnesses such as Fusion or Amp when their supported interfaces permit it.

Complete when: the same bounded task completes, cancels and resumes through the selected hosts with equivalent permission and budget behavior. Recipes must distinguish tested integrations from suggested wiring.

5. Learn which combination earns its cost

Outcome: routing improves because accepted outcomes, not only model priors, drive the next pick.

• Keep accepted/rejected evidence, correction time and later regressions with provenance.
• Calibrate quality estimates by task family; age stale samples.
• Compare one worker against a team, including coordination overhead. Use additional agents when the expected improvement justifies them.
• Evaluate new routing policies on held-out tasks before enabling them broadly. Keep project data local by default.

Captain keeps authoritative acceptance and routing-policy records. Receipt verification never substitutes for acceptance evidence.

Complete when: a policy change improves cost or completion time per accepted task at a stated quality target, with reproducible evidence. A shared leaderboard is optional later work, not a prerequisite for useful personal routing.

What this direction prioritizes

Honest measurement over marketing claims. Portable coordination without forcing a new primary IDE.

A new editor, hosted multi-tenant service and public model marketplace are outside this sequence. Connect to existing environments where that serves builders better. Broader platform support should follow evidence of demand and reliable adapters.