Skip to main content
A custom channel would connect messages from your application to an agent and return replies to the correct recipient. Prepare that boundary before choosing a transport.
There is no verified released custom-channel adapter or custom WebSocket SDK. Agent execution remains gated. Saving a tool or agent configuration does not create an inbound messaging endpoint.

​
Design the message flow

You need a channel owner, its authentication contract, sample messages without personal data, and a documented routing policy.
1

Identify the sender and destination

Define how your server authenticates the channel’s requests and maps a channel user to permitted application data. Bind the target workspace and agent on your server. A channel user ID does not grant workspace membership or authorize an arbitrary agent ID.
2

Define delivery records

Preserve the provider message ID, destination, and processing outcome. Deduplicate repeated inbound deliveries. Specify size and attachment limits, unsupported-message responses, and how an operator handles a message that cannot be routed.
3

Review outbound actions

Show the intended recipient and message before a consequential send. Track acceptance separately from delivery and conversation completion. An uncertain response requires reconciliation before retrying, so one request does not produce duplicate messages.
Use secrets and auth connections only in supported configuration fields. Tool authoring can describe a future outbound action. It does not implement your bridge or release the agent runtime.

​
Frequently asked questions

A saved client tool definition does not provide an inbound transport. Your channel design needs a separately implemented and authorized receiver.
A released execution path, reviewed identity mapping, retry handling, recipient confirmation, and a tested route for delivery failures. Configuration read-back alone proves none of these.