How to run several AI agents under one orchestrator

Give the orchestrator one job: split a case into tasks, send each to the worker certified for it, and assemble the results. It takes no worker's actions itself. Every delegated task carries the lower of the orchestrator's and the worker's bounds, a named person resolves conflicts and held items, and every step files into one case record.

What is an orchestrated process, and who owns it?

An orchestrator agent coordinates other agents. Take a business account opening: one agent checks documents, another screens directors, another sets up the account, another writes to the customer. The orchestrator decides the order, passes each task with the facts it needs, and notices when one result contradicts another.

Coordinating others is the fifth depth, and only orchestrators hold it. It is a separate authority from anything the workers do. An orchestrator that may coordinate account opening may not, by that fact, open an account.

One named person owns the end-to-end process. Each worker keeps its own owner for its own capability. Without a single end-to-end owner, each team defends its own agent and nobody answers for the customer's outcome.

How do you set it up, step by step?

1. Person, process owner: map the case into tasks. Write which worker does each task, in what order, and which tasks depend on others. Evidence: a versioned process map.
2. Person, process owner: decide what the orchestrator may decide alone. Routing a task to a certified worker, retrying a failed read, assembling a summary. Everything else goes to a person.
3. Platform: certify each worker on its own capability. The orchestrator's certificate covers coordination, not the workers' actions.
4. Orchestrator, depth 5: delegates a task. The task carries the case reference, the facts with their sources, and the bounds that apply. Evidence: a delegation entry linked to the case.
5. Platform, at each worker action: applies the lower of two sets of bounds. A worker cannot do more for the orchestrator than it could do alone, and the orchestrator cannot lend authority it does not hold. Evidence: the verdict names which agent's bound decided.
6. Workers, at their certified depth: do the task and report. Results return with sources attached.
7. Orchestrator, depth 5: checks results against each other. If the document check and the screening disagree on a director's date of birth, it stops and raises the conflict.
8. Person, process owner or delegate: resolves conflicts and held items. The orchestrator may propose a resolution; a person chooses it.
9. Platform: closes the case record. One tree of delegations, verdicts and decisions.

Which decisions does the named person keep?

• Adding or removing a worker. A new worker changes what the process can do. The owner approves it, and the worker is certified on its own capability before it receives a single task.
• Changing routing rules. Which worker gets which task is a design decision, not a runtime one.
• Resolving conflicts between workers. The orchestrator should surface them, not average them.
• Anything held by any worker in the case.
• Exceptions to the process map. If a case does not fit, a person decides how to handle it.

How the orchestrator should break work up and hand it out is covered in more depth in how an orchestrator agent should delegate work.

Which controls matter, and what record do they leave?

One source of authority. Every agent's bounds come from the same place, so an orchestrator cannot hand a worker rights from a local config file. The argument is made in one source of truth for what agents may do. Evidence: each verdict cites the bound version.

Lower bound wins across the chain. Evidence: verdicts naming the deciding agent and bound.

No self-delegation. The orchestrator cannot assign a task to itself, and a worker cannot call the orchestrator to start a new case. Evidence: refused verdicts on attempts.

Loop limits. A cap on delegations per case and on repeated tasks. Evidence: stopped cases with the cap reached.

Case tree. Every delegation, verdict and human decision hangs off the case reference. Evidence: the tree, reconstructable from the append-only record.

What should you measure, and where does it go wrong?

Measure end-to-end time per case, conflicts raised per hundred cases, held items per worker, delegations per case, and cases a person had to restart.

The common failures follow a pattern. Authority laundering: a worker without payment rights asks another agent to pay, and nothing checks the chain. Loops: two agents hand the same task back and forth. Silent averaging: the orchestrator picks one of two conflicting results without saying so. A single point of failure: when the orchestrator fails, no worker knows the case exists. And local rules: an orchestrator built for one country quietly applies its routing elsewhere, which matters when you run AI agents across several countries.

Where Pryme fits

In Pryme, depth 5 is reserved for orchestrators, and every worker action is checked against the minimum chain of bounds, including the orchestrator's own, at the moment it is attempted. Every delegation and verdict files into the same append-only record. The governed agentic operating system guide covers the model, and the seven jobs of an agentic OS shows where coordination sits among them.