> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryopencomputer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up call transfers

> Route to a phone destination or hand a conversation to another Athena agent.

**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](/guides/recordings.md).
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:

```json theme={null}
{
  "department": "support",
  "case_reference": "CASE-EXAMPLE-001"
}
```

Return a successful JSON response containing `transfer_context.destination`:

```json theme={null}
{
  "transfer_context": {
    "destination": "+15555550123",
    "custom_message": "I will connect you to support now."
  }
}
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.