---
title: Overview
description: "How users reach your agent: the channel contract, the base eve HTTP channel, and authoring custom channels."
url: "https://eve.dev/docs/channels/overview"
docs_index: /llms.txt
---

> For an index of all documentation, see [/llms.txt](/llms.txt).

A channel connects a platform to your agent. For conversations, it:

- Converts incoming messages into agent input.
- Maps each platform conversation to an eve session.
- Decides how, where, and whether to deliver replies.

A channel can also receive events and pass them to another channel, without starting a conversation of its own.

eve ships a base HTTP channel plus first-class platform channels, and you can author your own. Browse the full set in the [Integrations](/integrations) gallery and choose the Channels filter.

After a channel dispatches a message, eve runs the same agent runtime regardless of where the event came from. Tools and instructions do not need channel-specific logic.

## Choose where the conversation lives

The agent doesn't have to reply where an event arrived. A webhook, for example, can start a conversation in a team chat without sending an agent reply to the webhook's source.

Use a [cross-channel hand-off](./custom#cross-channel-hand-off) when the conversation belongs elsewhere. The destination channel handles the session, replies, and follow-up messages. To post a notification without running the agent, use the platform's API instead.

## Audience

When a channel creates a session, it assigns an observability audience:
`public`, `private`, or `unknown`. The audience controls trace content capture,
not who may call the channel. Each channel uses the visibility information it
has; `unknown` is the safe default when it cannot classify a conversation.

Route auth controls access and supplies the session principal. See [Auth &
route protection](../guides/auth-and-route-protection) for principal types and
authorization. See the [default eve HTTP channel](./eve#audience) for its
mapping, or [custom channels](./custom#conversation-audience) to classify your
own.

## Overlapping messages

Channels default to `turnPolicy: "steer"`. Before assistant answer output or local tool execution begins, a message can interrupt pending model generation and continue the same turn with the correction. Executing tools finish and checkpoint their results before steering reaches the next model call. After answer output starts, steering waits for the next committed workflow boundary. The turn ID stays the same.

Reasoning and search progress do not count as answer output. Interrupted provider-managed search may run again; completed local tools are preserved.

Set `turnPolicy: "queue"` on any built-in or custom channel when each turn must finish before the next message starts:

```ts
export default defineChannel({
  turnPolicy: "queue",
  routes: [
    // ...
  ],
});
```

Adjacent queued messages can combine into one turn only when their full auth contexts match, including identity, issuer, authenticator, and authorization attributes. Their attachments and context stay in payload order. A different auth context ends the batch; eve does not regroup messages across intervening senders. Anonymous deliveries stay separate. Turns still share the session's conversation history.

`from(address).send(...)`, fixed `Session.send(...)`, cross-channel sends, and Chat SDK bridge sends also accept a per-send `turnPolicy` override. Pure `inputResponses` deliveries answer their pending request without steering. Explicit `cancel()` remains the stop-without-replacement operation.

Events rejected before `send(...)`, such as invalid signatures or filtered mentions, never reach the active turn. A delivery already sent to the session can interrupt pending generation before the channel's `deliver` hook processes it. If that hook ignores the correction, eve resumes the original request with its original auth, delivery provenance, and channel state.

Each channel has its own provider terms, data flow, auth model, and user-consent expectations. Before sending non-public, sensitive, regulated, or production data through a channel, confirm that the channel provider and your configured scopes, signature checks, route auth, and delivery behavior are appropriate for your use case.

## Where channels live

Channel files live under `agent/channels/` in the root agent or come from an [extension](../extensions) mounted there. The file stem is the channel id: `agent/channels/intake.ts` is addressed as `intake`. An extension mount prefixes its contributed channel IDs but does not change their route paths. Local subagents do not declare channels.

```text
agent/
  agent.ts
  channels/
    eve.ts
    slack.ts
    intake.ts
```

Install a channel from the registry with `eve add channel/<name>`, such as `eve add channel/slack` or `eve add channel/web`. You can also author the file by hand.

## The eve HTTP channel (default)

The eve channel is the framework's default HTTP session API, the routes the terminal UI, [`useEveAgent`](../guides/frontend/overview), and `curl` all talk to. Its selected `channels/eve.ts` source owns health, inspection, callbacks, task input, and the session protocol as one replaceable surface. eve supplies the source when no `agent/channels/eve.ts` file exists; author that file to replace it, most often to change route auth. See [HTTP channel](./eve) for routes, auth, replacement, and disablement.

## Custom channels

Build a channel with `defineChannel` from `eve/channels` when you need your own HTTP or WebSocket endpoint. Its routes can start conversations on that channel or hand work to another one. See [Custom channels](./custom) for examples and the authoring API.

## Relationship to the Chat SDK

eve uses the [Chat SDK's card-builder components](https://chat-sdk.dev/docs/api/cards) (Cards, Buttons, Actions, etc.) for composing rich Slack messages. When you build a card with the [Slack channel](./slack), the underlying primitives come from the Chat SDK and get converted to Slack Block Kit at post time.

eve's first-class channels use eve-owned runtimes for webhook handling, verification, event parsing, and thread management. The optional [Chat SDK channel](./chat-sdk) is the exception: it accepts a Chat SDK adapter and exposes its `Chat` and `Thread` primitives. Use `slackChannel` for eve's first-class Slack integration, `defineChannel(...)` for an eve-native custom channel, or `chatSdkChannel` when you intentionally want a Chat SDK adapter and runtime.

## Which channel?

| You want…                                   | Use                                                        |
| ------------------------------------------- | ---------------------------------------------------------- |
| A web app / browser chat UI                 | eve channel + [`useEveAgent`](../guides/frontend/overview) |
| Local tooling, SDK clients, `curl`          | [eve HTTP channel](./eve) (default)                        |
| MCP clients delegating durable work         | [MCP](./mcp)                                               |
| Slack mentions, DMs, buttons                | [Slack](./slack)                                           |
| iMessage and SMS                            | [Linq](./linq)                                             |
| iMessage                                    | [Photon](./photon)                                         |
| Discord slash commands, components          | [Discord](./discord)                                       |
| Microsoft Teams messages + Adaptive Cards   | [Teams](./teams)                                           |
| Telegram bot messages                       | [Telegram](./telegram)                                     |
| SMS or speech-transcribed phone calls       | [Twilio](./twilio)                                         |
| GitHub @mentions, PR review with checkout   | [GitHub](./github)                                         |
| Linear issue delegation and Agent Sessions  | [Linear](./linear)                                         |
| Another Chat SDK-supported service          | [Chat SDK adapters](./chat-sdk)                            |
| Anything else (internal webhook, WebSocket) | [Custom channel](./custom) (`defineChannel`, above)        |

## Disclaimer

As the deployer, it is your responsibility to ensure your agent complies with applicable laws.

Where an eve agent communicates with people, you may be required to disclose that they are interacting with an automated AI system where law requires it. eve does not add this disclosure automatically; configure it in your instructions and/or channel responses. See [Responsible use](../responsible-use) for the full deployer responsibilities.

## What to read next

- [eve HTTP channel](./eve): the default session API behind the TUI, SDK clients, and browser UIs
- [Slack](./slack): the most common platform channel, end to end
- [MCP](./mcp): expose the agent as a durable invocation service
- [Linq](./linq), [Photon](./photon), [Discord](./discord), [Teams](./teams), [Telegram](./telegram), [Twilio](./twilio), [GitHub](./github), and [Linear](./linear): the other first-class platform channels
- [Chat SDK adapters](./chat-sdk): reach services eve has no first-class channel for
- [Custom channels](./custom): build a channel for any surface with `defineChannel`
- [Durable cross-channel notifications](../patterns/durable-cross-channel-notifications): post to another platform without starting an agent turn
- [Frontend](../guides/frontend/overview): browser chat on the eve channel with `useEveAgent`
- [Integrations](/integrations): browse every built-in channel in one gallery using the Channels filter

---

For a semantic overview of all documentation, see [/sitemap.md](/sitemap.md)

For an index of all available documentation, see [/llms.txt](/llms.txt)

For agent-facing discovery, including API and MCP surfaces, see [/agents.md](/agents.md)