> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/developer-guide/platform-api/conversations/channels.md).

# Channels

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

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](/developer-guide/platform-api/conversations/channel-manager.md).

{% content-ref url="/pages/34HJnXyVQXrBvV9THPG9" %}
[Channel Manager](/developer-guide/platform-api/conversations/channel-manager.md)
{% endcontent-ref %}

## Managed Channel Availability <a href="#internal-preview-channels" id="internal-preview-channels"></a>

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.

{% hint style="info" %}
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](/developer-guide/platform-api/conversations.md#background-deferred-tool-results) for that interactive path.
{% endhint %}

{% hint style="info" %}
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](/developer-guide/platform-api/conversations.md#background-deferred-tool-results).
{% endhint %}

For the buyer-facing description of this behavior, see the conceptual [Email channel](https://docs.concurrence.com/channels/email) documentation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.concurrence.com/developer-guide/platform-api/conversations/channels.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.