6. Multi-agent delegation — what to share around and what to keep yourself

This is part 6 of the Alice Way series. Through part 5 Hooks and automation, the series covered how to design the mind of one collaborator. This post is about a structure where that one collaborator does not do everything — about distributing the mind sideways.

0. Delegation is splitting mind so one context does not carry it all

Hand every task to one collaborator and their context window fills fast. Once it fills, decision quality drops. Drop in quality forces the operator to double-check every time. Then the operator's mind load goes back up.

Delegation breaks this loop. Large tasks get split and handed off to sub-collaborators; the main only receives a summary of each result. Each sub focuses on one thing with its own context. The main's context stays only filled with what the decision needs.

Delegation has costs, though — a brief has to be written, the result has to be verified, and the integration has to happen. If the gains of distribution do not exceed those costs, delegation is a loss.

This post is a record of which work is worth delegating, how to build gates that hold the delegation accountable, and the traps to avoid.

The subagent mechanism itself is borrowed from Anthropic Claude Code's subagents system. This post is a record of how that mechanism is used, not an invention of it.

1. The main–sub split — who carries what

The split I converged on.

The core is — main carries decision authority and memory; sub carries the work and deep context. They never carry the same thing. Overlap is wasted context.

The most common way this split breaks — the main tries to know every detail of the sub's work. Then the main's context fills, and the reason to have a sub disappears.

The main has to know what it does not know. The unknown part is held by the sub.

2. What is delegable — five conditions

Not all work is delegable. Only the work that passes all five of these goes down to a sub.

2.1 Is the input closed?

A sub receives a one-shot slice of the main's context. Two-way mid-task conversations like "tell me more about X" are hard. So everything needed at the start has to be closed inside the brief.

If the input is not closed, the sub fills it with guesses. Guesses often miss.

2.2 Can the output be summarized?

When the sub's result returns to the main context, only the summary should come in. If the result is intrinsically long and not summarizable — for example "review all 100 files" — the value of delegating shrinks. The main ends up absorbing a 100-file summary anyway.

2.3 Does decision authority stay with the main?

The sub must not step into the operator's decision territory mid-task. "Can I change the DB schema?" is not something the sub decides. If such decisions might appear mid-task — either pre-declare the authority table in the brief, or design the sub to stop and report at decision points.

2.4 Is verification automatable?

If the operator has to manually verify the sub's result every time, the delegation gain disappears. Only work that comes with an automated verification script is delegable. (See §4 on gates.)

2.5 Is it focused on one thing?

A sub does one thing. Compound work like "refactor this component + add tests + update docs" does not get delegated as one. Split into three, send to three different subs. A single sub carrying multiple things produces tangled context and vague output.

3. The cost of delegation — when direct is better

Delegation is not always net positive. The cost in summary.

• Brief-writing cost — putting what / why / how / where-to-stop into writing
• Context-prep cost — extracting only what the sub needs and handing it over
• Verification cost — automated checks + main's re-confirmation to trust the result
• Integration cost — absorbing the result back into main context

The sum of these four has to be less than the cost of doing it directly for delegation to pay. In my experience — work that finishes under 30 minutes loses money to delegate; work that takes 2+ hours or touches 5+ files gains from delegation.

Delegation that ignores task size is not delegation — it is just shifting blame.

4. The delegation gate — enforcing the promise in code

The most common way delegation fails — the brief gets written but the verification and merge gate get skipped. Then drift between the promise and the result piles up and only surfaces much later.

After getting burned by this pattern once, I now always bundle three pieces into the same PR for any delegation.

4.1 The brief

A document spelling out what / why / how / where-to-stop. The sub reads it once before starting. The brief carries:

• Goal and Definition of Done
• Inputs (extracted from main context)
• Output format (which files, what structure)
• Decision-authority table (autonomous / report to main / forbidden)
• Verification method (named automated script)
• Merge gate (what must pass in CI before merge)

4.2 The automated verification script

So humans do not have to check every result manually — an operable script. For "refactor component X" delegation, something like npm run verify:component-x ships in the same PR as the brief.

A brief without a verification script is not a brief. It is just an expression of intent.

4.3 The merge gate

The verification script runs in CI, and the merge is blocked if it does not pass. Promise verification without setting up a gate — eventually something gets merged without the verification ever running.

The three pieces (brief + verification + gate) move together. Drop any one and the promise stops being enforced in code, and the promise breaks.

If a promise is not enforced in code, drift accumulates.

5. Delegations in actual rotation

A subset of what I delegate weekly.

5.1 Broad codebase exploration

"Find every place X keyword is used and how" — to a sub. The sub combs the whole repo with grep/glob/find and writes up the result. The main only receives the writeup.

If the main does this directly — hundreds of match results crowd the main context. No room left for decisions.

5.2 Build · test runs

"Run lint + build + test on this change and summarize" — also to a sub. The sub takes the full output; the main only gets "passed" / "failed (3, first two lines: ...)" style summary.

5.3 Reviews

"Review this PR from a security angle" — sub reads the whole thing and writes up an issue list. The main only gets the count and the most important three.

5.4 Broad external research

"Known security issues with this library and alternatives" — external research. Sub gathers from multiple sources and writes up. Main absorbs only the short summary needed for the decision.

5.5 The accumulated effect

Context savings per task are small. But when 5–6 delegations happen daily — the main context stays in decision-only mode all day long. The reporting format the operator sees becomes consistent, and patterns like "the main is now confused because it holds everything" disappear.

6. Traps — patterns where delegation fails

Failure patterns I have hit at least once.

6.1 Unverified delegation

The most common trap. Brief written, delegated. Result comes back, no way to verify, so manual check every time. All gain gone. → §4's three-piece gate is the answer.

6.2 Open-input delegation

"Just handle this however" — the sub fills with guesses, and guesses miss. → Keep the brief closed even if short.

6.3 Blurry authority

The sub hits "should I change this?" mid-work and proceeds on its own judgment. The operator sees results that diverge from intent. → Authority table in the brief + stop-and-report pattern at decision points.

6.4 Over-fragmented delegation

Delegating five-minute tasks. The brief-writing cost exceeds the task itself. Faster to do directly. → No delegation under 30 minutes.

6.5 Ignoring integration cost

Sub results that are hard to integrate at once. Five subs touching different files simultaneously and colliding. → Pre-partition sub work areas in the brief so they do not overlap.

7. The delegate-vs-direct decision flow

The decision flow I run mentally when new work comes in.

new work
  ↓
under 30 min? → yes → direct
  ↓ no
input closed? → no → direct (or prep input first)
  ↓ yes
verification automatable? → no → direct (too risky)
  ↓ yes
single thing? → no → split, delegate each
  ↓ yes
→ delegate (brief + verification script + merge gate bundle)

When this flow is internalized, the delegate-vs-direct call is fast. No fresh deliberation each time.

8. Compressed into one principle

The core of delegation design collapses into one sentence.

"The main holds decisions and memory; the sub holds work and deep context. Delegation always ships brief + verification + gate as one bundle."

When this holds, delegation becomes an accelerator that keeps the main context in decision mode. When it breaks, delegation becomes blame-shifting and result integration becomes the operator's recurring burden.

The next post covers the device that enforces whether delegated (and direct) work is actually "done" when it says it is — verification loops, i.e. how to lock down the definition of "done" for code work.