Deploying to Slack
Learn the three Slack deployment patterns, how to stay in control of your agent after it's live, and how to prevent the two most common trust-breaking failures.
Key Takeaway
Every Slack-deployed agent can be paused in under a minute. Three deployment patterns serve three relationships with your team, and the owner maintains full control through four immediate actions: pause, remove, switch identity, and disable Live Mode. The agent operates within the boundaries of its deployer's access, and explicit channel scoping in the agent config prevents the most common trust-breaking failure mode.
Core concepts
Three patterns, three relationships
Channel-based @mention is the most common starting point. The agent is added to a Slack channel and responds when someone @mentions the Hyperagent bot. It appears under the shared Hyperagent identity, making it low-friction to deploy but generic in appearance. Best for teams exploring agent deployment with low commitment.
Custom identity gives the agent its own name and avatar. Instead of the generic Hyperagent bot, it appears as "Chief of Staff" or any name you configure. Custom identities can send outbound DMs to workspace members, enabling proactive communication, but can't yet receive inbound DMs. Best for team-facing agents that should feel like a purpose-built tool.
Live Mode DMs is an always-on pattern where the agent monitors direct messages sent to the Hyperagent bot and responds automatically. Every incoming DM triggers a response without needing an @mention. Best for personal agents or situations where conversations should be private.
Starting point: Most builders begin with channel-based @mention to test in a low-stakes way, then graduate to a custom identity once the team is ready for a named tool.
Four immediate actions
Every deployed agent is under the owner's control at all times. The answer to "Can I turn it off?" is always yes.
Pause a deployment stops the agent from responding to new @mentions. In-progress threads complete gracefully; only new triggers are ignored until you unpause. This is the primary safety valve.
Remove from channel is the full withdrawal. The agent leaves the channel entirely. To redeploy, you configure the channel assignment again from scratch.
Switch identities moves the agent between the standard Hyperagent bot and a custom identity. Critical: this pauses all existing deployments for that agent. Every channel goes silent until you explicitly unpause each one.
Disable Live Mode stops the agent from monitoring and responding to DMs. Like pausing, in-progress threads complete but new DMs are ignored.
The agent inherits the deployer's access
A deployed agent runs with the permissions of the person who set it up: their Slack workspace access, their connected integrations, and their stored credentials. The agent doesn't have its own independent access layer.
Boundary 1: The agent can only access Slack channels it's been explicitly added to. Even if the deployer has access to 50 channels, the agent monitors only its assigned channels.
Boundary 2: The agent can't DM users unless Live Mode is enabled or a custom identity with outbound DM capability is configured.
Boundary 3: If the deployer's integrations disconnect or their credentials expire, the agent's capabilities are affected.
Implication for teams: The deployer is the single point of control and the single point of failure. There's currently no contributor-level access that allows another team member to pause or reconfigure the agent's Slack deployments when the deployer is unavailable.
Two trust-breaking failures and how to prevent them
Unexpected channel posting. An agent can discover references to other Slack channels through conversations it processes. It saves these as memories and may post to those channels in subsequent invocations. In one real case, an agent deployed to a team channel discovered a competitive intel channel through thread context and started posting there without authorization.
Fix: Scope channel access explicitly in the agent's system prompt ("You may only post to #ops-team and #ops-weekly") and enforce at the agent config level. Config-level restrictions are hard boundaries; system prompt instructions are strong directives. Use both layers.
Silent deployment pause after identity switch. Switching a custom identity pauses all channel deployments for that agent with no warning dialog, no notification, and no visual indicator in Slack. A builder may not discover the silence for hours.
Fix: Treat identity switches as deployment events. Immediately check the Slack deployment panel after switching, unpause each channel explicitly, and schedule switches during low-traffic periods.
Choosing the right deployment pattern
Each pattern is designed for a different relationship between the agent and the people who interact with it.
| Dimension | Channel @Mention | Custom Identity | Live Mode DMs |
|---|---|---|---|
| Trigger | Team member @mentions the Hyperagent bot in a channel | Team member @mentions the custom-named agent in a channel | Anyone sends a DM to the Hyperagent bot |
| Agent identity | Shared Hyperagent bot (same across all deployments) | Custom name and avatar (unique per agent) | Standard Hyperagent bot in DMs |
| DM capability | None | Outbound only (can send, can't receive) | Full (responds to incoming DMs) |
| Best for | Low-commitment testing; teams exploring deployment | Team-facing agents that need a recognizable presence | Personal agents; private conversations |
| Tradeoff | Agent feels generic; shared identity across workspace | Identity switch pauses all deployments; no inbound DMs yet | Available to entire workspace; harder to scope access |
One-agent-per-channel constraint: Currently, one Hyperagent agent can be deployed per Slack channel. If you need multiple agents, create separate channels per agent (e.g., #ops-reporting and #ops-research). This also makes each channel's purpose clear to the team.
Key vocabulary
🔔Channel-based @mention
The default Slack deployment pattern where an agent responds in a channel when someone @mentions the Hyperagent bot. The agent appears under the shared Hyperagent identity.
🪪Custom identity
A named persona with custom name and avatar assigned to a deployed agent, making it appear as its own distinct bot in Slack rather than the shared Hyperagent identity.
⏸️Pause vs. Remove
Pausing stops new triggers while in-progress threads complete. Removing withdraws the agent entirely and clears the channel association, requiring full reconfiguration to redeploy.
🔐Deployer-scoped permissions
The principle that a deployed agent operates with the permissions of the person who set it up: their Slack access, their integrations, and their credentials.
📍Channel scoping
Explicitly restricting which Slack channels an agent can post to, configured in both the system prompt and the agent's deployment settings, to prevent unintended posting behavior.
🔄Identity switch pause
The platform behavior where changing an agent's custom identity automatically pauses all of its Slack channel deployments, requiring each to be manually unpaused.
Frequently asked questions
Summary
Your Next Step
Start with one channel and one deployment pattern. Watch what your team asks and where the agent falls short. That's your signal for what to refine.