feat(goal): Migration runs for coordinated multi-agent work

[Hmbown]

Summary

Replace the School-mode exploration with a whale-accurate, more standard multi-agent orchestration surface: a visible coordinated agent run that can choose bounded parallel workers, assign readable roles, reconcile disagreement, and report through the Work surface.

This remains a v0.8.44 exploration/feature item, but it should not introduce School terminology or a /school command.

Naming decision

• Whales form pods as social units, but the largest meaningful whale movement pattern is migration.
• A multi-pod or many-whale motion is better framed as a migration, aggregation, or fleet-style coordinated run than a school.
• For v0.8.44, avoid making Pod a new product noun. It collides with Kubernetes and is not needed for the current workbench foundation.
• Use plain UI language first: agent team, coordinated run, roles, evidence, synthesis. If whale-themed naming appears, Migration run is the preferred issue shorthand.

Product shape

• Candidate command surface: prefer an existing agent/workbench route such as /agents run <objective> or a Workbench action. Do not add /school.
• The parent agent may choose the run width dynamically instead of using a fixed count. It must stay bounded by config/runtime caps such as [subagents].max_concurrent and any explicit user budget.
• Roles should be visible and purposeful: scout/researcher, builder, verifier, critic, synthesizer, domain specialist, etc.
• The system should encourage productive disagreement and final reconciliation without making the transcript opaque.
• Work/checklist remains the primary progress surface; coordinated-run status is an orchestration layer, not a second conflicting checklist.

Guardrails

• Do not claim massive scale unless the local runtime/config actually permits that scale.
• Approval, sandbox, provider, and cost policies apply to every child.
• The parent remains accountable for final synthesis and evidence.
• Keep child output summary-first, with raw detail behind handles/detail pagers.

Acceptance criteria

• No user-facing School mode or /school command is introduced.
• A user can invoke a coordinated agent run and see chosen width, roles, active/completed children, and final synthesis.
• The agent can choose fewer or more workers based on task shape, within configured caps.
• Parallel children produce bounded summaries with evidence pointers; parent reconciles conflicts before final answer.
• Tests cover dynamic width selection, cap enforcement, visible status rendering, cancellation/cleanup, and no bypass of approval/sandbox policies.
• Docs explain when to use coordinated multi-agent runs: broad discovery, batch processing, adversarial review, and long-form synthesis.

Relationship to v0.8.44

This should come after the storage hygiene, WorkNode model, workbench routing, and parent-owned agent review surfaces. It depends on the workbench being able to represent agents, evidence, blockers, and synthesis as inspectable objects.

[Hmbown]

v0.8.44 implementation note: Goal should become a real Ralph-style autonomous continuation loop before it is exposed as a tabbed/direct mode. Acceptance shape: /goal remains the objective source, entering Goal loop verifies the model understands the goal, then continues after each turn until achieved, blocked, budget/cap exhausted, or user stops it. Permission posture must be explicit and visible: support Agent-like approvals and an opt-in YOLO/auto-approve posture for trusted repos, rather than silently changing execution policy. Work/checklist stays the granular progress ledger; Strategy metadata stays phase-level; receipts/evidence must show why the loop believes progress, completion, or blockage is real. School mode can compose with this later by letting the loop decide when to open a bounded school of sub-agents, with caps and visible synthesis.

[Hmbown]

Detailed v0.8.44 Goal mode spec, phrased for CodeWhale rather than copied from any reference implementation:

Goal Mode

Implement Goal mode as a per-thread persistent objective plus an autonomous continuation scheduler. This should not be just prompt text or a visual label. A goal is durable thread metadata, and each saved thread can have at most one active goal record. Goal operations should apply only to persisted threads; ephemeral sessions should reject goal creation or mutation. Plan mode must not auto-continue goals.

Goal State

