Skip to main content
Transfer Call connects to a phone or SIP destination through the selected telephony path. Transfer To Agent hands the conversation to another Athena workflow. Create the appropriate tool in Tools and attach it to the conversation nodes that need it.

​
Configure a phone transfer

  1. Create a Transfer Call tool and give it a name and a description explaining when the agent should transfer.
  2. Choose Destination Source: a fixed destination, ordered context routing, or a dynamic HTTP resolver. Configure it using the sections below.
  3. Set Transfer Timeout from 5 to 120 seconds; the default is 30 seconds. This is the wait for the destination to answer, separate from the HTTP resolver timeout.
  4. Choose Pre-Transfer Message: no message, custom text, or a prerecorded clip. Library clips require supported playback; see Recordings.
  5. Configure any transfer disposition exposed by your account. Save the tool, attach it to the relevant node, and tell the agent when to use it and what to do if transfer fails.
  6. Test with destinations you control. Confirm that the destination actually answers and both parties can hear each other. An accepted tool result or a spoken transfer announcement alone does not establish a connected transfer.
The destination format must match your provider: an E.164 phone number, SIP endpoint, or another supported destination. Transfer availability and behavior depend on the telephony path. Do not assume a working outbound call proves transfer support on that route.

​
Fixed destination

Choose the fixed/static source and enter Transfer Destination. A context template such as {{initial_context.transfer_destination}} can resolve it per call. Ensure the trusted call integration supplies the value; do not let arbitrary visitor input choose unrestricted phone destinations.

​
Ordered context routing

  1. Choose the context-routing source and add a rule.
  2. Enter the Context Field, such as department, and add value-to-destination rows, such as sales and support mapped to your approved destinations.
  3. Add more rules if needed and order them from most specific to least specific. The first matching value wins; comparison ignores case and surrounding whitespace.
  4. Optionally set Fallback Destination for unmatched values. Without a match or fallback, the tool reports a resolution failure.
  5. Test every mapping, an unmatched value, and a missing value before publication.
An unprefixed field such as department checks gathered context before initial context, including extracted values where supported. Use initial_context.department or an explicit gathered-context path when only that source should be read. Destinations may use context templates.

​
Dynamic HTTP resolver

Choose the dynamic source. Set Resolver URL, Resolver Timeout, authentication, optional custom headers, LLM Parameters, and Preset Parameters. Add a Resolver Wait Message if the caller should hear an explanation while the lookup runs. Athena POSTs a flat JSON dictionary of resolved arguments. Resolver presets take precedence over model-supplied arguments with the same key. This differs from the HTTP tool’s parameter precedence. For example, your receiver might receive:
Return a successful JSON response containing transfer_context.destination:
The number above is illustrative; replace it with a destination you control. The optional custom_message overrides the configured pre-transfer message when returned. A timeout, non-success HTTP response, non-JSON response, or missing destination is a resolver failure. This mode does not automatically use the context-routing fallback; design and test your resolver’s failure behavior.

​
Transfer introductions

When available, Play a transfer introduction to both parties generates a brief call summary before connecting the parties. Configure Introduction instructions, including the language, and choose a TTS voice that supports it. This feature is offered for Twilio with configured TTS; realtime speech-to-speech agents skip it. Introductions are limited to 25 words and 15 seconds, and transfer continues if preparation fails. Test the introduction on that exact provider and runtime.

​
Hand over to another Athena agent

  1. Prepare and publish the destination agent in the same organization. Confirm its model configuration, tools, and documents are ready.
  2. Create a Transfer To Agent tool. Give it a destination-specific name and description, such as “Transfer to Support” and the conditions that require that specialist.
  3. Select Transfer to agent and the destination workflow.
  4. Set Handover message, or leave it empty for no announcement. Choose Play the destination agent’s greeting: on starts with its greeting; off lets it continue from the handover context.
  5. Save and attach the tool to the source nodes. Add a separate transfer tool for each additional destination so the model has distinct selection instructions.
  6. Test a controlled conversation. Check the announcement, destination activation, carried context, destination tools, and a sensible response if the destination cannot start.
The call path must support in-call handover. A cascade call cannot switch to a realtime speech-to-speech destination through its cascade handover mechanism. Native Athena has its own supported handover path; validate the source/destination combination before rollout. Native Athena handovers require a published Athena destination. The cascade handover path can resolve destination drafts during a draft test. Release and test both sides deliberately; do not assume a draft source call always uses a destination draft. A transferring result records that handover was accepted, not that destination activation finished.