Coordinating many agents must never create authority that none of them holds alone. That is the whole of the problem. An orchestrator that can split a task, hand pieces to sub-agents and combine the results can also, without care, assemble an outcome nobody was permitted to produce. Authority has to be checked at each hand-off and at each action, not assumed from the arrangement.
What is authority sprawl?
Authority sprawl is what happens when the combined effect of several agents exceeds the bounds any single one of them was given. No agent breaks its own rules. The system as a whole still does something nobody authorised.
A plain example. One agent may draft payments up to the customer's limit. Another may update payee details from verified sources. A third may approve low-value payments that have already been drafted. Each bound is sensible. Now add an orchestrator that, asked to "settle outstanding supplier invoices", splits a large invoice into several payments under the limit, has the second agent update the payee, and routes each piece to the third for approval. The large payment went out in pieces, to a changed payee, with no person involved.
Agent orchestration is useful precisely because it lets an orchestrator compose work in ways the designer did not spell out. That same freedom is what produces sprawl.
Why can't the orchestrator just be trusted with more?
The tempting answer is to give the orchestrator broad authority and trust it to stay sensible. That reverses the logic of delegation. In any organisation, delegated authority flows downward and shrinks: a manager cannot delegate more than they hold, and each delegation is narrower than the one above it.
An orchestrator with broad authority becomes the most powerful and least tested agent in the estate. It is also the hardest to certify, because the space of things it might compose is vast. The question of whether an orchestrator can give a sub-agent more authority than it has has a clear answer, no, but enforcing that answer needs more than a rule in the orchestrator's prompt.
What rules prevent sprawl?
Four rules, enforced by the platform rather than by the orchestrator's own judgement, cover most of the risk.
- Authority only narrows on hand-off. A sub-agent acting on an orchestrator's behalf holds the lower of its own bounds and the orchestrator's. It never inherits more.
- Every action is checked on its own. The sub-agent's tool calls meet the full set of bounds at the moment of action, exactly as if no orchestrator were involved. Being called by an orchestrator is not a credential.
- Limits apply to the task, not just the step. Where a limit exists to cap total exposure, such as a payment ceiling, it is measured across all actions in the same task, so splitting does not get round it.
- Separation survives orchestration. If one agent drafted an action, a second agent in the same task cannot be its approver. Separation of duties is checked across the whole chain.
The third rule is the one most often missed, and it is the one that stops the splitting example above.
How does this differ from what an orchestration layer does?
Many products offer an orchestration layer: a way to define agents, route tasks between them, manage state and retry failures. That is plumbing, and it is valuable. It is not the same as deciding whether each routed action is allowed.
The difference is the subject of how an agentic operating system differs from an orchestration layer. An orchestration layer answers "which agent does this next?". A governed operating system also answers "may that agent do it, given who asked and what has already happened in this task?". Without the second question, coordination and authority are the same thing, and sprawl follows.
What does a well-bounded orchestration look like?
| Element | Bounded orchestration | Sprawling orchestration |
|---|---|---|
| Orchestrator's own depth | Depth 5 to coordinate, with no direct access to money or records | Broad tool access "in case it needs it" |
| Sub-agent authority | Lower of its own bounds and the orchestrator's | Whatever the sub-agent was configured with |
| Task-level limits | Measured across every action in the task | Measured per step only |
| Approval | A named person for anything held | Another agent in the chain |
| Record | Every hand-off and action filed with the task it belongs to | Separate logs per agent, joined by hand if at all |
The orchestrator in the left column coordinates work but cannot itself move money or change records. Its value is in planning and routing. Every consequential action still happens in a sub-agent that holds the relevant certificate and meets the relevant bounds.
How do you write this down?
A delegation of authority matrix for AI agents is the practical artefact. It lists each agent, the capabilities it holds and at what depth, which agents may call it, and which task-level limits apply. Reviewing it is how you spot combinations that would add up to something nobody intended.
The matrix should be read alongside the record. If the record shows a task where several sub-agents together moved more than any single bound would allow, the matrix has a gap, even if each individual action was allowed.
Where Pryme fits
In Pryme, depth 5 is reserved for orchestrators, and coordinating other agents does not grant any other depth. Every sub-agent action meets the minimum chain at the moment of action, and the lowest bound wins. Each hand-off and verdict is filed in the append-only record against its task. See the governed agentic operating system, explained.
What should you do differently?
For every orchestrator you run, list what it can reach directly and remove anything it does not need to plan and route. Make sure sub-agents cannot inherit authority from the caller, make task-level limits span the whole task, and check that no agent in a chain can approve another's draft. Then look for a past task in the record where the sum exceeded any single bound.
Questions people ask
Can an orchestrator ever move money itself?
It should not. Keep orchestrators at coordination and give money movement to a dedicated agent with its own certificate, so the capability is tested and bounded on its own.
How do task-level limits work across days?
Define the task boundary clearly, such as a single invoice or a single customer request, and measure limits across it however long it runs. A task that stays open for weeks should still carry one total.
Does this apply to agents from different vendors?
Yes. Authority narrowing and per-action checks must apply to every agent acting through your platform. A hand-off between vendors' agents is still a hand-off, and still needs to be bounded and recorded.