Each goal should have a stable internal goal id, a thread id, objective text, status, optional token budget, tokens used, elapsed active seconds, created timestamp, and updated timestamp. Runtime accounting should use the internal goal id to reject stale writes after a goal is replaced.

Supported statuses:

• active
• paused
• blocked
• usageLimited
• budgetLimited
• complete

The host owns paused, usageLimited, and budgetLimited. The model may only mark a goal complete or blocked, and completion for a budgeted goal must report final usage.

User And API Surface

Expose operations to set, get, clear, pause, resume, and edit the thread goal. Setting a new goal over an unfinished one should require confirmation. Clients should receive full goal updates after mutation, cleared events after removal, and a goal snapshot or clear event when resuming a thread so UI state can be restored accurately.

The model-facing tools should be narrow:

• get_goal: read current goal and usage.
• create_goal: create only when explicitly requested by the user or system; reject if one exists.
• update_goal: allow only complete or blocked.

Runtime Behavior

At turn start, attach the current active goal id to turn accounting when the thread has an active or budget-limited goal. Track token deltas as non-cached input tokens plus output tokens; avoid double-counting cached or reasoning tokens. Track wall-clock time only while the goal is active. Account progress after tool calls, turn finish, aborts, usage-limit errors, and before any external goal mutation.

When token usage reaches a token budget, persist budgetLimited, notify clients, and steer the model to wrap up without starting new substantive work. If a hard usage-limit error stops work, persist usageLimited and prevent continuation.

After a completed turn, if the goal is still active and there is no active turn or queued user input, start a hidden continuation turn. Before launching it, re-read the goal and verify that the goal id and status still match. Never auto-continue in Plan mode.

The hidden continuation should restate the objective as untrusted user data, explain that the goal persists across turns, require current-state verification before marking complete, require update_goal({status: "complete"}) only when requirements are proven done, and allow blocked only after the same blocking condition repeats across at least three consecutive goal turns.

UI Requirements

/goal should show a concise summary. /goal <objective> should create a goal. Add /goal edit, /goal pause, /goal resume, and /goal clear. Show footer/status states for pursuing, paused, blocked, usage-limited, budget-limited, and complete. For active goals, update elapsed time live during an active turn. Interrupting an active goal should pause it. Resuming a paused, blocked, or usage-limited goal should ask the user before continuing.

Permission Posture

Goal mode must make permissions explicit. It should support an Agent-like approval posture and an opt-in YOLO/auto-approve posture for trusted repos. It must never silently become YOLO just because a goal exists.

School Mode Composition

School mode should be a later composition point: an active goal may decide to open a bounded school of sub-agents when the task benefits from parallel review, discovery, or verification. The school needs visible caps, visible synthesis, and a final reconciliation step before the parent marks the goal complete.

[Hmbown]

Related concrete slices from the log pass:

• Agent routing: detect when parent work should delegate to scouts or RLM #2024 covers the detection/routing layer for when a coordinated run should be suggested.
• GitHub triage scout: delegate issue, PR, and milestone maintenance passes #2025 covers a GitHub triage scout role, which is a practical early use case for coordinated runs.

These keep #2007 focused on the user-visible coordinated-run surface while the scout heuristics and GitHub-specific role can be developed/tested separately.

[Keesan12]

For coordinated multi-agent runs, I would make the reconciliation report the load-bearing artifact. Parallel workers are useful, but the user needs to know what disagreement was found and how it was resolved.

A compact run receipt could include worker roles, assigned scopes, outputs accepted/rejected, verifier result, unresolved disagreements, and stop reason. That keeps the Work surface from becoming only a progress UI.

The strongest version of this feature would let someone inspect why the orchestrator chose bounded parallelism for this task and why it stopped when it did.

[Keesan12]

The reconciliation report should be the load-bearing artifact. For bounded parallel runs I would want worker roles, assigned scopes, accepted or rejected outputs, unresolved disagreements, verifier result, and stop reason in the receipt. That keeps the Work surface useful without hiding the evidence trail.