# Deploying to Slack

Source: https://www.hyperagent.com/docs/lessons/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.

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 [#core-concepts]

### Three patterns, three relationships [#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 [#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 [#the-agent-inherits-the-deployers-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 [#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 [#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 [#key-vocabulary]

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.

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.

Pausing stops new triggers while in-progress threads complete. Removing withdraws the agent entirely and clears the channel association, requiring full reconfiguration to redeploy.

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.

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.

The platform behavior where changing an agent's custom identity automatically pauses all of its Slack channel deployments, requiring each to be manually unpaused.

## FAQs [#faqs]

Pausing is a temporary hold. The agent remains associated with the channel and retains its configuration. New @mentions are ignored, but any thread the agent was already responding in will complete. Unpausing restores normal operation instantly.

Removing is a full disconnection. The agent leaves the channel, its monitoring stops, and the association is cleared. To bring it back, you need to go through the deployment setup again. Use pause when you want a quick safety stop. Use remove when you want to withdraw the agent from that channel entirely.

When you change an agent's identity, the platform needs to reauthorize each channel deployment under the new identity. As a safety measure, all deployments are paused until the owner explicitly unpauses each one. This prevents the agent from appearing in channels under an identity that may not have been reviewed for that context.

The gap is that this happens without a warning dialog or notification. The channels go silent, and the owner discovers the pause only when checking the deployment settings. The best practice is to treat every identity switch as a deployment event: switch, immediately verify the deployment panel, unpause each channel, and confirm the agent is responding.

Agents learn from their conversations. When a team member mentions a channel name during an interaction, the agent may save that channel reference as a memory. On a future invocation, the agent can use that memory to post to the channel, even though the owner never intended for the agent to operate there.

This is the most common trust-breaking failure mode in Slack deployments. The mitigation is two layers of scoping: an explicit instruction in the system prompt naming only the authorized channels, and config-level restrictions in the deployment settings that act as hard boundaries. System prompt instructions are strong directives the agent follows with high fidelity. Config-level restrictions can't be overridden by the agent regardless of context.

The agent runs with the deployer's permissions: their Slack access, their integrations, their credentials. This makes the deployer the natural control point for the agent's behavior. It also means that if the deployer is unavailable, no one else on the team can pause, reconfigure, or troubleshoot the agent's Slack deployments.

This is an active area of platform development. Teams have raised the need for contributor-level access that would allow designated teammates to manage an agent's deployments without being the original deployer. Until that capability ships, the practical workaround is to document the deployment configuration and ensure at least one other team member knows how to access the agent's settings through the Hyperagent web UI.

## Summary [#summary]

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.