> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anyreach.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Channels
> How one agent serves phone, web voice and chat, and email from a single configuration.
A channel is the transport an agent talks over. Anyreach supports four: `telephone` for PSTN voice, `webrtc` for voice and chat in the browser, `email` for asynchronous mail, and `text` for messages driven through the API. You build and publish an agent once, and the same published version answers across every channel you point at it.
## One agent, every channel
Channel is a property of the conversation, not the agent. When you create a conversation you pick a `channel`, and the agent's published configuration is resolved for that conversation regardless of which transport it runs on. The same instructions, tools, knowledge, and starting message apply everywhere by default.
You then tune behavior per channel without forking the agent, using two optional maps on the agent config:
| Field | What it tunes | Example settings |
| -------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `channel_overrides` | How the agent thinks and responds on a channel (LLM steering) | `instructions` plus `instructions_mode` (`append` or `replace`), `starting_message`, `max_tool_steps` |
| `channel_properties` | How a reply is rendered and delivered on a channel (transport and presentation) | Email: `body_format`, `subject_template`, `signature`, `include_unsubscribe_footer`; Text: `body_template`; per-channel `enabled` |
Both maps are keyed by channel and are additive. When a channel has no entry, it inherits the base agent config and adapter defaults, so voice and `webrtc` are unaffected by an email override.
`channel_overrides` changes the prompt the model sees; `channel_properties` changes the message that gets sent. Reach for an override to make the agent terser on email, and a property to set its email signature.
## The four channels
| Channel | Transport | How it starts | Timing |
| ----------- | ------------------------ | ----------------------------------------------------------------------- | ------------ |
| `telephone` | PSTN voice | A phone number rings the agent, or a campaign dials out | Real-time |
| `webrtc` | Browser voice and chat | A visitor opens your Web Widget | Real-time |
| `email` | Email (via the provider) | Mail arrives at an agent email address, or you start an outbound thread | Asynchronous |
| `text` | First-party API messages | You create the conversation and post messages over the API | Turn-based |
### Telephone
Voice over the public phone network. Inbound calls route to the agent attached to a phone number; outbound calls are placed by a campaign or by creating a `telephone` conversation, which enqueues the call for the dialer (the create call returns `202` with a contact). For `telephone`, `user_id` must be a `+E.164` phone number.
See [Telephony](/telephony/overview).
### WebRTC
Voice and chat that run entirely in the browser, no phone number required. A visitor starts the conversation by opening the Web Widget you embed on your site; the conversation is created immediately. This is the channel for in-app and on-page support.
See [Web Widgets](/web-widgets/overview).
### Email
Asynchronous, threaded email. Inbound mail to a configured agent email address is answered by that address's agent. You can also start an outbound thread by creating an `email` conversation with a `to_address`; the agent sends the first message and continues the thread as replies arrive. Email rendering is controlled by `EmailProperties` (for example `body_format`, `subject_template`, `default_subject`, `signature`).
See [Email](/email/overview).
### Text
A first-party API channel with no transport mechanics of its own — useful for embedding the agent in your own product surface or for programmatic conversations. Create a `text` conversation, then drive the exchange by posting each user message to that conversation's `messages` endpoint:
```bash theme={null}
curl -X POST https://api.anyreach.ai/core/conversations/{conversation_id}/messages \
-H "Authorization: Bearer " \
-H "X-Anyreach-Org: " \
-H "Content-Type: application/json" \
-d '{"text": "Do you ship to Canada?", "interactivity": "plain"}'
```
Set `interactivity` to `rich` to also receive any widgets the agent emits; `plain` returns text only.
User PATs (`pat_`) require the `X-Anyreach-Org` header. Organization API keys (`ak_`) carry their org implicitly, so you can omit it.
## How conversations begin
Every channel produces a conversation that lands in the same inbox, so a phone call, a browser chat, an email thread, and an API exchange are all reviewed and evaluated the same way.
```
phone number / campaign ─▶ telephone ─┐
Web Widget ─▶ webrtc ─┤
agent email address ─▶ email ─┼─▶ conversation ─▶ inbox
API (create + messages) ─▶ text ─┘
```
## Next steps
Inbound and outbound voice over the phone network.
Embed browser voice and chat on your site.
Answer and start asynchronous email threads.
Review every channel in one inbox.