Transfer vs. delegate

There are two distinct ways one sub-agent hands work to another. The most important rule to remember is that DELEGATE is the default; TRANSFER is the justified exception.

Definitions

• Transfer: The target becomes the new active responder for the rest of the conversation.
• Delegate: The caller asks the target for an answer to a specific sub-task and stays in charge, receiving the result back.

Transfers for delegation

Can you use transfers for delegation? In short: no. While you might be tempted to use a transfer to send work to a specialist and expect them to transfer it back, this creates ownership thrash and unstable routing. Always use the built-in delegate action when you need a sub-agent to consult another and return the result.

Rules of engagement

• Authoring Default: Prefer delegation for peer edges. Transfer to a peer only when conversation ownership must move to that peer (e.g., triage to an owner specialist, or a terminal domain switch). If both could work, choose delegate unless you can justify permanent ownership transfer.
• A sub-agent can only transfer/delegate to targets explicitly listed in its own allowed-targets list. This is validated when the agent design is saved AND re-checked at run time.
• A sub-agent that is really a different, externally-linked agent (a cross-agent reference) can only ever be a DELEGATION target, never a transfer target. "Becoming" someone else's agent via transfer has no coherent meaning.
• Only one transfer can win per turn. Delegation supports multiple targets in the same turn (fan-out) — another reason consult-style edges should be delegate, not transfer.
• Each hop is bounded independently — a transfer-count cap and a success-based delegation cap both apply. Only handoffs that actually complete count against the delegation cap (skipped/failed ones don't).

What you see in traces

• Routing events show "transfer" and "delegation" as distinct event types, each carrying a from/to sub-agent pair.
• A route_error event means a handoff was attempted but rejected — check its recorded error code.

Authoring implications

• Decision checklist per peer edge: Does the caller need the result back to synthesize or continue? → Delegate. Should the user talk only to the specialist from now on? → Transfer. "Get data from X then answer" is always delegate, never transfer.
• Reachability: Design the handoff graph so every sub-agent is reachable from the default one — an unreachable specialist can never be routed to even though the design itself validates fine.
• Typical shape: A triage/router default sub-agent often TRANSFERS to one owner specialist; specialists DELEGATE to helpers. Avoid a full mesh of transfers.
• Dual-listing the same peer for both actions is allowed but each edge needs a distinct role. Do not dual-list for flexibility without a reason.
• If a sub-agent needs to consult another team/agent without giving up control, only delegation supports that — don't try to model "ask and come back" as a transfer.