How should an orchestrator agent delegate work?

Delegate narrowly. An orchestrator should hand each sub-agent one clear task, with only the data that task needs, through the governing layer rather than directly. It should pick only certified agents, pass on no more authority than it holds, set a deadline and budget, and check each result. Irreversible steps it assembles are held for a person.

What makes delegation by an agent different from delegation by a manager?

A manager delegating to a colleague relies on shared context, judgement and accountability. The colleague knows what "sort this out" means and would query an odd request. An orchestrator agent and its sub-agents share none of that by default. Every assumption has to be made explicit, and every limit has to be enforced by something other than goodwill.

An orchestrator agent also reasons in natural language, so its delegation decisions can be steered by what it reads. That is why delegation must pass through the platform, which applies rules the orchestrator cannot change.

What are the rules for good delegation?

Delegate by role, to certified agents. The orchestrator chooses among agents whose role covers the capability and whose certificate is current. An agent with a lapsed certificate is not eligible, however suitable it looks.

One task, clearly stated. "Check this supplier against the sanctions lists and return the result with sources" is a task. "Handle the supplier" is not.

Pass the minimum data. Give the sub-agent what the task needs. A screening agent needs the supplier's name, country and registration number, not the contract value or internal notes.

Pass no extra authority. The sub-agent acts within the lower of its own authority and the orchestrator's for that task. The reasons are set out in whether an orchestrator agent can give a sub-agent more authority than it has.

Use a queue, not a direct call. Posting the task to a work queue gives it an id, a record and a place to wait if the sub-agent is busy.

Set a deadline and budget. If the sub-agent does not finish in time or within its budget, the task comes back to the orchestrator or a person.

Check results, do not just accept them. A result is a claim from another agent, with its sources attached. The orchestrator verifies what it can before building on it.

What may the orchestrator do, and what stays with a person?

What does this look like in practice?

Take a mid-sized manufacturer's procurement orchestrator. A buyer asks it to onboard a new supplier for a component. The orchestrator breaks this into four tasks: verify the supplier's registration, screen it against sanctions lists, check its bank details, and draft the supplier record.

It posts each to the queue with a task id linked to the parent. The registration and screening agents return results with sources. The bank details came from the supplier's own email, so they arrive marked external; the bank-check agent can confirm the account format but cannot verify ownership, and returns that limit. The orchestrator assembles the supplier record as a draft. Because the bank details are unverified, the platform holds the record for a procurement officer, who calls the supplier on a known number before approving.

Four delegations, one parent task, and the one step that could lead to a misdirected payment waited for a person. Running several agents this way at scale is covered in how to run several AI agents under one orchestrator.

Which protocol details matter?

Whatever format the handoff uses, it should carry the task id, the parent id, the inputs, the deadline and the sender's identity. The general mechanics are described in how agent-to-agent protocols work. The governing layer that checks each delegated action is described in the governed agentic operating system guide.