cc-os/plugins/os-orchestration/ORCHESTRATION.md

51 lines
3.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## Session orchestration
- Main-loop tokens are the most expensive tokens in the session: every direct tool
call and every byte read into this context bills at the main-loop model's rate,
while a haiku/sonnet subagent does the same mechanical work for a fraction of it.
The more capable the main-loop model (opus- or fable-tier), the lower the
delegation threshold. The question is not "is this task big enough to delegate?"
but "does this step need main-loop judgment?" — when a sequence beyond ~3 tool
calls needs no main-loop judgment between steps, delegate it down-tier, even if
the steps are strictly sequential.
- Delegate when: work is parallelizable across independent files/subtasks; an
implementation task produces N independent files from an already-settled design,
spec, or plan (write-N-files fan-out is delegated work — the design decisions are
already made); an investigation spans many files or needs a large/isolated
context (long log review, wide grep-and-synthesize); or a mechanical multi-call
sequence (edits, lookups, conversions) needs no judgment between steps. This
holds for the whole session: after one round of spawns completes, the next
eligible chunk of work is delegated too — don't drift back into long direct runs
mid-session.
- Work directly when: the op is single-file or ≤2 tool calls; steps are genuinely
judgment-dependent (each result changes what you do next); the user is in the
loop every few turns (interactive troubleshooting — delegation overhead exceeds
savings); a uniform multi-file change is covered by one scripted command (a
loop/script in a few Bash calls is direct work, cheaper than a per-file grind or
a spawn); or you are driving/polling a script's own output.
- Batch before spawning: plan the full fan-out before the first spawn, then group
related subtasks (~58 similar items) into one agent prompt with an explicit
return format, so each agent completes in one round. A follow-up on an agent's
result goes to that same live agent via SendMessage, not a fresh spawn — every
new spawn re-pays the per-agent system-prompt tax.
- Delegate async and keep working: launch independent subagents in the background
and continue your own thread while they run; intervene only when a result shows
an agent off track.
- Before every `Agent` call → set `model:` explicitly in that call. An omitted
`model` silently bills the subagent at the main-loop model. Mechanical
file-edit/shell work → `haiku`; anything requiring judgment → `sonnet`; genuinely
hard reasoning → `opus`.
- When a spawn requests `sonnet` or `opus` → append to its prompt: "State the exact
model ID you are running as in the first line of your report." (The launch result
does not show the resolved model; the subagent's self-report is the only visible
signal.) When a report comes back showing a lower tier than you requested → say so
and adapt (re-spawn or flag the downgrade) — never treat downgraded output as
judgment-tier work silently.
- Before delegating investigation → don't re-cover your own ground: a file you
already read goes into the subagent prompt as a stated fact or summary, not as an
instruction to read it again. If an investigation will span many files, delegate
it before reading them yourself — a short orienting Read is fine only when the
target file/path is uncertain.
- Where a call exposes an effort dial (Workflow `agent()` opts), set it per stage:
mechanical stages `effort: low`; hard verify/judge stages `high`/`xhigh`.