Limit a support employee to one inbox
A team running customer support only through WhatsApp can turn off SMS and other unused channels so the employee never spends time watching a surface nobody uses.
Not every employer wants every channel open. Turn Slack, WhatsApp, SMS, or any other non-core channel on or off for your workspace, either in the settings screen or by simply telling your employee to switch it. Core channels like chat stay on because every employer needs them; everything else is yours to control.
Every AI employee ships connected to more channels than a given employer may want active at once. The channel toggle lets you decide, per workspace, which ones are actually live: turn on WhatsApp for a customer-support employee, leave SMS off for one that only handles internal reporting, and change your mind later without losing any configuration. Only three channels arrive switched on by default when a workspace is provisioned: In-App Chat, Mailbox, and Auto Schedule. Everything else, Slack, Telegram, API Access, MCP Server, A2A Protocol, Webhook, and Email Webhook among them, starts off until you turn it on.
A small number of core channels are always on because the product depends on them to function at all: In-App Chat (turning it off would lock you out of the product), Live Meeting (the meeting-bot join), Auto Schedule (the cron surface behind recurring work), and Calendar (auto-joining from Google, Outlook, and Apple invites). None of these four can be switched off from the UI or by asking your employee; the toggle write is rejected before it reaches the database, and you get back an explanation naming the channel rather than a silent no-op. A separate set of channels, In-App Voice, In-App Video, Discord, SMS, Microsoft Teams Chat, WhatsApp, Phone Call, Chat Widget, and SDK, are marked coming soon in the catalog: they show up in the list so you know they exist, but there is nothing to flip yet, on the UI or in conversation.
You can flip a channel from the workspace settings UI, or just tell your employee directly, for example 'turn off SMS for now' or 'enable WhatsApp'. Either path calls the exact same write function, so the two are always in sync. This is different from the channel usage panel on the same Communications page: the toggle controls whether a channel can receive or send anything at all, while the usage panel only reports how much traffic an already-enabled channel has seen. Turning a channel off does not erase its usage history or its configuration (a Slack workspace connection, a webhook endpoint) which stays intact for the next time you turn it back on.
The settings UI lists every channel available to your workspace with a simple on/off state, so you can see and manage everything in one place.
The same switch is available conversationally through the employee's manage_channels tool, which supports list, enable, disable, and setup_info actions. Ask your employee to enable or disable a channel by name and it calls the same underlying write the UI toggle uses. There is only one source of truth, so the UI and the conversation never disagree.
Four channels are marked always-on in the catalog because the platform relies on them: In-App Chat, Live Meeting, Auto Schedule, and Calendar. Trying to turn one of these off returns a clear explanation naming why, instead of silently failing or leaving your workspace half-configured.
Nine more channels are marked coming soon and cannot be toggled at all, in the UI or by an employee, so you will never accidentally 'turn on' something that is not actually built yet. Asking your employee to enable one of these gets a plain answer that it isn't available.
Slack, Telegram, API Access, MCP Server, A2A Protocol, Webhook, and Email Webhook each carry a plan entitlement on top of the on/off toggle. If your plan does not include one of these, trying to enable it, from the UI or by asking your employee, returns a message telling you it needs a plan upgrade rather than turning on and quietly failing to work.
The entitlement check runs before the toggle write, so a channel you are not entitled to never ends up in an enabled-but-broken state. Once your plan covers it, the same enable action works immediately without any other change.
One switch, read everywhere a message could arrive
Each channel's on/off state is stored per employer and per channel. When a message comes in on any channel, the platform checks this setting before doing anything else: if the channel is off, the message is not processed for your workspace.
A short-lived cache keeps that check fast, and flipping the toggle immediately clears the cache for that channel so the change takes effect on the very next message, not after a delay.
Two channel categories are protected from being turned off entirely: channels the product cannot function without, and channels that are not yet built. The first stays on by design; the second cannot be toggled at all until it ships.
A team running customer support only through WhatsApp can turn off SMS and other unused channels so the employee never spends time watching a surface nobody uses.
When your team is ready to try a new channel, switch it on for one employee first, confirm the workflow feels right, then enable it more broadly.
If a third-party channel needs to be paused, for example during a provider issue or a temporary company policy change, disable it in seconds instead of reconfiguring the employee.
If enabling Slack or the API fails with a plan-upgrade message instead of turning on, you know immediately it's an entitlement problem, not a broken OAuth flow or missing key, and can decide whether to upgrade.
Yes, for any channel that is not marked always-on. In-App Chat, Live Meeting, Auto Schedule, and Calendar stay on for every employer since the product depends on them; every other channel, including Mailbox and Slack, can be turned off.
Within 60 seconds at the outside, and immediately in practice. Flipping the toggle clears the cached state for that channel right away, so the next incoming or outgoing message for your workspace reads the fresh setting instead of the 60-second cache.
Yes. Asking your employee to enable or disable a channel calls the same write function the UI toggle uses through the manage_channels tool, so there is no difference between the two paths.
You get a clear message explaining that channel cannot be turned off because it is a core surface every employer needs, rather than a silent failure. This applies to In-App Chat, Live Meeting, Auto Schedule, and Calendar.
Slack, Telegram, API Access, MCP Server, A2A Protocol, Webhook, and Email Webhook are gated by plan. Enabling one you're not entitled to returns a message that it needs a plan upgrade instead of turning on in a broken state.
No. Disabling a channel only flips its enabled state. Any existing setup, like an authorized Slack workspace or a configured webhook endpoint, stays in place so re-enabling it later doesn't require reconnecting anything.
Channel Enable/Disable Toggle is part of Ways you talk to them.
Chat in the app with live reasoning, speak to your AI voice agent over a call, message on Slack or WhatsApp, send an email, or embed a widget on your website. Every channel connects to the same AI agent with the same memory and capabilities. Switch channels mid-conversation and your employee picks up right where you left off.