Agent transfer, handing off control instead of calling

The last pattern kept the orchestrator in charge: it called a specialist, got a result, and carried on. Transfer is the other choice. Control moves to the specialist, which takes over the conversation.

The difference sounds subtle and matters a lot. In one, a manager asks an expert a question and relays the answer. In the other, the manager says "you handle this from here" and steps back.

Call-and-return, versus hand-over

A customer-service example makes the two concrete. The customer says "I cannot connect to the server."

Under agent as tool, the general agent stays the face of the conversation. It asks the tech specialist, relays the answer, the customer replies, and the general agent asks the specialist again. Every exchange round-trips through the orchestrator.

Customer:      I can't connect to the server.
General agent: (asks tech) Please check your network settings.
Customer:      How do I do that?
General agent: (asks tech again) Go to Settings > Network...

Under transfer, the general agent hands the whole conversation to the tech specialist, which then talks to the customer directly until the issue is resolved.

Customer:      I can't connect to the server.
General agent: (transfers to tech specialist)
Tech agent:    Let's check your network settings. How are you connected...
Customer:      How do I do that?
Tech agent:    Go to Settings > Network...           (still the tech agent, directly)

Call-and-return suits a quick question the orchestrator should stay on top of. Hand-over suits a sustained task a specialist should own, because relaying every turn through the orchestrator is wasteful when the specialist is going to handle all of them anyway.

Agent as tool relays each turn through the orchestrator. Transfer hands the conversation over.

Transfer is also a tool

Like everything the orchestrator does, a transfer is a tool call. The orchestrator has a transfer_to_agent tool, and calling it hands control to the named specialist.

@tool
def transfer_to_agent(agent_name: str) -> str:
    """Hand control of the conversation to a specialist agent."""
    context.state["active_agent"] = agent_name       # control moves here
    return f"Transferred to {agent_name}."

The mechanism is small because the interface is the same one used throughout this series. What changes is not how the agent asks, but what the ask means: not "run this and give me the result", but "you are in charge now."

The agent tree

Transfer produces a natural structure: a router at the top, specialists below it.

        router agent
        /     |      \
   billing  tech   account
   agent    agent   agent

A request arrives at the router, whose only job is to recognise which specialist it belongs to and transfer. The specialist inherits the full conversation and handles the task to completion. The router is a receptionist: it does no specialist work itself, it just gets you to the right desk.

The transfer flow, in four steps:

1. The router receives the request.
2. It picks the right specialist and calls transfer_to_agent.
3. Control moves; the specialist inherits the full conversation history.
4. The specialist handles the task and returns the result.

Step three is the one to hold onto. The specialist does not start fresh; it inherits everything said so far, so it has the context to take over mid-conversation. That inheritance is what makes hand-over smooth, and it is also, as the security series will note, what makes transfer a place to think carefully about what each specialist is handed.

A router transfers to a specialist, which inherits the full conversation and owns the task.

Choosing between the two runtime patterns

Agent-as-tool and transfer both let the model pick specialists at runtime. The choice between them is about who stays in charge.

Use agent-as-tool when the orchestrator should stay the single point of contact. Use transfer when a specialist should genuinely take over, and relaying every turn would be pure overhead.

What to take from this

• Transfer hands control to a specialist, rather than calling it and relaying a result. Control moves; the specialist owns the conversation from there.
• It is a tool call like everything else, but the meaning is "you are in charge now", and it produces a router tree: a receptionist at the top, specialists below.
• The specialist inherits the full conversation, which is what makes hand-over smooth, and what makes it worth thinking about what each specialist is handed.

All three patterns so far run agents in one process, on one machine. Agents can also live on different machines and talk over a network, which is a protocol of its own. The next post builds that.