Skip to main content
A channel connects a Managed Deep Agent to an external messaging service. Messages from the service can start agent runs, and the agent can respond through the same service without a separate application server.
Managed Deep Agents is in public beta and available on LangSmith Cloud in the US region only.

​
Project structure

Channel declarations live in the project-level channels/ directory, with one channel per file:

​
Understand channels

A channel combines three parts of an external messaging integration:
  • Inbound events: Verify and normalize provider events, then start an agent run.
  • Outbound messaging: Send the agent’s response back to the originating conversation.
  • Deployment requirements: Declare the secrets and provider configuration that the deployment needs.
In Managed Deep Agents, a channel connects a deployed agent to a messaging provider. The managed runtime handles the channel lifecycle: Provider adapters determine which events are accepted, how provider conversations map to Managed Deep Agents threads, and how responses are delivered. The channel declaration exposes the supported configuration for that provider.

​
Declare channels in a project

Put each channel in a separate module under channels/. Export a module-level channel from each file. The file name becomes the configured channel name. It identifies the channel at runtime and forms part of its inbound route. For example, a declaration in channels/support.py receives events at:
Do not name a declaration channels/channel.py. Channel names must be unique within a project. The provider factory creates the declaration. For example, channels.slack() creates a Slack channel. See the provider guide for its complete declaration and setup procedure.

​
Access the originating channel at runtime

Channel-originated runs expose runtime.channel to tools and middleware. It contains the normalized event and conversation address, plus methods for posting and updating messages. Ordinary HTTP runs and scheduled runs do not have an originating channel, so runtime.channel is absent for those runs. By default, the managed runner posts the agent’s final response to the originating conversation. Provider guides describe how to customize that behavior and send intermediate messages. Scheduled runs can deliver results through a named channel even though they do not originate from one. See Schedules.

​
Distinguish channels from connectors

A channel receives messages that start agent runs and delivers responses. A connector gives the agent tools for initiating operations against an external service. A project can use either or both. For example, a Slack channel handles mentions and replies, while Slack connector tools let the agent search conversations or send unrelated messages.

​
Supported channels

Slack

Start runs from Slack mentions, direct messages, and thread replies.

​
See also

  • Identity: authenticate callers and scope channel runs to the resolved user.
  • Schedules: deliver scheduled results through a configured channel.
  • Deploy an agent: deploy project changes and configure secrets.
  • CLI reference: review channel project-file conventions.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.
Edit this page on GitHub or file an issue.