Skip to main content
Delegation lets one Agent ask another for help. Unlike a sub agent, the target is not created for the occasion: it is a standing peer with its own workspace, memory, skills, sessions and scheduler. It answers from its own environment, and the answer comes back to the Agent that asked, never to the user.
The agent_delegate tool only appears when at least two Agents are enabled. A single-Agent install never sees it.

Sub Agent or Peer

Use a sub agent to parallelise your own work. Delegate when the task belongs to somebody else — the Agent that owns the codebase, the knowledge base or the customer relationship.

A Delegation Is a Run

Every delegation returns a run_id. That id is the handle to a real, recorded run in the target’s workspace, and its parent is the run that asked for it, so a chain of delegations stays walkable from either end. The handle is what makes waiting optional. Work that takes longer than the caller is willing to wait keeps going in the background, and the caller collects it later instead of asking again:
With the default wait_seconds, a task that finishes quickly comes back inline in one call and the handle never has to be used.

Actions

A handle is only readable by the Agent that created it.

Guards

Delegation is between full Agents, so it is fenced in:
  • Allowlist — who may ask whom. Unset means any Agent may delegate to any other
  • Cycles — an Agent already in the chain cannot be delegated to again
  • Depth — how many hops one chain may take
  • Size — the largest task text accepted
  • Time budget — a delegated run that overruns is cancelled
A cancelled target records its own cancellation. If it answers anyway, the answer is still attached to its run rather than thrown away.

Configuration

An Agent listed with an empty array, like "research" above, can be delegated to but cannot delegate onward.