Agent updates and the deprecation of assistant_view​

The Assistant messaging experience (assistant_view) will be deprecated in February 2027. The assistant-related methods that power it are being replaced by a new set of API methods: the Agent Sessions API. Agent sessions let users manage their conversations with your agent in one place, with a status, a title, and a stop button. The agents.sessions.setStatus and agents.sessions.rename API methods replace the assistant.threads.setStatus and assistant.threads.setTitle API methods, respectively. For now, your existing calls keep working through a compatibility bridge. See the Agent sessions guide to get started.

The Agent messaging experience (agent_view) is already available, and we recommend moving to it now. If your app still uses assistant_view, follow the migration guide to move to the new experience. Read more in the guide to developing agents.

What's new for agents​

Alongside this announcement, we're releasing a set of improvements to the agent experience:

• Upgraded Tools tab: a newly renamed and revamped Agents & Tools tab helps users find popular agents with a new landing page.
• Improved thread experience: including multi-agent stacking, thread naming, a revamped thinking UI, and a native stop button for agent streams. When a user stops your agent, your app receives an agent_session_stopped event.
• Plan and Task card block updates: UI refinements to the plan and task card blocks agents use to show their work.
• Marketplace data in the About tab: an agent's Marketplace data now appears in its About tab.
• Agent sessions in the sidebar: A new sidebar with pin / archive / unread and live updates.

Slack Code is how agents and people work together to build with AI in Slack, creating dedicated channels for more involved work. A channel is created from an existing conversation, context is carried forward, and agents and collaborators have a shared, visible place to work.

Within a session, agents can publish artifacts for people to oversee and iterate on:

• Code diffs, so people can review what changed
• Block Kit views, for structured interactive experiences
• HTML previews, for prototypes and generated interfaces
• Canvases, for longer-form content and collaboration

The work becomes multiplayer: teammates can join channels, review work, add context, and help make decisions, all while collaborating in the same session and with the same artifacts. Your agent manages the lifecycle, creating a channel when a task warrants one, sharing updates as the work progresses, and closing the session once the work is complete.

Read on to learn more:

• Slack Code: where your team and agents build together
• Build with AI as a team using Slack Code

Installing the plugin sets up two things:

• Skills. Focused sets of instructions and references that your assistant loads automatically when a task calls for them. The plugin includes skills for Block Kit, scaffolding new apps, calling Web API methods, using the Slack CLI, composing messages, and searching Slack.
• Slack MCP Server connection. The Slack MCP server lets you and your agent interact directly with your Slack workspace, such as searching channels, sending messages, and managing canvases.

Install the plugin in Claude Code with /plugin install slack@claude-plugins-official, or from the Cursor Marketplace.

Read the Slack MCP and Skills Plugin docs to get started.

• We've added the slack manifest diff command, which prints differences between the project manifest and the app settings.
• We've added the slack blocks preview command to open Block Kit blocks in the Block Kit Builder.

• The Slack CLI now recommends the official Slack plugin to Claude Code users.
• We've reduced the verbose output when using create --app to link an existing app during project creation.
• We've added a --category flag to slack docs search command.
• When the CLI errors because a prompt must be shown while in a non-TTY environment (AI agents, devops scripts, etc.), the error message now displays the prompt and, for app and team selection, the matching flags to select an option.
• We've fixed a recurring unable_to_parse_json error caused by empty JSON files (credentials, config, or app state) left behind by an interrupted write; the CLI now treats them as empty state and recovers automatically.

If your app doesn't use proxy/TLS configuration or inspect respond() return values, this upgrade is possibly only a version bump.

New features​

• We've added a dispatcher option to the SocketModeReceiver class.
• We've added instanceof operator support to error classes.

Breaking changes​

• We've raised the minimum Node.js version to 20.
• We've removed the agent and clientTls options from the AppOptions interface.
• We've updated the SocketModeReceiver class to accept a dispatcher option instead of proxy agents.
• We've removed Workflow Steps from Apps.
• We've updated the respond() utility function to return a native Response object.
• We've upgraded the Node Slack SDK dependencies.
• We've improved error handling throughout.

For full migration details, see the Bolt for JS v4 to v5 migration guide.

All packages now require Node.js 20 or later. This is the only breaking change for the following packages:

• The cli-hooks package has been updated to v2.
• The cli-test package has been updated to v4.
• The logger package has been updated to v5.
• The oauth package has been updated to v4.
• The types package has been updated to v3.

Three packages have more substantial breaking changes:

