lemurOS:dispatching-parallel-agents

lemurOS:dispatching-parallel-agents

Overview

When tasks are truly independent, dispatch them in a single message with multiple Task tool blocks. Parallel dispatch is fast but unsafe when independence isn't real — overlapping writes corrupt state, sequential dependencies produce wrong outputs.

When to use

All four conditions must hold:

• Tasks touch disjoint file sets (no two tasks write the same file).
• No task depends on another's output.
• Tasks are idempotent on retry.
• No shared FS lock contention (different vault slugs OK; same slug → Librarian serialises anyway).

When NOT to use

• Any two tasks write the same file.
• Task B reads what Task A produces.
• Tasks share a Librarian per-slug lock and you want true parallelism (you won't get it — the lock will serialise them; the parallel dispatch just hides the queue).
• Tasks have order-sensitive side effects (DB migrations, env mutations).

Hard gates

Before dispatch, write out the file paths each task will write. If any path appears in two tasks, REJECT parallel dispatch and sequence them instead.

Parallel dispatches go in a single assistant message with multiple Task tool calls. Splitting across messages is sequential, not parallel.

After all subagents return, aggregate verdicts using the table below before emitting your own verdict.

When it's wrong - quick table

Situation	Why wrong	Do this instead
Tasks 2 and 3 both edit theme.ts	Last write wins → silent loss	Sequence
Task B uses Task A's output file	Race: B may read before A writes	Sequence
Both write to vault under same slug	Librarian serialises via per-slug lock	Either sequence, or accept hidden queueing
One task is a migration / env mutation	Side effects sequence-sensitive	Sequence

The pre-dispatch check

For each task, list:
  - Files written
  - Files read (only)
  - Vault slug touched (if any)

If any "Files written" overlaps across tasks → SEQUENTIAL
If any task's "Files read" appears in another's "Files written" → SEQUENTIAL
If 2+ tasks touch the same vault slug → ACCEPT serialisation or sequence
Else → PARALLEL OK

Aggregation

Any subagent returned	Parent emits
BLOCKED	BLOCKED
REQUEST_CHANGES	REQUEST_CHANGES
DONE_WITH_CONCERNS	DONE_WITH_CONCERNS
All DONE	DONE

Red flags - STOP and reconsider

Thought	Reality
"Last write wins, it's fine"	Last write wins is the bug, not the design.
"They probably won't collide"	Probably ≠ provably. List the write sets.
"Parallel is always faster"	Parallel-to-a-locked-resource is sequential with extra overhead.
"Splitting across messages is still parallel"	No — a new assistant turn means the prior batch already completed.

Verdict

Emit the aggregated keyword from the table above.