The easy mistake with multi-agent work is to start with the number of agents.
How many workers can we run at once?
How much faster can the plan move?
Where can the work be split?
Those are useful questions, but they are not the first questions.
The first question is simpler and more important:
Who is allowed to do what?
That became clear in today’s session while turning a `.plan.md` file into a reusable multi-agent orchestration skill.
At first glance, the work looked like a planning problem. Take a phased checklist, assign workers, run them in parallel, review the results, and integrate the changes.
But the deeper issue was authority.
The skill needed to separate two things that are easy to blur. First, create and stabilize the orchestration procedure itself. Second, apply that procedure to a real implementation plan only when the user explicitly asks for that execution.
That separation matters.
If the same process both defines the operating model and starts doing the implementation work, the orchestrator can quietly become the worker. Once that happens, the whole system loses its shape. The master agent stops preserving the plan and starts absorbing it.
In a useful orchestration model, the Master Agent has a specific job.
It analyzes the plan. It maps dependencies. It assigns file ownership. It chooses worker boundaries. It routes work through review. It handles cleanup and integration decisions.
But it does not default to doing the implementation itself.
That constraint is not bureaucracy. It is what keeps the system understandable.
Workers need constraints too. Each worker needs an explicit, non-overlapping scope. That sounds obvious until the work touches shared contracts, migrations, configuration, or common helpers. Those areas can turn parallel implementation into collision if they are treated like ordinary independent tasks.
The plan has to identify those pressure points before the workers begin. Otherwise, speed just creates more coordination debt.
The reviewer gate is the other important piece.
Every worker result should pass through a senior review or tester step before it is integrated. Not because review is ceremonial, but because it protects the whole system from fast inconsistency.
A worker can finish its assigned scope and still introduce a contract mismatch, a missing test, or a behavioral edge case. The reviewer step gives the Master Agent a clear signal: this is ready, this needs repair, or this should not be integrated yet.
That is the practical lesson.
Multi-agent automation does not fail because there are too few agents. It fails when the boundaries are vague.
You need a master who preserves the structure of the work.
You need workers who stay inside their scopes.
You need a reviewer who decides whether the result is ready.
Only then does parallelism become useful.
Without that structure, a multi-agent system is just a faster way to create the same confusion in more places at once.
The real design problem is not adding more agents.
It is keeping the orchestration layer clean enough that the agents can cooperate without stepping on each other.
-----------
If you find this content useful, please share it with this link: [https://patrickmichael.co.za/subscribe](https://patrickmichael.co.za/subscribe)