Parallel agents without chaos

“Run five agents” sounds like progress because five is larger than one. In practice it can mean five copies of the same context, five model bills and five plausible edits aimed at the same file.

Parallelism needs structure before it needs scale.

Each agent should have a bounded job, a tool policy and an isolated place to work. For code, a git worktree gives the change a real branch boundary. A verifier can run tests without competing with an implementer. An explorer can remain read-only. Results return as evidence the parent task can accept, reject or reconcile.

The project must remain the centre. If sub-agent output becomes a pile of detached chats, the user is now the orchestrator and the feature has exported its hardest problem. Goals, activity, cost and results need a shared identity so the work can merge back into one understandable state.

Cost is part of orchestration too. Parallel calls multiply spend and can destroy cache reuse. The system should reserve parallelism for genuinely independent work, constrain the candidate models and make the ceiling visible before dispatch.

The aim is not maximum simultaneous generation. It is reduced elapsed time without sacrificing ownership. Two isolated, well-scoped agents that produce reviewable evidence beat ten agents writing over one another.

Concurrency is an implementation detail. Coordination is the product.