Channels

Managed channel provisioning, service routing, and deferred tool-result delivery for email, SMS, iMessage, and WhatsApp.

Open Build > Channels in the Developer Console to request managed channel setup. Voice, WhatsApp, and SMS request forms, including SMS campaign registration, are available without the former Channels preview flag. Submitting a request does not provision a number, approve a campaign, or establish delivery. Concurrence completes channel setup and supplies the use-case identifier; follow Channel Manager for the separate provisioning and runtime contracts.

Channel Manager

Managed Channel Availability

Email, SMS, iMessage, and WhatsApp require managed enablement and channel-specific setup. Self-serve provisioning, operational availability, and preview status are separate questions. Confirm the selected channel's availability with Concurrence, complete its applicable onboarding and consent requirements, then bind the supplied use case to a service.

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.
• Completion can trigger a follow-up turn that uses the tool result to generate the answer.
• The supported transport-managed path requests a follow-up when the tool completes, so normal operation does not require the recipient to poll or send another message. A failed completion dispatch can delay that follow-up until recovery or another inbound turn.
• Filler suppression avoids sending the intermediate acknowledgement as the answer. It does not guarantee exactly one delivered message: a turn can produce multiple buffered messages, and channel delivery can fail independently.
• A genuine tool failure still surfaces through the normal failure path; suppression applies only to the intermediate acknowledgement.

This behavior applies when the managed channel path uses the final-result policy. Tool lifecycle rules still apply: a coupled result that has been superseded is not delivered as a new answer.

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.