How it works
Naming delegation targets injects a syntheticdelegate_agent tool into the
parent’s tool list. The parent calls it with a task; the child runs with its own
instructions, model, and capabilities; the result flows back to the parent as a
tool result.
There is no connector to install and nothing to attach beyond picking the target
agents.
What a child inherits
The child gets a fresh thread. Anything it needs to know about the situation has
to be in the task the parent sends it.
Depth
Delegation chains are capped at 3 levels by default (parent is 0, its child is 1). A run at the cap cannot delegate further, and the tool is not offered to it.Budget
Parent and child share one work budget. A child’s model calls and tool calls count against the same allocation, so a deep chain cannot outspend a shallow one by recursing.Autonomy in a chain
A sub-agent’s calls go through the same admission door. The child’s run carries the human from the parent’s session on its user identity while its invoking principal is the parent agent — so an account-level deny that names either the human or the parent applies to the child’s calls too.Designing a chain
- Give each child one job. A specialist with five tools beats a generalist with thirty.
- Send the smallest task that is sufficient. The child sees nothing but what you send, and everything you send costs tokens on both sides.
- You cannot point a child back at its parent. Self-references and cycles are rejected when you save the configuration, so a delegation loop never gets as far as the depth cap.
- Decide what a failure means. A child that cannot complete returns a tool result the parent has to handle — say in the parent’s instructions what it should do then.
Observing it
Delegation shows in the Activity timeline; the kind filter has a “Delegation” option. Each handoff records which agent called which.Next
- Creating an agent
- Workflows — when the plan is fixed, not reasoned