Orchestration: opt-in model-agnostic execution workers

[bearmug]

Summary

Turn orchestration into an explicit, opt-in execution-worker plane. A user may select any configured model—local, low-cost, hosted, high-context, or privacy-preserving—for bounded work while the frontier model remains the controller and final reviewer.

This issue is about harmonizing responsibilities across Pi-Rogue systems, not introducing a universal API. Reuse existing runner, ledger, context-broker, and telemetry contracts where they fit; eliminate overlapping authority and hidden dispatch.

Motivation

The Qwen incident in #371 showed that worker execution needs clear ownership and reliable timeout/budget reporting. The worker must be an execution capability, not a second controller, autonomous router, or hidden fallback path.

Authority and responsibility boundaries

System	Owns	Must not own
Frontier/controller	Intent, decomposition, dispatch, approvals, tool grants, validation, final decisions	Unreviewed worker output becoming authoritative
Orchestration	Goals, loops, consent scope, worker lifecycle, cancellation, completion	Hidden dispatch or model-quality judgments
Worker executor / pi-subagents	One bounded execution task and evidence return	Policy, approval, merge, or fallback decisions
Context Broker	Bounded handoff context and durable artifact references	Worker lifecycle or routing decisions
Advisor / read-only board	Strategic critique, risk flags, and worker-output review	Dispatch, spend approval, or autonomous steering
Router	Trajectory observation and future routing recommendations	Spawning workers or silently switching the controller
Fusion	Explicit model-only panel/judge/synthesis flows	Implicit agent/workflow execution
Model provider	Inference	Tool policy, filesystem access, or orchestration authority

User control

The user explicitly opts in for a run or session and selects a configured model reference directly. Pi-Rogue may suggest models by observed characteristics (fast, local, private, low marginal cost, high context), but suggestions are not policy and there are no mandatory profiles.

Proposed explicit commands:

/pi-rogue-orchestration worker ask
/pi-rogue-orchestration worker use <model-ref>
/pi-rogue-orchestration worker status
/pi-rogue-orchestration worker clear

Default behavior remains frontier-only.

Execution lifecycle

User opt-in → Frontier dispatch → Orchestration lifecycle → One bounded worker
                                      ↓
                           Context Broker/artifacts
                                      ↓
                     Frontier validation → optional Advisor critique
                                      ↓
                         Router records observation only

The frontier decides whether to accept, retry, change model, escalate, or ask the user. Worker failure must never trigger an implicit paid-model fallback.

Worker controls

Every run must have explicit, centrally enforced:

• model reference and provider identity;
• bounded task and context;
• allowed tools, paths, network, and secrets policy;
• wall-clock deadline;
• turn, tool-call, token/cost, and concurrency limits;
• cancellation and termination behavior;
• structured outcome and provenance;
• artifact/diff references.

Soft warnings request wrap-up; hard limits terminate with an unambiguous classified outcome. "Unlimited" or flat-rate inference still receives operational safety bounds.

Raw runner traces remain owned by the runner. The Context Broker stores bounded summaries and references rather than duplicating transcripts.

MVP scope

• One worker per task.
• Explicit run/session opt-in.
• Any configured model reference; no opinionated profiles.
• Read-only/research and structured-result tasks first.
• Frontier review required before consequential action.
• User-managed inference-server lifecycle; Pi-Rogue probes but does not start or stop it.
• Default-off behavior and no silent fallback.
• Reuse existing orchestration, pi-subagents, Context Broker, router telemetry, and artifact mechanisms where responsibilities already fit.

Acceptance criteria

• Frontier model remains unchanged before, during, and after worker execution.
• No worker runs without explicit user approval.
• User can select any configured model reference directly.
• Worker lifecycle is explicit: dispatch, running, completed, failed, timed out, cancelled, or budget exhausted.
• Timeout, turn, tool, token, and cancellation outcomes are distinguishable and persisted with provenance.
• Worker output is reviewed by the frontier model before consequential action.
• Read-only advisor/board can critique output but cannot dispatch, approve spend, or steer live execution.
• Router remains observation/recommendation-only unless the user explicitly enables its separate model-switch behavior.
• Fusion remains an explicit model-panel feature and is not an implicit worker path.
• Tests cover default-off behavior, approval scope, model mismatch, endpoint loss, cancellation, timeout, budget exhaustion, and no-fallback behavior.
• Documentation explains responsibility boundaries and the user-facing command surface.

Non-goals

• Autonomous advisory-board control.
• Live board monitoring or worker-to-worker delegation in the MVP.
• Automatic model discovery, ranking-based dispatch, or fallback.
• Worker pools, distributed queues, leases, or load balancing.
• Pi-Rogue-owned model-server lifecycle.
• Remote Pi/tool execution.
• Separate releases for orchestration internals; changes ship through the canonical @fiale-plus/pi-rogue artifact.

Related work

• Incident investigation: #371
• Investigation/evidence PR: #373

[bearmug]

Feature-loop implementation started in PR #377: #377. This first MVP slice adds explicit session-scoped model requests and frontier-controller policy under orchestration, with tests and validation. Direct worker executor dispatch and availability preflight remain follow-up slices; no hidden dispatch or fallback is introduced.