Delegating Work

Activation guard

Use this at the moment you're about to start a multi-step task yourself —
before the first line of code, the first browser action, the first CI poll,
or the first test run. It applies whenever the main thread is about to do
work, not just when the user says "parallelize this."

Skip it for a genuinely single small edit with nothing independent to split
off — spawning overhead would exceed the work itself.

Do NOT do this on the main thread

Each of these is a real temptation, not a hypothetical — they're the
single most-repeated correction the user gives, most recently today
(2026-07-31):

• Writing the implementation yourself because the change "looks quick." Spawn
  a coding subagent even for a small fix; the main thread reviews the diff, it
  doesn't produce it. "Hmm why are you coding on the main thread? You're
  supposed to spawn cheaper models like sonnet to write the code."
• Driving the browser yourself for a UI check or E2E pass. Spawn a subagent
  to run Playwright / Chrome DevTools MCP and report back. "use cheaper sub
  agents for testing ... don't use fable (you) for browser automation bro"
• Babysitting a PR yourself (polling CI, pushing fixups). Spawn a subagent to
  watch and fix. "please use a cheaper model to do the babysitting - like
  sonnet. not you"
• Running the test/fix retry loop yourself. Spawn a subagent to run tests,
  read failures, patch, and re-run until green. "i prefer to use terra sub
  agents for testing/fixing and not use you, the main thread, for these
  things like i see you doing rn"
• Doing a mechanical multi-file sweep yourself (renames, lint fixes, the
  same small edit repeated across files). Split by file set, one subagent per
  slice.
• Skipping delegation "just this once" because the task feels urgent. Cost
  is the reason to delegate, not an excuse to skip it. "this run is getting
  really expensive ... fable model is now per-token pricing so this is
  costing me thousands"

Decision table

Kind of work	Tier
Planning, architecture, ambiguity calls	Main thread
Synthesis / final review of subagent output	Main thread
Talking to the user	Main thread
Writing an implementation slice	Cheap subagent
Browser automation / E2E verification	Cheap subagent
PR babysitting (CI polling + fixups)	Cheap subagent
Test-fix-retry loops	Cheap subagent
Mechanical sweeps (rename, lint, repeated edit)	Cheap subagent(s), one per disjoint file set
Research / repo scans / docs extraction	Cheap subagent

Default to the cheapest tier that can do the work reliably — Haiku for
bulk/mechanical work, Sonnet for anything needing real coding judgment.
Reserve the expensive/frontier model for the main-thread row above. This is a
standing instruction: don't ask the user for permission to parallelize.

What the main thread keeps

Planning, prioritization, ambiguity resolution, integrating what subagents
return, final review before the user sees it, and all direct conversation
with the user. Everything else in this table is a delegation candidate by
default, not an exception.

Parallel edits are the intended pattern, not a risk

Parallel subagents editing disjoint files is normal and expected here. Assign
non-overlapping file sets before you fan out, and have each subagent re-read
existing changes before editing. Use the shared checkout's normal
read-before-edit discipline.

Related skills

This skill is the decision point; it doesn't replace the workflows that
follow it:

• efficient-frontier — the orchestration workflow once you've decided to
  delegate: handoff packets, fan-out limits, the review loop.
• efficient-fable — the same workflow, plus Fable's per-token pricing as a
  reason it matters even more.
• delegate-to-agent — the briefing contract (objective / context / output /
  boundaries) and fan-out discipline (cap ~3, default to one) for spawning a
  sub-agent from the main thread.