Bring DataFact Agents to Slack and Telegram

DataFact now supports Slack and Telegram as native messaging channels for Agent conversations.

They join the existing DingTalk and Feishu options, giving teams more ways to make an Agent available where work is already happening. Instead of moving every question into a separate console, an approved user can interact with a configured Agent through the organization’s chosen messaging platform.

The channel changes where a conversation is delivered. It does not redefine what the Agent can access, which tools it can use, or which data a user is authorized to receive.

What was added

• Slack for Agent conversations in Slack workspaces.
• Telegram for Agent conversations through a configured Telegram bot.

Teams and custom applications can still use the open API when a native channel is not the right delivery path. Slack and Telegram add product-supported options; they do not replace the other channels or the API.

Each provider has its own application model, credentials, permissions, and delivery behavior. DataFact therefore presents provider-specific configuration rather than pretending every platform follows one generic App ID and App Secret contract.

Register a Slack or Telegram channel

Open Applications, create a channel, and select Slack or Telegram. The current form displays the values required by the released provider integration. Obtain those values from the corresponding Slack app or Telegram bot configuration.

Protect those credentials as service secrets. Do not paste them into tickets, screenshots, prompts, or shared documents. When credentials rotate, update the channel configuration and repeat the delivery test.

See the channel creation guide for the released workflow and current fields.

Connect the channel to an Agent

Saving the channel registers an external delivery endpoint. It does not attach that endpoint to every Agent automatically.

Open an editable General Agent and connect the registered channel from the Agent’s configuration. Keeping registration and association as separate steps prevents a newly created app or bot from being implicitly exposed through an unintended Agent.

See the Agent connection guide for the association flow.

The operating model is:

Slack app or Telegram bot
            ↓
registered DataFact channel
            ↓
explicit Agent association
            ↓
Agent resources and execution controls

Each step has a distinct owner and failure mode. Provider registration can succeed while Agent association is missing. Agent association can exist while the external app lacks workspace permission. A saved secret can be valid while event delivery or bot access remains incomplete.

Keep access control outside the chat prompt

Moving an Agent conversation into Slack or Telegram should not move governance into the chat prompt. The Agent’s resources, tools, data permissions, and execution controls remain the authority for what it can retrieve or query.

Registering Slack does not grant every Slack member access to every DataFact resource. Creating a Telegram bot does not make all configured Agents available through that bot. The organization must still decide who can reach the external integration, which Agent it exposes, and what that Agent is allowed to do.

The channel can also provide presentation controls for reasoning and tool messages. Those settings affect which execution details are forwarded to the messaging platform. They do not grant or revoke the Agent’s underlying tools or data access.

Verify delivery and boundary behavior

A successful channel setup needs more than a saved form. Test the complete path in the intended workspace or chat environment.

Before enabling a team, verify:

1. The Slack app or Telegram bot is active in the intended environment.
2. The external platform grants the permissions required by the released integration.
3. Provider credentials are stored only through approved secret-handling paths.
4. The channel is connected to the intended General Agent.
5. The Agent has only the resources and tools required for its role.
6. A representative authorized user can start a conversation and receive a response.
7. An unauthorized or out-of-scope user cannot retrieve restricted results.
8. Reasoning and tool-message presentation matches the organization’s disclosure policy.
9. Failed delivery produces an observable signal with an identified owner.
10. Credential rotation and channel removal have a tested recovery procedure.

Test both content and transport. A correct answer that never reaches Slack is a delivery failure. A delivered answer that exceeds the user’s data scope is an authorization failure. Treating those as separate checks makes each problem easier to diagnose and contain.

Why native messaging channels matter

Native channels reduce the context switch between a business question and a governed Agent workflow. Teams can ask from a familiar surface while DataFact keeps the Agent configuration and execution boundary explicit.

The useful outcome is not simply that another bot can send messages. It is that an organization can place a controlled Agent in an existing collaboration channel without treating message delivery as permission to use every connected resource.

See how DataFact Agents deliver results or review the channel documentation.