Signal routing rules
A signal routing rule decides which Agent receives a message. One rule currently connects one chat application directly to one Agent. An Agent can use several rules to connect to several chat applications.
The term “signal” leaves room for more than chat. Future rules can use routing expressions to select an Agent by channel, conversation, or other conditions. They can also deliver events from systems such as Salesforce.
If you have not prepared a Slack, Microsoft Teams, Lark, Feishu, or DingTalk application, complete the Channel Provider steps in Quick start first.
Create a routing rule
- Open Signal Routing in the Console and select New routing rule.
- Select the Agent that will receive messages and the Channel Provider adapter.
- Enter a clear rule name, such as
support-slack. - Select the group-message mode and memory scope.
- Enter the credentials and connection details for the chat application, and save the rule.
- Send a message to the bot in that chat application. Confirm that the selected Agent replies.
Give each bot account its own chat application and routing rule. If several Agents must use different bot accounts, create a separate application for each bot and then create each rule.
This keeps Agent identities and messages separate and lets you rotate each credential by itself.
Select a group-message mode
The Console shows only the modes that the selected Channel Provider supports:
| Mode | What happens to a group message that does not address the Agent |
|---|---|
| Addressed messages only | The Agent does not see the message and does not reply. |
| Observe unaddressed messages | The message enters the conversation context but does not wake the Agent. The Agent can use it as context after someone addresses it. |
| May intervene | The Agent first decides whether joining the conversation will help. It replies only when it decides to speak. |
Slack, Microsoft Teams, Lark, and Feishu support all three modes. DingTalk can currently receive only group messages that explicitly address the bot, so the Console offers only the first mode for DingTalk.
May intervene does not make the Agent reply to every message. It lets the Agent decide when to speak. If it speaks too often, first tighten its role instructions.
Use Addressed messages only for a group that needs question-and-answer behavior only.
Select the memory scope
Shared lets group messages enter the shared memory scope for this instance. Use it for work groups where the Agent must keep knowledge across conversations.
Channel only keeps group messages in memory that only this channel can read. Use it for customer data, confidential projects, or teams that must stay separate.
Reconfigure or remove a rule
You can change the target Agent, group-message mode, memory scope, or chat credentials. If you select another Agent, new messages go to that Agent. Existing conversations and memory do not move automatically.
Removing a rule stops new message delivery but does not delete the chat application. You can create a new rule later with the same application.
If the Agent does not reply
- The Channel Provider is missing: open Agent Library → Control Plane Plugins, enable its plugin, and restart the control plane when the page tells you to.
- The bot receives no group messages: check the provider event subscriptions, permissions, and application release state. DingTalk group messages must explicitly @-mention the bot.
- The rule is saved but there is no reply: confirm that the target Agent is enabled, its model configuration works, and the rule is available in the rule list.
- Direct messages work but group messages do not: check the group-message mode and confirm that the bot belongs to the target group.
Use the provider-specific permissions, events, and credentials in Quick start.