Delegation & review
How the lead fans work out safely — frozen interfaces, ownership boundaries, and review of every returned diff.
Parallel writers on one working tree is how delegation usually goes wrong. darting.dev handles it with two habits before the fan-out and one hard rule after it: freeze the seams, name the boundaries, and review every diff that comes back.
The division of labor in one line: the context-rich agent plans and reviews, the context-poor agent types.
Interface first
Before spawning anyone, the lead agent freezes the seams in the tree itself — not in prose:
- Shared types land first.
- Real signatures land with not-implemented bodies. The stub is the contract.
- Every shared registry, barrel, and route entry is pre-wired.
So the tree compiles hollow before anyone types a line of behavior. Two agents writing against a signature that already exists can't disagree about it.
lead: freeze types + stubs + wiring → tree compiles hollow
├─ worker A · owns files A… (consumes contracts read-only)
└─ worker B · owns files B…
lead: review both diffs against the plan
Ownership boundaries
Each assignment names three things: the files this agent owns and may edit, the contracts it consumes read-only, and touch nothing else. Disjoint file sets behind frozen seams are the whole reason parallel writers are safe — remove either half and you're back to conflicts.
What parallelizes, and what doesn't
- Read-only roles — explorers, code and security reviewers — always parallelize safely.
- One UI driver at a time. There's one desktop per sandbox.
- Entangled work builds serially. Decomposition is used when the work genuinely cuts, not as a default. A plan that doesn't split cleanly is built in sequence.
The roles reference covers what each of those agents can and can't do.
Every returned diff gets reviewed
A sub-agent finishes and reports. That report is not the acceptance test — the lead is. It holds the plan and the conversation the sub-agent never had, so it reads the whole diff and judges it against intent: no quiet scope-shrink, no drive-by refactors of code that wasn't in the assignment.
It also checks the classic failure modes of delegated work:
| Check | What it catches |
|---|---|
| Files outside the boundary | An agent that wandered into code it didn't own. |
| Leftovers of removed code | Dead imports, orphaned types, stale string literals. |
| Weakened or deleted tests | A suite that passes because it stopped asserting. |
| Suppressions added to get green | Ignore comments and silenced errors standing in for a fix. |
A dedicated reviewer sub-agent can run the same pass with fresh eyes; the lead's version is the one that knows what the change was for.
Fixes go back to the same agent
Triage has three outcomes:
- Trivial — the lead just fixes it.
- Substantive — it goes back to the same sub-agent, which resumes with its full prior context. That's far cheaper and more reliable than a fresh agent rediscovering code someone else wrote minutes ago.
- Wrong approach — only then is a fresh agent the right call, because the thing being replaced is the plan, not the typing.
Where this shows up
You see the shape of it in the thread: the lead's plan, the sub-agents it spawned, each one's report, and the diff they collectively produced. For complex work that plan is a document you approved first — see plans & the Build button — and what lands is a single reviewable branch, as described in git, diffs & Commit Thread.