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.