• The socket-mode package has been updated to v3. See the guide on migrating @slack/socket-mode from v2 to v3 for handling breaking changes.
• The web-api package has been updated to v8. See the guide on migrating @slack/web-api from v7 to v8 for handling breaking changes.
• The webhook package has been updated to v8. See the guide on migrating @slack/webhook from v7 to v8 for handling breaking changes.

Most of the changes in those batch of updates fall under the theme of HTTP transport improvements, such as migrating from axios to the native Fetch API.

Here's what developers need to know:

• New event: app_context_changed: Slack will send an app_context_changed event to your app whenever the user's active context changes. The event payload includes an ordered list of entities the user is currently viewing.
• The app_context is now sent to message.im and app_home_opened events: Slack will also send the app_context to these events if the app is subscribed to the app_context_changed event.

Learn more in the guide to Developing agents.

• Agent messaging experience (agent_view): agent conversations now look & feel the same as a regular direct message. Gone is the history tab and new chat button. Instead, all of your conversations appear in the standard message tab and your agent can respond in-thread.
• Assistant messaging experience (assistant_view): agent conversations happen in separate Chat and History tabs.

New apps can only use the Agent messaging experience. Apps that already use the Assistant messaging experience can continue to use it for now, but assistant_view will eventually be deprecated, and we'll ask existing apps to migrate to agent_view.

The Agent messaging experience changes the following:

• Knowing when a user opens a DM: rely on the app_home_opened event to know when a user has actively opened a DM with your app. The assistant_thread_started event no longer indicates this. See Migrating to the Agent messaging experience for details.
• Suggested prompts: suggested prompts now live at the top of the Messages tab instead of within threads, and the thread_ts argument is no longer required when agent_view is enabled.
• Continuing a conversation: after a user sends a new message, calling the assistant.threads.setStatus API method on that thread automatically opens the thread to keep the conversation going.

The Slack CLI v4.4.0, Python SDK v3.43.0 with Bolt Python v1.29.0, and @slack/web-api@7.18.0 (for the Node Slack SDK) are required to access the Agent View feature.

Already have an app using the Assistant messaging experience? Follow the migration checklist to move to the Agent messaging experience. Read more in the guide to developing agents.

• The Slack CLI now supports the features.agent_view app manifest property to enable the new Agent experience.

For more details about building with Block Kit, check out our Block Kit overview!

• The slack create command now accepts the --app flag to scaffold a project and automatically link it to an existing app.
• The slack external-auth add-secret command is now available to all apps, not just Slack-hosted apps.
• The Slack CLI now supports mcp_server manifest fields for connecting MCP servers to the Slackbot MCP Client.

The Slackbot MCP Client allows developers to connect MCP servers to Slack. Once connected, Slackbot will automatically discover your MCP server's tools and invoke them based on user prompts in conversation.

Four authentication methods are available for connecting to MCP servers:

• Slack identity auth: for MCP servers that map Slack user and team IDs to available features, with no separate OAuth flow required for end users.
• No auth: for MCP servers that serve standard responses regardless of requestor.
• Dynamic Client Registration: for MCP servers that support standard OAuth discovery. Slack handles client registration automatically.
• Manual OAuth: for MCP servers where you manually register OAuth credentials with the provider.

Read the Slackbot MCP Client docs to get started.

What's changing​

Previously, system-generated notifications were sent as direct messages from Slackbot. Now that Slackbot is the home for AI conversations in Slack, we want to separate notification delivery for clarity. These notifications are now sent from the new "Slack" system user, USLACK. Existing historical Slackbot system notifications will be backfilled and moved to the new "Slack" DM as well.

Note: User-authored messages sent directly to Slackbot (e.g., messages you typed into the Slackbot conversation) are not affected by this change.

What this means for developers​

If your app or integration:

• Filters incoming messages or events by Slackbot's user ID,
• Checks the username field for "Slackbot" to identify system notifications, or
• Uses the chat.postMessage API method or related API methods and expects system notifications to route through Slackbot

then you should update your integration to handle the new "Slack" system user (USLACK) instead.

No action required if your integration does not reference Slackbot's user ID or username in its logic.

For more details about building with Block Kit, check out our Block Kit overview!

• The slack api command can now send unauthenticated requests when no token is available or when --no-auth is specified.
• The slack api command no longer triggers a background update check when invoked with arguments (e.g., slack api chat.postMessage).
• Any Y/N select prompts now display as vertical selection, similar to the slack create command.
• We've disabled upgrade notifications for the slack manifest and slack manifest info command. The command returns JSON that may be used for scripting, and the notifications interfere with parsing the response output.

For more details about building with Block Kit, check out our Block Kit overview!