Channels

Applies to Framework (not available)Self-hosted Everruns Cloud

A channel is an Agent-owned way for an external caller to reach that Agent and get a reply. Each channel belongs to exactly one Agent and has its own transport configuration, authentication, session routing, version policy, and publish state. One Agent can have several channels, and publishing or unpublishing one does not change the others.

Use a channel when an external peer sends a request and waits for a reply. Use an Agent trigger when a schedule or event starts Agent work without a reply channel.

How work enters an Agent: channels (Slack, AG-UI, A2A, FCP, Public Chat) route a caller's message to the Agent and return its reply; triggers (schedule, webhook, GitHub, MCP events) send a configured message with no reply channel. Either way the message lands in a session and the turn runs on the Agent's Harness.

Agent Channel Architecture

Channel types

Type	`channel_type`	Who calls it	Canonical route	Guide
Slack	`slack`	Slack users, through a Slack app	`/v1/channels/{channel_id}/slack/events`	Slack
AG-UI	`ag_ui`	Browser and app clients that speak the AG-UI protocol	`/v1/channels/{channel_id}/ag-ui`	AG-UI
A2A	`a2a`	Other agents, over the A2A protocol	`/v1/channels/{channel_id}/a2a`	A2A
FCP	`fcp`	Any HTTP client, text in and text out	`/v1/channels/{channel_id}/fcp`	FCP
Public Chat	`public_chat`	Visitors to a hosted chat website for one Agent	`/v1/channels/{channel_id}/public-chat`	Public Chat

Routes are relative to the API base, for example https://your-everruns-host/api. The channel ID in each route is the channel’s own ID, not the Agent’s.

Create a channel

Open the Agent and select the Integrations tab.
Select Add channel and choose the channel type.
Configure the type-specific fields and select Save channel.
Select Publish to make the channel live.

The same operations are available over the API under /v1/agents/{agent_id}/channels, with publish and unpublish actions per channel. Each channel can follow the Agent’s default version, its latest version, or a pinned version; see Agent Versions.

Channel lifecycle

Each channel has its own lifecycle:

Draft ⇄ Live
Draft → Disabled
Live → Disabled
Disabled → Draft

Draft: Configured but does not accept ingress traffic.
Live: Published and able to accept traffic while its Agent is active and exposures are not suspended.
Disabled: Kept for configuration but rejects ingress traffic and does not invoke the Agent.

Publishing and unpublishing require the dangerous Agent permission (Owner by default). The same permission is required to change a live channel’s configuration, including its authentication and secrets, or to disable it. Members who can manage Agents can still edit Draft and Disabled channels.

A channel serves traffic only when all three hold: the channel is live, the Agent is active, and the Agent’s exposures are not suspended. Suspending exposures from the Agent’s Integrations tab takes every channel of that Agent offline at once without changing each channel’s state.

Errors from public channels are sanitized so they do not expose internal state, such as whether a channel exists or why it is offline.

AG-UI

An AG-UI channel lets a client that speaks the AG-UI protocol run the Agent and stream its events. The channel accepts AG-UI RunAgentInput and streams AG-UI 1.0 events over SSE. Public Chat uses the same protocol.

Upgrade a pre-1.0 client

Use a 1.0-compatible AG-UI client for existing channels as well as new ones. The reasoning event names changed:

Pre-1.0 event	AG-UI 1.0 event
`THINKING_START`	`REASONING_START`
`THINKING_TEXT_MESSAGE_START`	`REASONING_MESSAGE_START`
`THINKING_TEXT_MESSAGE_CONTENT`	`REASONING_MESSAGE_CONTENT`
`THINKING_TEXT_MESSAGE_END`	`REASONING_MESSAGE_END`
`THINKING_END`	`REASONING_END`

Custom handlers must recognize the new names to render reasoning. This is a breaking wire change for clients that require THINKING_*; the channel does not translate events back to that vocabulary. Text messages still use TEXT_MESSAGE_*.

