Is it possible to pass extra context or send contetxual update during transfer_to_agent tool call?

[pale nymph]

AI-generated Answer for dinesh_85560

Short answer: not inside the transfer_to_agent tool call. The tool’s arguments are limited to agent_number (required) and reason (optional). There is no field to attach arbitrary context, and system tools (like transfer_to_agent) cannot update dynamic variables. (elevenlabs.io)

How to pass context around a transfer

• Send a contextual_update client-to-server event on the same conversation WebSocket. Contextual updates are designed to add background info without interrupting the flow and can be sent at any time (e.g., immediately before the transfer). The event payload is: { "type": "contextual_update", "text": "..." }. (elevenlabs.io)
• If you need structured values available to the next agent’s prompt, use dynamic variables. Populate them at conversation start or update them via tool results before transferring (system tools cannot do this; use client or server tools that return JSON and assign into variables). (elevenlabs.io)
• Optionally configure a transfer_message in the transfer rule (it plays to the user during handoff) and whether the receiving agent should play its first message; this does not carry hidden context. (elevenlabs.io)

Python SDK example (sending a contextual update)

• Use your conversation’s WebSocket and send the contextual_update JSON defined in the docs. For example with websockets in Python:
  • await websocket.send(json.dumps({ "type": "contextual_update", "text": "Customer tier: Gold; open ticket #1234" }))
    This uses the event structure documented for contextual updates and the same Python WebSocket pattern shown in the multi‑context examples. (elevenlabs.io)

Configuring transfer_to_agent with Python SDK

• Define transfer rules when creating/updating the agent (you choose targets, optional delay_ms, optional transfer_message, and whether the transferred agent should play its first message). The LLM will then call transfer_to_agent with agent_number and (optionally) reason when conditions match. (elevenlabs.io)

If you need the receiving agent to “see” extra data, send a contextual_update and/or update dynamic variables via a tool call just before the transfer; don’t rely on the transfer_to_agent call to carry custom context. (elevenlabs.io

[pallid niche]

If you need the receiving agent to “see” extra data, send a contextual_update and/or update dynamic variables via a tool call just before the transfer;
How can I make sure that the tool call will be called before transfering to an agent?

[pale nymph]

AI-generated Answer for dinesh_85560

Short answer: there’s no hard, API-level guarantee to force a custom tool to run before transfer_to_agent. Transfers are initiated by the LLM based on your transfer rules and descriptions. You can only bias the order, not enforce it.

What you can do (documented):

• Tell the LLM the sequence explicitly. In your agent/system prompt, instruct: “Before calling transfer_to_agent, call <your_tool> and wait for its result.” ElevenLabs recommends specifying tool-calling order/logic in the prompt. (elevenlabs.io)

• Make the tool block until its result is in context. For client tools, enable “Wait for response” (expects_response) so the agent pauses until your tool returns and the response is appended to the conversation context. (elevenlabs.io)

• Use dynamic variable assignments from the tool response if the receiving agent needs structured values. Server tools can assign fields from their JSON response into dynamic variables for later use. (elevenlabs.io)

• Give yourself a small buffer before the transfer. Agent transfer rules accept delay_ms; adding a short delay gives time for a contextual_update or tool response to land before the handoff. Note that contextual_update events are asynchronous (no ordering guarantee), so the delay is a best-effort buffer. (elevenlabs.io)

Limits to be aware of:

• Contextual updates are processed asynchronously and don’t interrupt the flow, so they can race with a transfer if issued too late. There’s no ordering guarantee. (elevenlabs.io)

• The LLM decides when to call transfer_to_agent using your natural-language conditions; there’s no platform switch to “lock” transfer until your tool has run. (elevenlabs.io)

If you need strict determinism, use the above prompt+blocking tool pattern; otherwise there’s no documented way to guarantee a pre-transfer tool invocation in the SDK. (elevenlabs.io)

Sources:
Tools — ElevenLabs Documentation
Client tools | ElevenLabs Documentation
Dynamic variables | ElevenLabs Documentation
Agent transfer | ElevenLabs Documentation
WebSocket | ElevenLabs Documentation
Agent transfer | ElevenLabs Documentation
Tools — ElevenLabs Documentation

[pallid niche]

I need prompt+blocking tool pattern. Can I know in the tool called before transfer_to_agent which agent is being transferred to? Or can I specify to call a different tool before transferring to each agent? Each agent would have you tool to run before transfer_to_agent