Delegation depth

A task token carries the agent that presented it in act. RFC 8693 §4.1 allows that claim to nest, so a chain of agents is expressible in one claim with the human still at sub:

{
  "sub": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "act": {
    "sub": "agent:db-reader",
    "depth": 2,
    "act": { "sub": "agent:jira-triage", "depth": 1 }
  }
}

v0.1 issues depth 1

The control plane in v0.1 exchanges a user’s token for a task token, and every token it issues carries depth: 1. Handing it a task token as subject_token is invalid_grant, because the subject is validated against the upstream identity provider and a task token did not come from there.

The specification marks sub-agent delegation as not in v0.1 and keeps the claim shape, because a chain can reach a tool server from anywhere. Nothing on this page asks you to build against the control plane producing one.

Why the limits exist anyway

Depth is a number a tool server can act on, and it is checked at both ends.

The control plane’s limit is max_delegation_depth in the agent’s registration. It is required, it is checked on every exchange, and it is server-enforced rather than client-asserted: an agent cannot claim a depth it was not given. Any value from 1 to 5 is accepted; with v0.1 issuing depth 1 only, none of them changes what is issued yet, and 1 is the honest value.

The tool server’s limit is its own, and this one is doing real work today, because a tool server accepts tokens from wherever they came. @onbe/server and @onbe/mcp both default maxDelegationDepth to 1 — direct agents only:

const onbe = new OnbeToolServer({
  issuer: 'https://onbe.internal.example.com',
  audience: 'https://db.internal',
  maxDelegationDepth: 2,
});

The default is restrictive because depth is trust you did not personally grant. Raising it says that any agent your agents may call can reach this server. You may well want that; you should want it on purpose.

Reading a chain

Read act outwards. The outermost actor made this call; each nested actor asked the one above it. A tool server can refuse on any of them — the direct caller not being on a list, the chain being longer than expected — or simply record the whole thing, which is the minimum.

What a chain does not mean is accumulated authority. Scope narrows at every hop, so a longer chain has at most the authority of the human at the start of it and usually less. The risk a chain carries is distance, not privilege: the further the caller is from the person, the harder it is for anyone to say why the call happened.

Keep it short

Depth 1 is the case v0.1 issues and the one to design for. When sub-agent exchange lands, depth 2 will occasionally be right — an agent that needs a specialist to read something for it. Beyond that, ask what the chain is really modelling, because it is usually a workflow that would be easier to understand, and much easier to audit, as several tasks started by the same person.