Choosing an Orchestration Primitive for Four Scenarios
For each scenario below, name the orchestration primitive you'd reach for — a plain subagent, a dynamic workflow, an agent team, or "none of these, just work in the conversation directly" — and justify the choice in terms of who needs to hold the plan, whether workers need to talk to each other, and how large the task is.
- "Read through this 4,000-line log file and tell me which requests returned a 500."
- "Every one of our ~300 React components under
src/components/still imports from the oldlegacy-uipackage. Migrate each one to the newui-kitpackage, working file by file, and verify each migration compiles." - "We keep getting intermittent test failures in CI and nobody can reproduce them locally. I want several different theories chased down at once — flaky timing, shared test state, a real race condition in the code — with whoever's investigating actively trying to shoot down the others' theories."
- "Rename the
fetchUserfunction togetUserByIdand update its one call site insrc/api/users.ts."
1. Log file — a plain subagent. This is a single, self-contained side task whose result (the list of 500s) is all that matters; the thousands of lines of log content you don't want cluttering your main context are exactly what a subagent's own context window is for. It doesn't need a script (there's no repeatable orchestration shape worth codifying), and it doesn't need to talk to anything else — a subagent reads, filters, and reports back a summary. Reaching for a workflow or a team here would add overhead — background-run bookkeeping, or a separate context window per teammate — with nothing to parallelize against.
2. 300-component migration — a dynamic workflow. This is the
textbook workflow shape: a task that decomposes into ~300 similar,
largely independent units of work (one component, one migration, one
compile check), far more than a conversation delegating subagents
turn by turn could coordinate without flooding its own context with
300 rounds of "delegate, wait, read result." The orchestration logic —
discover the files, fan out one agent per file with pipeline(),
verify each one compiles — is exactly the kind of plan worth encoding
in a script you can rerun (e.g. after fixing a systematic issue the
first run's verification step surfaced) rather than re-deciding by
hand every time.
3. Flaky CI investigation — an agent team. This is precisely the case a team is built for: the plan can't be written as a script because you don't know the answer well enough yet to encode a fixed orchestration shape, and the value specifically comes from several investigators actively challenging each other's competing hypotheses in real time — something a subagent literally cannot do, since a subagent only ever reports back to whoever spawned it and can't talk to a sibling subagent. A single investigator (or even sequential subagents) would suffer from anchoring: once one theory looks plausible, subsequent investigation gets biased toward confirming it rather than genuinely testing the others. Independent teammates, explicitly told to try to disprove each other, don't share that anchor.
4. One-line rename, one call site — none of these. There's nothing here to decompose, nothing to parallelize, and no ambiguity about scope or approach. Working through it directly in conversation (grep the call site, Edit both, verify) is faster and cheaper than any of the three heavier mechanisms — reaching for a workflow or a team on a task this small adds pure orchestration overhead with no benefit, the same mistake as writing a for-loop to execute one line of code exactly once.
Share this question