Subagents & delegation
A capable agent sometimes needs help — a reviewer, a linter, a specialist. OAP lets an agent delegate to other agents, but delegation is a governed edge, not an open door: it can only reach a closed roster you reviewed, the tree is bounded, and it can't quietly disclose data past the people who own it.
A closed roster, not "any agent"
An AgentClass declares the exact agents it may delegate to — a subagent roster. It can't summon an
arbitrary agent by name; it can hand work only to a member of that reviewed list. The roster is validated as a
DAG (no delegation cycles), and each entry can be pinned to an exact bundle digest (name@sha256:…) so the
subagent you approved is the subagent that runs — see supply-chain pinning. A cluster
can require those digest pins as a ratchet, so no one loosens it below.
Bounded by construction
Each roster member has a mode ceiling — single_turn, task, or chat — capping how much autonomy a
delegated agent gets, and the whole delegation tree is bounded by a budget (maxDelegatedAgents), so a chain
of agents can't fan out without limit. A subagent is still just an AgentSession: scoped,
budgeted, audited, and torn down when done — the parent doesn't get to escape those rules by going through a
child.
Delegation can't launder a data boundary
The subtle risk in delegation is disclosure: handing a child a piece of data the requester was allowed to see but the child's audience is not. OAP treats that as an authorization question. When a delegated call would pass data past the set of people who can see it, the parent parks and asks the data's owner — the same owner-gated check as a direct share — rather than letting the boundary dissolve one hop away.