With npm @ag-ui/core 1.0, import validation schemas from @ag-ui/core/schemas:

import { EventSchemas, RunAgentInputSchema } from "@ag-ui/core/schemas";

Send protocolVersion: "1.0" in the run request to receive the version in RUN_STARTED. Omitting it suppresses that response field; it does not select the old protocol. Open text and reasoning messages and reasoning spans close before a terminal event. Cancelled runs finish with outcome: { type: "cancelled" }.

Subagent events and their activity snapshots are available when the channel enables subagents_visible. This setting defaults to off and stays off for Public Chat.

Visibility and access

AG-UI channels are public client surfaces, so they expose less than the Agent’s own event stream:

tool_visibility controls tool activity: none, generic (a fixed text you configure in generic_tool_text), or narrated. Raw tool names, arguments, and results are never sent.
Reasoning summaries, token usage, subagent activity, and client answers to tool-approval interrupts are off by default, each behind its own setting.
Access is anonymous by default. Set a shared token or an auth block to require authentication, and rate_limit_per_minute to cap requests per IP.
A thread stays resumable for session_expiration_seconds (6 hours by default); after that, the same thread ID starts a new session.

To serve AG-UI from a Rust application without the Platform, see AG-UI in the Framework.

FCP

An FCP channel implements the Free Communication Protocol, a minimal text-in, text-out HTTP interface:

GET returns a Markdown handshake that describes what the channel can do and how to authenticate.
POST takes plain text, or {"message": "..."}, runs one turn, and returns the Agent’s final reply as Markdown. There is no streaming.

Every response, including errors, is text/markdown with instructions that point back to the handshake. Access is anonymous by default; set anonymous to false and a token to require a shared bearer token. FCP has its own rate limit and does not accept the auth block that AG-UI and A2A use. response_timeout_seconds (120 by default) bounds how long a POST waits for the reply.

Public Chat

A Public Chat channel serves an isolated, hosted chat website for one Agent. Visitors see only that Agent: there is no console navigation, organization switcher, or access to other agents, channels, or sessions.

Visitors can be anonymous, or sign in through the channel’s auth configuration, such as Google sign-in. Anonymous visitors can be required to pass a Cloudflare Turnstile challenge before a session starts.
The chat streams AG-UI events, and raw tool names, arguments, results, and internal IDs never reach the browser.
The deployment-level public_chat feature flag (FEATURE_PUBLIC_CHAT) controls whether Public Chat routes are mounted and whether the type appears under Add channel.

The website reads its public configuration from /v1/channels/{channel_id}/public-chat/config. That response never includes channel secrets.

Other transports

The same channel model also carries transports that do not need a reply channel:

webhook runs the Agent when an authenticated HTTP call reaches /v1/channels/{channel_id}/webhook, and is available under Add channel.
schedule runs the Agent on a cron schedule. Create schedules as Agent triggers, which also cover webhook, GitHub, and MCP event starts.
api_endpoint gives callers an execution-only API key for the session routes under /v1/channels/{channel_id}/sessions.

Existing integrations

Channels replace the former Agent Endpoint name. Existing channel IDs and configuration stay the same. CLI commands now use everruns agents channels; the management API uses /v1/agents/{agent_id}/channels. The former /v1/agents/{agent_id}/endpoints routes remain aliases, and console bookmarks under /agents/{agent_id}/endpoints redirect to the channel pages.

Retired Apps

Apps are retired from Everruns management. Everruns keeps existing App records for historical attribution and compatibility, and existing installs continue to serve traffic, but the App list, detail page, create flow, and management API are retired.

The old /v1/e/{channel_id}/… and /v1/apps/{app_id}/… ingress paths remain permanent aliases. They resolve to the migrated channel and continue to work. Do not rewrite a working existing installation only to change its URL. New integrations use the channel-scoped canonical routes above.