[feature] Epic: multi-target scatter-gather orchestration (decompose → fan out → synthesize → return)

[Jason-Vaughan]

Vision

A request goes up to a frontier orchestrator, which breaks it into sub-tasks and dispatches each to the most appropriate backend — cheap grunt to a local model, long-context work to a long-context backend, code to a code backend, hard reasoning kept on the frontier — possibly in parallel, then reorganizes the results and returns one answer. You define the parameters and make up the rules via roster config (which backends exist, what they're good at, their relative cost); the model decides the breakdown within the menu you defined.

What's built today (the spine)

• Frontier-first orchestration — tanglebrain "…" routes the whole task to a can_orchestrate backend; task-fit (good_at) + rotation pick which.
• Emergent decompose → delegate → review — the router injects the delegate_local tool; the orchestrator's own reasoning decides what to offload, then reviews.
• Offload to free local — delegate_local runs sub-tasks on the local model at $0.

Good spine. Missing: the multi-target, parallel, capability-routed-per-sub-task pieces. Today every delegated piece goes to the same place (local), sequentially.

Building blocks (roadmap)

1. Generalized / tiered delegate ([feature] Generalized delegate — route sub-tasks to a configured cheaper backend, not just local #38) — more than one delegate target; the prerequisite.
2. Capability-routed delegation — pick the target per sub-task by good_at / cost (sub-task-level task-fit, mirroring the request-level router). The frontier model decomposes and routes each piece by fit.
3. Parallel fan-out — a delegate_many([...]) tool or a deterministic coordinator that dispatches sub-tasks concurrently and collects results (vs. sequential tool calls).
4. Synthesis / reduce — the explicit "reorganize and return" step (orchestrator synthesizes, or a configured reducer).
5. The "menu" the orchestrator sees — available backends + their fit + relative cost, surfaced so it can "decide based on what's available."
6. Observability of the orchestration tree — extend measurement to the decomposition tree (which sub-task → which backend → tokens/cost); the knob GUI can visualize the fan-out.

Design constraints (keep the product's character)

• Config-driven — the roster is the rules; adding a backend or a delegate target stays a config edit.
• Local-first + neutral — no economic/sub-evasion framing; "cheaper" is a capability/cost hint you configure.
• Opt-in + ToS-disclaimed for non-local tiers (DISCLAIMER.md).
• Plain Python first — the loop can stay emergent; introduce an optional deterministic coordinator only when the control flow (parallel fan-out + reduce) earns its keep (the standing "a graph engine only when justified" stance).

Slices

• [feature] Generalized delegate — route sub-tasks to a configured cheaper backend, not just local #38 — generalized/tiered delegate (first concrete slice)
• capability-routed per-sub-task delegation
• parallel fan-out primitive (+ collect)
• synthesis/reduce step
• orchestrator-visible backend menu (fit + cost)
• orchestration-tree observability (measurement + GUI)

This is the original product vision written down as an executable roadmap; #38 is the first chunk.