> 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, deferred tool-result delivery, and message history for email, SMS, iMessage, and WhatsApp conversations. Open **Build > Channels** in the Developer Console to request managed channel setup. Voice, WhatsApp, and SMS request forms, including SMS campaign registration, are available. 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](/developer-guide/platform-api/conversations/channel-manager.md) for the separate provisioning and runtime contracts. {% content-ref url="/pages/34HJnXyVQXrBvV9THPG9" %} [Channel Manager](/developer-guide/platform-api/conversations/channel-manager.md) {% endcontent-ref %} ## 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. 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. * If a background tool is interrupted before it reports a result, a follow-up turn still runs in the thread. The agent gets a result that says the tool was interrupted and that whether it finished is unknown, so the person hears back instead of waiting until they write again. An interrupted write reports `"outcome": "unknown"`: the agent is told not to send it again and to say it couldn't confirm the request went through. A tool that finished before the interruption delivers only its real result. If a later message leads the agent to call the same companion skill with the same inputs while it is still running, no second run starts, so only that run's answer comes back. A skill bound with `coupled` lifecycle belongs to the turn that started it, so a later turn starts its own run. See [Background (deferred) tool results](/developer-guide/platform-api/conversations.md#background-deferred-tool-results). 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` (wait inline for the answers this turn's background work produces, and return `background_pending: true` with what arrived when time runs out) 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. ### Messaging History On SMS, iMessage, WhatsApp, and email, the conversation's history keeps an agent reply only when the provider accepted it or may have sent it: * A reply the provider accepted is kept. * A reply whose send result is unknown, such as a provider timeout, is kept too, because the recipient may have it, and later turns see it as sent. * A reply the channel refused, such as one the provider rejected or one blocked by an opt-out, is left out of the history. The tool calls of that turn stay in the history. Conversation detail therefore shows what the recipient may have received. Use the channel's delivery status, not the history, to confirm that a kept reply was delivered. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/developer-guide/platform-api/conversations/channels.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.