Channels

Internal-preview channels - email, SMS, iMessage, and WhatsApp - and how agents deliver long-running tool results on non-live channels.

The Channels surface covers channels that are not yet self-serve provisionable. Once a channel is enabled for your workspace, provisioning and use-case configuration happen through Channel Manager.

Channel Manager

Internal-Preview Channels

Some channels - email, SMS, iMessage, and WhatsApp - are currently in internal preview. These channels are not self-serve provisionable because they involve regulated infrastructure (carrier registration, dedicated messaging lines) or are held for managed enablement. To enable one of these channels for your workspace, reach out to the Amigo team, who will coordinate provisioning.

Long-Running Tool Delivery on Non-Live Channels

The messaging channels above (email, SMS, iMessage, WhatsApp) are non-live: the recipient is not connected while the agent reasons, and there is no live stream to keep open. This changes how the agent delivers a reply that depends on a long-running (background) tool - a multi-step lookup, an external system call, or a data query that reaches out to another system.

On a live channel (voice, web chat), the agent emits a short filler ("Let me check on that...") to fill the wait while the tool runs, then follows with the real answer. That behavior is unchanged.

On a non-live channel, a filler would add a message without adding an answer, and the recipient has no way to stream or poll to pick up the follow-up. So the default behavior is different:

• The intermediate filler is suppressed - it is never delivered as the reply.
• The agent waits for the tool to complete and delivers the real answer as a single follow-up message.
• Delivery is event-driven: the follow-up is dispatched the moment the tool finishes. The caller does not need to send another message, poll, or hold a connection open to receive it.
• The exchange stays one inbound, one outbound - one incoming message produces exactly one outgoing reply, and that reply is the actual answer rather than a placeholder.
• A genuine tool failure still surfaces through the normal failure path; suppression applies only to the intermediate acknowledgement.

This is the default for all non-live channels and requires no configuration.

This suppress-and-follow-up behavior is specific to the transport-driven messaging channels (email, SMS, iMessage, WhatsApp), where the platform owns delivery back to the recipient. It is distinct from the synchronous REST turn contract, where a background tool returns background_pending: true with an acknowledgement and the caller drains the result on a later turn or by polling. See Background (deferred) tool results for that interactive path.

For the synchronous batch/API path, per-request controls are available on the turn request: wait_for_final (await the real answer inline, bounded, falling back to background_pending: true on timeout) and suppress_filler (omit the acknowledgement text from output so a batch caller never mistakes it for the answer). See Background (deferred) tool results.

For the buyer-facing description of this behavior, see the conceptual Email channel documentation.