Skip to main content
When an expert hits a subtask outside its own specialty, it can delegate that subtask to another expert. The specialist runs in an independent session and its result flows back for the main expert to integrate. This page covers the three things that trip people up: the candidate roster is not automatic, @-mentioning two or more experts makes delegation mandatory, and costs stack.

​
Where the roster comes from

An expert can only delegate to experts in its roster. That roster has two sources. Source one: the whitelist (auto-injected) In personalization settings, set the delegation policy to whitelist and pick specific experts. Maximum 10.
With policy none or an empty whitelist, the auto-injected roster is empty — no delegation happens at all.The earlier “all” policy (auto-including the 20 most recently used experts) is retired because its behavior was unpredictable. Today’s rule is blunt: an expert not on the whitelist does not appear in the roster on its own.
Source two: @-mentions (effective under every policy) @-mention an expert in the composer and it merges into the head of the roster — even under policy none, even if it is not whitelisted. An explicit mention counts as stronger intent than a toggle. Either way, an expert only enters the roster if all of these hold: Failures are filtered silently: put 5 on the whitelist, have 3 resolve, and nothing is reported in the conversation — the other 2 simply are not in the roster. A roster build failure is also non-blocking; that turn just has no delegation capability.

​
Mentioning two or more makes delegation mandatory

This is a hard behavioral hinge:
  • One @-mention: advisory. The model may delegate or may do the work itself — a single mention is often just a reference.
  • Two or more: a mandatory directive is injected. The model must call the delegate tool once for each mentioned expert, must not do their parts itself, must not skip any, and must synthesize all results at the end.
If you also @-mentioned the current expert, that part is its own to execute directly — it is not in the roster and needs no delegate call.
If you want deterministic division of labor, mention everyone. If you want the main expert to decide, mention no one.

​
Background by default

Delegation runs in the background by default: the tool returns a job handle immediately, the main expert keeps working or replies to you, and the specialist’s result is injected back automatically when it finishes. The model only switches to blocking when it genuinely cannot proceed without the result in the same turn. The execution budget is fixed at 900 seconds (15 minutes), matched on both the server and runtime sides, and cannot be extended — passing a longer timeout only changes how long the local call waits, never how long the specialist gets. A timeout gives you an explicit signal:
Same for a failure:
In both cases the main expert receives clear feedback and either handles the work itself or tells you where it is stuck, rather than silently dropping the result.

​
Delegation versus multi-task subagents

Both farm work out, but they are different things: Both obey the same constraint: whoever is dispatched does not receive the delegate or task tools (they are L1-reserved), so the chain cannot recurse indefinitely. A specialist also cannot modify the main conversation’s plan document.

​
Costs stack

One delegation ≈ an extra full conversation turn, plus the main expert reading the returned result into context (another token cost). So “main expert + 3 delegations” can cost several times a plain turn.All of it bills to your account under token_split — the specialist’s creator does not absorb the runtime cost.
Two practical ways to keep it down:
  1. Only whitelist experts you actually use. The roster occupies system-prompt space; ten expert briefs sit in context every turn.
  2. Write complete task descriptions. The specialist cannot see your conversation history, and an underspecified task makes it flail — far more expensive than two extra sentences.
Model rates are operational data — the model selector is authoritative; the algorithm is fixed, see billing formulas.

​
Where the roster briefs come from

The one-line brief shown for each candidate resolves in this order: the creator’s delegation brief → the expert description → an empty string. For creators this is a field worth caring about: it decides whether other experts think of you at the right moment. “Turns messy data into charts with statistical conclusions” is far more useful than “data analysis expert.”

​
Failures and what to do

​
FAQ

No. The specialist runs in an independent session and only sees the task description passed to it, never your history. What comes back is a structured summary, not its full transcript.
Yes. Set the policy to none and @-mention no one; the main expert gets no roster and therefore cannot delegate.
Yes — it executes with its own skills and memory, which is the whole point. It does not read your memories from the main conversation.
Yes. A completed delegation (expert, task summary, result, duration) is written into your memory as one entry, best-effort — a failure there never affects the conversation.

​
Keep reading

Personalization

Delegation policy, whitelist, and the multi-task toggle

Subagents and delegation

Parallel division of labor inside one expert

Configure your expert

Creator side: the delegatable flag and delegation brief

Billing formulas

How token_split is computed