The most useful lesson from this session had very little to do with parallelism.
It had to do with restraint.
I was turning a `.plan.md` file into a reusable multi-agent orchestration skill. At first glance, that kind of work invites the wrong question. You start thinking about how many workers you can run at once. But that is usually not the real constraint.
The real constraint is authority.
Who decides?
Who edits?
Who checks the result before it gets integrated?
That became clearer as the skill took shape. It needed two distinct phases. First, define and stabilize the orchestration method itself. Then, only with explicit user intent, apply that method to a real implementation plan.
That separation matters more than it sounds.
If the same process both writes the operating model and quietly starts doing the work, the orchestrator stops being an orchestrator. It becomes an unbounded worker with extra authority. And once that line blurs, the whole system starts to lose shape.
So the Master Agent in this model has to stay narrow by design. It owns analysis, dependency mapping, file ownership, worker assignment, review routing, and cleanup. What it should not do by default is implementation. Its job is to preserve coordination quality, not absorb execution.
The same discipline applies to workers. Each worker needs a clear, non-overlapping scope. That sounds obvious until real code is involved. Shared contracts, migrations, and config files turn supposed parallelism into collision very quickly. If those boundaries are vague, you do not get speed. You get interference.
The other piece that matters is review.
Every worker result should pass through a senior reviewer or tester before integration. That gate is not bureaucracy. It is what prevents a multi-agent system from becoming a fast way to produce inconsistent work. It catches regressions earlier, and it forces an explicit decision about whether a result is actually ready.
The practical lesson is simple.
Multi-agent systems work better when authority is explicit. You need one agent to hold the shape of the work, workers who stay inside their assigned edges, and a reviewer who decides what earns integration. Without that structure, adding agents just gives you more ways to make the same mistakes faster.
So the design question is not how to add more workers.
It is how to keep the orchestration layer clean enough that parallel work stays coherent.
That is the difference between a plan that can be executed and a plan that only looks executable.
-----------
If you find this content useful, please share it with this link: [https://patrickmichael.co.za/subscribe](https://patrickmichael.co.za/subscribe)